Hunting Ivanti Connect Secure Zero-Days: From Auth Bypass to Implant, With IoCs and Log Sources

Rapid7 is warning that two more Ivanti Connect Secure zero-days are under active exploitation in the wild. This post traces what a warning like that turns into in practice — pre-auth auth bypass, web shell, implant, and the pivot into identity — using the 2024 and 2025 ICS waves as the pattern baseline, then ranks the triage checks I would actually run and maps each exploitation stage to the log source that still carries signal afterwards. The item I'm working from is a short piece from Australian Cyber Security Magazine, dated 4 November 2026 in its feed metadata. That's the whole of it: two bugs, active exploitation, and another reminder that edge appliances remain the cheapest way into a corporate network.

My first reaction was "again." I think that reaction is the actual security problem.

The fatigue isn't irrational. Ivanti Connect Secure has produced a steady supply of pre-auth bugs since the January 2024 wave (CVE-2023-46805 chained with CVE-2024-21887) through the January 2025 buffer overflow (CVE-2025-0282). Teams that own these boxes have run the emergency-patch, integrity-checker, rotate-everything cycle more than once. When the fourth or fifth warning lands, the temptation is to apply the patch, tick the box, and move on.

The position I'll argue instead: for an internet-facing VPN concentrator, "patched" is not "clean." Patching closes the front door. It does nothing about what walked through it while the door was open. If an appliance was exploitable for days before you applied the fix, your job that week is incident triage, not patch management — and on these boxes I'd rather spend one maintenance window rebuilding than a quarter wondering.

The exploitation chain below is drawn from how the earlier ICS waves actually played out, including which log sources still carry signal after an implant lands. The triage checks are ranked in the order I'd run them, and there's a decision tree at the end for teams that can't yank the VPN offline on a Tuesday.

On this page

What Rapid7 Actually Stated, Separated From What Circulated

Confirmed Claims From the Report

CVE Identifiers, Version Ranges, and What I Could Not Verify From Public Sources

Why Patch-Level Precision Matters More Than the Headline

Why VPN Concentrators Keep Ending Up on the Board

The Earlier ICS Zero-Day Wave as a Pattern Baseline

What an Attacker Buys With One Edge Appliance

The Deployed-But-Unmanaged Problem

The Exploitation Chain: Auth Bypass to Implant

Stage 1: Pre-Auth Reconnaissance Against the Login Surface

Stage 2: Authentication Bypass Mechanics on the Request Path

Stage 3: Web Shell Placement and Configuration Tampering

Stage 4: Persistence Through the Integrity Checker

Stage 5: Pivot and Credential Access From the Appliance

Log Sources That Still Give You Hunting Signal After Compromise

Appliance Audit, Admin, and Session Logs

Downstream Identity Telemetry Outside the Appliance

Configuration Diffs and Integrity Checker Output as Detection

A Table Mapping Each Stage to the Log Source That Catches It

Concrete IoCs and Hunting Queries

Authentication and Session Anomalies Worth Alerting On

Filesystem, Process, and Configuration Indicators

Network-Level Signals and Beaconing Patterns

Log Search Queries You Can Adapt to Your Pipeline

Triage Order: What I Would Check First and Why

Ranked Checks With Expected Outcomes

Fast Negative Signals That Let You Close an Alert

Patch or Mitigate: A Decision Tree for Teams That Cannot Take the VPN Offline

Branch 1: Patch Window Available This Cycle

Branch 2: No Maintenance Window This Week

Branch 3: Traffic Already Looks Suspicious

Rebuild Versus Clean: Why I Do Not Trust a Cleaned Appliance

Building Detection Coverage Before the Next Wave

Safe Test Cases in an Authorized Lab

Proving the Alert Fires With Synthetic Traffic

What I Confirmed, What I Did Not Test, and What I Suspect

Further Reading

What Rapid7 Actually Stated, Separated From What Circulated

Confirmed Claims From the Report

Stripped to what the source actually supports:

That is the whole confirmed set. There are no exploitation mechanics, no post-exploitation indicators, no affected build numbers in what I could read.

CVE Identifiers, Version Ranges, and What I Could Not Verify From Public Sources

I could not verify CVE identifiers or affected version ranges for these two bugs from the material I had. I won't invent them, and the reason matters beyond pedantry: a fabricated CVE number in a blog post becomes a fabricated CVE number in someone's scanner exclusion list, ticket, and risk register. Fake precision is worse than admitted ignorance.

Here's the concrete version — what to do instead of trusting any blog post, this one included:

1. Pull the advisory directly from Ivanti's product security advisory list and note the SA- identifier and the exact build numbers listed as fixed.
2. Cross-check the NVD entry for each CVE — nvd.nist.gov — for the CVSS vector and the CPE range.
3. Check whether it landed in CISA's Known Exploited Vulnerabilities catalog. KEV presence is what turns a patch ticket into a deadline with a date on it.
4. Read Rapid7's own write-up on their blog and in AttackerKB for exploitation detail, since the news item summarizes their research rather than presenting it.

Everything below about the exploitation chain comes from the publicly documented mechanics of the earlier ICS waves. I flag where I'm generalizing.

Why Patch-Level Precision Matters More Than the Headline

"Affected: Ivanti Connect Secure 22.x" is not actionable. Ivanti ships builds, not point releases, and the fixed-build list is the only thing that answers "am I exposed." An appliance reporting 22.7R2.4 and one reporting 22.7R2.5 can sit on opposite sides of the same advisory.

I don't have a version-fingerprinting one-liner for ICS that I trust — the appliance doesn't reliably advertise its build to an unauthenticated request, and I've seen enough variation between builds to distrust banner guessing. The reliable source is the version string in the admin console under system status, which means the real problem is inventory hygiene. Reconcile it in bulk:

## inventory.csv  -> host,build   (exported from your CMDB or console scrape)
## fixed-builds.txt -> one build per line, copied from the vendor advisory

while IFS=, read -r host build; do
  [ "$host" = "host" ] && continue
  if grep -qx "$build" fixed-builds.txt; then
    printf 'OK    %-24s %s\n' "$host" "$build"
  else
    printf 'CHECK %-24s %s\n' "$host" "$build"
  fi
done < inventory.csv

OK    vpn-eu-01                22.7R2.5
CHECK vpn-us-01                22.7R2.3
CHECK vpn-ap-02                22.7R2.1

CHECK does not mean vulnerable — it means nobody has proven it isn't. If you can't produce this table in under ten minutes during an active-exploitation window, that gap is a finding in its own right.

Why VPN Concentrators Keep Ending Up on the Board

The Earlier ICS Zero-Day Wave as a Pattern Baseline

The 2024 wave is the reference model, and it's the most useful thing to study when a new ICS advisory drops, because the sequence of events tends to repeat.

In January 2024, Ivanti disclosed CVE-2023-46805 (an authentication bypass in the web component, CVSS 8.2) chained with CVE-2024-21887 (a command injection in the web components, CVSS 9.1). Mandiant attributed exploitation to a cluster they tracked as UNC5221. Volexity published post-exploitation analysis describing a web shell they called GIFTEDVISITOR and a broader campaign they named LIGHTBASILISK. CISA issued Emergency Directive 24-01. Ivanti shipped an XML mitigation component while patches were still pending, then patched in waves — with at least one follow-on vulnerability (CVE-2024-21893, an SSRF in the SAML component) added to the pile after organizations had already "finished" the first round.

Then in January 2025, CVE-2025-0282 — a stack-based buffer overflow in Connect Secure, Policy Secure and Neurons for ZTA gateways, CVSS 9.0, pre-auth RCE, exploited as a zero-day — repeated the pattern: emergency patch, forced integrity checks, forced credential rotation.

The recurring shape is: pre-auth bug in the web or SAML surface → exploitation within days → implant that survives patching → the integrity checker itself becomes a target.

What an Attacker Buys With One Edge Appliance

Attackers keep coming back because the payoff is disproportionate to the effort. A compromised concentrator isn't "one server." It typically yields:

• Session material. Active VPN sessions, cookies, and the ability to ride an authenticated tunnel without ever touching a credential.
• SAML signing keys and IdP trust. An appliance that signs assertions is a position from which identity can be minted, not just borrowed. This is the finding I care about most, and it gets the least attention in patch-day comms.
• Configuration secrets. LDAP bind credentials, RADIUS shared secrets, client and server certificates, and any local accounts in the appliance realm.
• Topology. Every internal route the appliance can reach, learned from its own config rather than from noisy scanning.
• A quiet pivot point. Traffic from the appliance's management address toward internal hosts often has no EDR, no agent, and no user to notice.

That last point is why I keep saying the appliance is an identity asset, not a network asset. Treating it as a network device is how it ends up in the "patch quarterly" bucket.

The Deployed-But-Unmanaged Problem

I've watched the same ownership failure play out repeatedly. The appliance was bought by the network team. It's racked, it terminates VPN, it works. Nobody owns its patching because it isn't a server and isn't a firewall. It has no EDR (you can't install one). Its logs go to a local disk that nobody ships off-box because "syslog doesn't support the format." There's a VM snapshot from 2019 that someone considers a backup.

That's the environment these exploits are designed for. The bug is the entry; the deployment model is why entry becomes persistence.

The Exploitation Chain: Auth Bypass to Implant

Framing before the mechanics: the specific stages of the two new bugs are not public in what I read. What follows is the chain as documented across the prior ICS waves, generalized so you can map it onto the new advisory once real detail lands. Where a step is inference, I say so.

Stage 1: Pre-Auth Reconnaissance Against the Login Surface

The ICS web surface is well known and easy to enumerate. A researcher or attacker establishing a baseline records response codes and headers for the standard endpoints:

for p in /dana-na/auth/url_default/welcome.cgi \
         /dana-na/auth/url_admin/welcome.cgi \
         /dana-na/auth/saml-consumer.cgi \
         /dana-na/auth/saml-sso.cgi; do
  printf '%-42s %s\n' "$p" "$(curl -sk -o /dev/null -w '%{http_code}' \
    --max-time 5 "https://vpn.example.com$p")"
done

/dana-na/auth/url_default/welcome.cgi       200
/dana-na/auth/url_admin/welcome.cgi         302
/dana-na/auth/saml-consumer.cgi             400
/dana-na/auth/saml-sso.cgi                  302

Those exact codes will differ on your build — the point is to capture them as a baseline you can diff later. A pre-auth endpoint that starts returning 200 instead of 302, or a new 500 where you previously saw 400, is one of the few cheap signals you get from outside the box.

Stage 2: Authentication Bypass Mechanics on the Request Path

Here's the mental model I use for this bug class, because it generalizes across every ICS auth bypass I've read up on.

These appliances have two request layers: a portal/reverse-proxy front end that handles unauthenticated traffic, and application handlers behind it that assume "if a request reached me, the front end already authenticated it." An auth bypass is almost never "authentication doesn't exist." It's a route where the request reaches the handler while sidestepping the front-end check — through path handling quirks, alternate encodings, or an endpoint that was never wired into the auth filter.

The 2024 pattern was exactly this: reach administrative functionality pre-auth, then use it. The 2025 bug skipped the logical bypass entirely and was a memory-safety failure in the pre-auth parser — different mechanism, same outcome.

The defensive consequence: you cannot reason about exposure from the login page. The login page behaving correctly tells you nothing about the endpoints that don't render a login page. That's why "I checked, it asks for credentials" is not a valid triage argument, and it's why I push teams toward build-number verification over behavioral testing.

Stage 3: Web Shell Placement and Configuration Tampering

Once code execution exists, the documented objective in prior waves was durable, low-noise access. Public reporting from the 2024 wave describes web shells placed in web-accessible locations — Volexity's write-up described replacement of the portal's welcome.cgi with a web shell, so that a legitimate-looking page path served attacker code.

Alongside the shell, the configuration is where I'd look hardest: authentication server ordering, realm settings, and local administrator additions. On an appliance, "change the config" is often equivalent to "change who can authenticate," and config changes are far less likely to trip a file-integrity alert than a new binary.

I treat any unexpected change to the auth server chain on a concentrator as a compromise indicator until proven otherwise — not a misconfiguration.

Stage 4: Persistence Through the Integrity Checker

This is the part defenders consistently get wrong, so I'll be blunt: a passing integrity check is not evidence of a clean appliance.

The Integrity Checker Tool is itself software running on the box. Attackers who already have code execution can modify the checker, or modify the components the checker validates against. Reporting around the 2024 wave described exactly this: tampering that caused the checker to return clean results on compromised systems.

What that means operationally:

• Record the checker's output and the hashes of the checker's own artifacts, so you can tell later whether the tool you trusted was the tool you shipped.
• Treat a suspiciously terse "no issues found" as suspicious, not reassuring.
• Do not accept "we ran the integrity check and it passed" as a triage negative unless you can show what the checker binary's hash was at the time.

Stage 5: Pivot and Credential Access From the Appliance

The end state of the chain isn't a shell on the VPN box. It's the appliance used as an authenticated launch point: harvesting session databases and cached credentials, beaconing out over allowed ports, and reaching internal hosts from a source IP that internal controls broadly trust because it's the VPN.

My assessment — untested against these specific bugs, but consistent with prior waves — is that the highest-value target on the box isn't code execution, it's the signing and trust material. An attacker who takes the SAML signing key doesn't need to stay on the appliance at all; they can mint identity upstream. That's why credential rotation after a suspected compromise has to include trust material, not just user passwords.

Log Sources That Still Give You Hunting Signal After Compromise

Appliance Audit, Admin, and Session Logs

The admin console exposes administrative access logs and system event logs, and the appliance can forward them to syslog. Exact menu paths and field formats vary by build, and I won't pretend otherwise — but the categories are stable:

• Administrative access log: who logged into the admin console, from where, when, and whether it succeeded. This is your single highest-value log and the one most often not shipped off-box.
• System/event log: service restarts, config changes, and upgrade events.
• Session records: active VPN sessions and their source addresses.

The first thing I check on any ICS engagement is whether these leave the appliance at all. If they only live on local disk, an attacker with root deletes the evidence before you ask for it.

Downstream Identity Telemetry Outside the Appliance

This is where you get signal the attacker can't easily reach. If your VPN authenticates against AD or an IdP, you have a second copy of the authentication story:

• Domain controller events for the appliance's service account and for VPN-authenticated users, including any authentication that appears to come from the appliance but originates from a sudden burst of users.
• RADIUS/NPS logs if the appliance federates to a RADIUS server — the shared-secret model means a compromised appliance can authenticate arbitrary users, and those successes show up downstream.
• IdP SAML assertion logs: an assertion signed by the appliance for a user who never hit the VPN login page is a red flag.

I put this second only because it's slower to query. On trust, it comes first — it's off-box and harder to tamper with.

Configuration Diffs and Integrity Checker Output as Detection

You can't detect config tampering without a known-good config. Two commands' worth of discipline:

• Export the appliance configuration on a schedule, out-of-band, and diff it. Alert on any change not tied to a change ticket.
• Archive integrity checker output with the timestamp and the hash of the tool that produced it.

Neither is glamorous. Together they're the difference between "we think it's clean" and "we can show it."

A Table Mapping Each Stage to the Log Source That Catches It

Concrete IoCs and Hunting Queries

Everything in this section hunts structure, not a published indicator list — because no indicator list for these two bugs is public in what I read. Adapt the field names; they won't match your pipeline exactly.

Authentication and Session Anomalies Worth Alerting On

• Successful admin console login from an ASN or country the appliance has never seen, especially followed by config activity.
• A burst of failures against the admin UI followed by a success — the classic pre-patch brute-force-adjacent pattern.
• Any admin session with no corresponding MFA event downstream, where MFA is enforced for admins.
• A session count jump that doesn't correlate with a workday start in any region.
• Concurrent sessions for the same user from different source ASNs.

Filesystem, Process, and Configuration Indicators

On builds where you can reach a shell, the checks I'd run first are modification-time and hash based rather than name based:

## web root and config, most recently modified first
find /home/webserver/htdocs /home/etc -type f \
     -newermt '2026-10-01' -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null \
  | sort -r | head -40

## unexpected interpreter children under the web server
ps -eo pid,ppid,user,etime,cmd | grep -E 'perl|python|sh -c' | grep -v grep

2026-10-28 03:12 /home/webserver/htdocs/dana-na/auth/url_default/welcome.cgi
2026-10-28 03:12 /home/webserver/htdocs/dana-na/img/logo_small.png

Two files modified at the same minute, one of which is a PNG that nobody would ever edit, is exactly the kind of output that closes an investigation in the wrong direction — or opens one. The indicator is the pairing, not either file alone.

Network-Level Signals and Beaconing Patterns

• Appliance-originated outbound connections to destinations outside your documented update and licensing endpoints. An egress allowlist makes this trivial; without one it's white noise.
• Long-lived TLS sessions from the appliance's management address to a single external IP, especially with regular small payloads.
• DNS lookups from the appliance for domains registered in the last 90 days.
• Internal east-west traffic from the appliance to hosts that no VPN user has ever needed.

Log Search Queries You Can Adapt to Your Pipeline

Administrative auth anomaly, expressed generically:

-- field names will differ; the shape is what matters
SELECT
  src_ip,
  countIf(event = 'admin_login_failed') AS fails,
  countIf(event = 'admin_login_success') AS successes,
  min(ts) AS first_seen,
  max(ts) AS last_seen
FROM appliance_admin_log
WHERE ts > now() - INTERVAL 24 HOUR
GROUP BY src_ip
HAVING fails >= 5 AND successes >= 1
ORDER BY successes DESC, fails DESC;

src_ip          fails  successes  first_seen           last_seen
203.0.113.44    37     1          2026-11-05 02:14:07  2026-11-05 02:19:51
198.51.100.9    6      1          2026-11-05 09:41:12  2026-11-05 09:41:30

The first row is the one I'd wake someone for. The second might be a legitimate admin fat-fingering a password six times before coffee — which is precisely why this query is a triage filter, not an alert with a page attached.

For appliances where logs only exist locally, a shell-side pre-filter keeps volumes sane:

awk '/admin_login_(failed|success)/ {print $1, $2, $NF}' /var/log/admin_access.log \
  | sort | uniq -c | sort -rn | head -20

Triage Order: What I Would Check First and Why

Ranked Checks With Expected Outcomes

1. Exact build number against the advisory's fixed-build list. Fastest possible answer to "are we even in scope." Expected outcome: a build string you can match, or a finding that your inventory is stale.
2. Is the admin console reachable from the internet at all? If it isn't, an entire class of post-exploitation activity is harder and your triage priority drops. Expected outcome: a yes/no you can prove with an external scan.
3. Admin access log review, 30 days back, for new source ASNs. Expected outcome: a short list you can explain, or a short list you can't.
4. Config export diff against the last known-good. Expected outcome: either a clean diff or a change nobody can justify.
5. Web root modification times and hashes against baseline. Expected outcome: a list of files changed since the last patch window, ranked by suspiciousness.
6. Egress flow review from the appliance's management address. Expected outcome: either a documented allowlist match or an outlier worth chasing.

Build verification comes first not because it's the most security-relevant, but because it's the cheapest gate. If you're not in the affected range, checks 3–6 become routine instead of urgent — and knowing you can close the ticket in ten minutes with evidence is what stops alert fatigue from turning into a real incident.

Fast Negative Signals That Let You Close an Alert

Every one of those has a "valid only if" column, and that column is where most rapid triage quietly fails. "We checked the admin logs and there's nothing" from an appliance that only logs locally isn't a negative signal. It's an absence of evidence.

Patch or Mitigate: A Decision Tree for Teams That Cannot Take the VPN Offline

Branch 1: Patch Window Available This Cycle

Patch, then verify the build changed (don't trust the installer's success message), then run the integrity check and archive its output along with the checker's hashes.

Then do the part people skip: rotate. After a pre-auth compromise window, rotate everything that lived on that box — local admin passwords, LDAP bind credentials, RADIUS shared secrets, and critically, any SAML signing certificates and the trust relationships built on them. Then invalidate all active VPN sessions. A patch that leaves the attacker's stolen signing key valid has fixed nothing that matters.

Branch 2: No Maintenance Window This Week

Be honest with yourself about what mitigation buys: it reduces the probability of new compromise. It does not address existing compromise, and it does not survive the next variant.

What's actually worth doing:

• Remove the admin console from internet reachability. This is the single highest-value control available without downtime, and it's frequently ignored because "our admins work from anywhere."
• Disable unused services and auth methods on the appliance — every enabled surface is a future CVE.
• Front the appliance with an auth proxy or WAF rules for the known endpoint paths, and accept that this is a speed bump against targeted attackers.
• Turn on full log forwarding. Not next sprint. Today, because you can't investigate the compromise you may already have without it.

I'm skeptical of vendor workarounds for a reason: in the 2024 wave the XML mitigation was a stopgap that had to be paired with actual patches and follow-on fixes. Treat any mitigation as exposure reduction with a hard expiry date, not a fix.

Branch 3: Traffic Already Looks Suspicious

Stop treating it as a patch task. What that looks like:

1. Preserve before you touch. Volatile state — running processes, active sessions, memory — is gone after a power cycle.
2. Isolate at the network layer with an explicit allowlist, not by pulling the power on a box that 3,000 people need.
3. Rebuild, don't clean. More on this below.
4. Run the identity-side investigation in parallel: IdP logs, DC logs, and everything the appliance trusted.

Rebuild Versus Clean: Why I Do Not Trust a Cleaned Appliance

My position is unambiguous: rebuild. The reasoning isn't paranoia, it's arithmetic about what you can actually verify.

On a black-box appliance you cannot enumerate every write an attacker with root made. Files can be restored to their original hashes after a backdoor is established elsewhere. The integrity checker can be tampered with — that's publicly documented behaviour from the 2024 wave. The vendor's clean-check tooling is itself software you'd be trusting based on a hash you probably didn't record.

Rebuilding costs a maintenance window, a config restore from a known-good export, and a certificate re-enrolment. Not rebuilding costs a quarter of uncertainty and, if you're wrong, a domain compromise that started at the VPN. I've never once regretted the rebuild, and I've watched plenty of teams regret trusting a clean scan.

Building Detection Coverage Before the Next Wave

Safe Test Cases in an Authorized Lab

You can't test these detections on production, so build a lab. An evaluation instance of Connect Secure (or the vendor's supported lab licensing path) plus a log shipper gets you 90% of what you need. On it, exercise:

• Repeated failed admin logins followed by a success, from a controlled source.
• A config change with no change ticket, to prove your diff job fires.
• A file dropped into the web root, to prove the mtime/hash job fires.

All of these are things you can do to your own appliance without touching anything real. None of them require exploit code.

Proving the Alert Fires With Synthetic Traffic

A rule you haven't seen fire is a rule you don't have. Write synthetic events matching the exact schema your pipeline ingests, and confirm the alert:

cat >> /var/tmp/ics-lab.log <<'EOF'
2026-11-05T02:14:07Z ics-lab-01 adm: admin_login_failed user=admin src=203.0.113.44
2026-11-05T02:14:09Z ics-lab-01 adm: admin_login_failed user=admin src=203.0.113.44
2026-11-05T02:14:11Z ics-lab-01 adm: admin_login_failed user=admin src=203.0.113.44
2026-11-05T02:14:12Z ics-lab-01 adm: admin_login_failed user=admin src=203.0.113.44
2026-11-05T02:14:15Z ics-lab-01 adm: admin_login_failed user=admin src=203.0.113.44
2026-11-05T02:14:18Z ics-lab-01 adm: admin_login_success user=admin src=203.0.113.44 mfa=none
EOF

## expected: your pipeline emits exactly one alert for 203.0.113.44
grep -c 'admin_login_success' /var/tmp/ics-lab.log

1

If that produces zero alerts, you've found a detection gap in five minutes instead of during an incident. This is the cheapest security engineering available to any team, and almost nobody does it, because writing the rule feels like the finish line when it's actually the start.

What I Confirmed, What I Did Not Test, and What I Suspect

Confirmed from the source: Rapid7 is warning about two additional Ivanti Connect Secure zero-days under active exploitation; the disclosure follows an extended run of edge-appliance compromises.

Confirmed from primary sources about the earlier waves (not these two bugs): CVE-2023-46805 (CVSS 8.2) chained with CVE-2024-21887 (CVSS 9.1) were exploited in January 2024; CVE-2024-21893 was a SAML SSRF added later; CVE-2025-0282 (CVSS 9.0) was a pre-auth stack overflow exploited as a zero-day; CISA issued ED 24-01. Public reporting describes web shell placement in web-accessible paths and tampering with integrity-checking on compromised appliances.

Did not verify, and will not assert: the CVE identifiers, affected build ranges, exploitation mechanics, or post-exploitation indicators for the two bugs in the Rapid7 warning. I didn't reproduce these specific vulnerabilities for this post.

Suspect, but untested: that the exploitation chain will look structurally like the 2024–2025 waves — pre-auth web/SAML entry, shell placement, config tampering, checker evasion. That's inference from pattern, not reporting on these bugs. If the real detail turns out to be something else, the detection sections above still hold, because they target post-exploitation behaviour rather than a specific byte pattern.

Strong opinion: the organizations that get hurt by this wave will mostly not be the ones that failed to patch. They'll be the ones that patched, assumed clean, and never rotated the signing material.

Further Reading

• CISA Known Exploited Vulnerabilities catalog — check whether the new CVEs are listed before you set a patch deadline.
• NVD: CVE-2024-21887 and NVD: CVE-2023-46805 — the January 2024 chain referenced throughout.
• NVD: CVE-2025-0282 — the January 2025 pre-auth buffer overflow.
• Rapid7 blog and AttackerKB — where the exploitation detail for this warning should appear.
• Ivanti product security advisories — the authoritative source for affected builds and SA- identifiers; search for the Connect Secure advisory, not the marketing pages.
• Volexity's blog — the January 2024 post-exploitation analysis covering web shell placement and integrity-checker evasion on compromised appliances.