If you run Ivanti Connect Secure, the job this weekend is the same as two weeks ago, only with less room for doubt. On 30 October 2026 CISA added two more Connect Secure flaws to its Known Exploited Vulnerabilities catalog: CVE-2026-111357, a privilege escalation to root, and CVE-2026-118527, a predictable-identifier bug that lets an authenticated attacker write files to a known location on disk. KEV says both chain with CVE-2026-104935, the authentication bypass Ivanti patched on 13 October.

Upgrade to a release that fixes CVE-2026-104935 if you have not already. Then treat any appliance that was exposed on 22.8R2.4 or earlier during October as a possible compromise. As of 31 October we could not find a public fixed version for either of the two new CVEs, and the sections below explain why.

The three CVEs in the chain

The KEV entries for CVE-2026-118527 and CVE-2026-111357 both say the flaw “can be chained with” the other two. Read together, the descriptions fit a familiar pattern: an unauthenticated foothold, a way to place attacker-controlled content where the appliance will find it, then a jump to root. That ordering is our reading of the descriptions. Neither Ivanti nor CISA has published the step-by-step mechanics.

The MITRE record for CVE-2026-111357 adds one technical detail. It says Connect Secure 22.8R2.4 “mishandles the manner in which the dsinvoked broker trusts DSCache configuration data, leading to privilege escalation to root, as exploited in the wild in October 2026.”

If you track these programmatically, this pulls the three entries from CISA’s KEV JSON. We ran it with Python 3.13 on 31 October; it uses only the standard library:

import json, urllib.request

URL = "https://raw.githubusercontent.com/cisagov/kev-data/main/known_exploited_vulnerabilities.json"
WANT = {"CVE-2026-104935", "CVE-2026-118527", "CVE-2026-111357"}

with urllib.request.urlopen(URL, timeout=30) as r:
    kev = json.load(r)

for v in kev["vulnerabilities"]:
    if v["cveID"] in WANT:
        print(v["cveID"], v["dateAdded"], v["dueDate"],
              "triage=" + v.get("forensicTriage", "?"), ",".join(v["cwes"]))

Output on 31 October:

CVE-2026-118527 2026-10-30 2026-11-13 triage=No CWE-340
CVE-2026-111357 2026-10-30 2026-11-02 triage=Yes CWE-306,CWE-862,CWE-345
CVE-2026-104935 2026-10-13 2026-10-16 triage=Yes CWE-290

For what each field means and how to match the feed against a scanner export, see our guide to the CISA KEV JSON feed.

What is fixed and what is not

CVE-2026-104935 has fixes. The CVE record Ivanti published says the bug affects “ICS before version 25.1.3.0” and “does not impact ICS version 22.7R2.14 or prior”. It lists 25.1.3.0, 25.1.3.1, 22.8R2.5 and 22.7R2.14 as unaffected.

Rapid7’s write-up of Ivanti’s advisory breaks this down by branch: 25.1.1.1 and earlier fixed in 25.1.1.2, 25.1.2.2 and earlier fixed in 25.1.3.0 and 25.1.3.1, and 22.8R2.4 and earlier fixed in 22.8R2.5. The 25.1.1.2 entry does not appear in the CVE record’s unaffected list, so confirm it against Ivanti’s advisory before you rely on it.

CVE-2026-111357 and CVE-2026-118527 have no fixed version that we could confirm. When Ivanti disclosed CVE-2026-104935 on 13 October, it fixed two stages of the chain. The Register and The Hacker News both reported that a third flaw, the privilege escalation, had no fix yet, and quoted Volexity saying Ivanti planned to fix it “in the coming weeks”.

Since then:

• The only CVE record for CVE-2026-111357 is MITRE’s. It lists 22.8R2.4 as affected and gives no fixed version. Its references are Volexity’s report and Ivanti’s CVE-2026-104935 advisory, not a separate Ivanti advisory.
• CVE-2026-118527 had no record in the CVE List repository when we checked on 31 October. Its KEV entry is the only primary description we found.
• Both KEV entries list Ivanti’s CVE-2026-104935 advisory as the vendor reference, and both carry CISA’s standard required action: apply vendor mitigations, or “discontinue use of the product if mitigations are unavailable”.
• Canada’s Cyber Centre updated its advisory on 16 October to say open-source reporting indicates CVE-2026-111357 is exploited. Singapore’s CSA alert, last updated 30 October, still names only CVE-2026-104935 and advises updating “to the latest versions”.

We could not read Ivanti’s advisory directly during this run, and Ivanti may have published a fix that these records do not yet reflect. Check the advisory and Ivanti’s support portal before you decide that your current version is enough.

Why 22.8R2.4 matters

According to The Hacker News’s summary of Volexity’s report, Volexity found the chain on a customer appliance running 22.8R2.4, which was fully patched at the time. That is the exact version MITRE’s CVE-2026-111357 record lists as affected. Exploitation began on 3 October, ten days before disclosure.

Volexity tracks the actor as UTA0576. The same reports say the attacker:

• stole LDAP domain credentials from the appliance, searched Active Directory for passwords and ran password-spraying attacks;
• used no malware or web shells, only commands already on the appliance (per The Register);
• was assessed by Volexity, with low confidence, as criminally rather than espionage motivated.

Two vendor statements limit how much you can learn from the appliance itself. Rapid7 quotes Ivanti saying “reliable indicators of compromise are not available”. The Hacker News reports Volexity saying the Ivanti Integrity Checker Tool does not detect this chain, even though Ivanti still recommends running it regularly.

Triage checklist

1. Inventory. List every Connect Secure appliance and its exact version, including standby units and lab boxes that face the internet.
2. Close the entry point. Upgrade anything below the fixed versions for CVE-2026-104935 (see above). This is the unauthenticated step. KEV describes the other two flaws as needing an authenticated or local attacker.
3. Assume compromise on exposed 22.8R2.4-and-earlier appliances. If an appliance ran a vulnerable version on the internet during October, patching does not undo what an attacker already did. Neither Ivanti nor Volexity has said that upgrading removes existing access.
4. Rotate what the appliance knows. Volexity saw LDAP credentials stolen. Rotate the directory bind account and any other service credentials stored on the appliance, and review VPN user sessions and tokens. This is our recommendation, based on the reported attacker behavior. Our explainer on why MFA does not always stop token theft covers the session side.
5. Hunt outside the appliance. With no reliable on-box IOCs, the useful signals are in your other logs:
   • password spraying or bursts of failed authentications from the appliance’s internal IP against Active Directory;
   • LDAP queries from the appliance that go beyond its normal user lookups;
   • in web or WAF logs in front of the appliance, large numbers of requests to /dana-na/auth/url_default/welcome.cgi, and requests whose X-DSCGI-PATH header does not match the URL path (both indicators Volexity published, as reported by The Hacker News);
   • traffic to or from 108.165.147[.]64, the IP Volexity listed.
6. Escalate to forensics if you find anything. Volexity says confirming compromise needs network and memory forensics. Our guide to CISA BOD 26-04 explains what the KEV “forensic triage” flag asks of federal agencies and what private teams can borrow from it.
7. Decide on exposure while you wait. Until a fix for CVE-2026-111357 is confirmed, limit who can reach the appliance where you can. KEV’s own fallback is to stop using the product if mitigations are unavailable. Our post on the FortiMail zero-day with no patch walks through the same decision for another edge device.

Limits of this article

• We did not test any of these flaws, and we have not seen exploit code.
• We could not fetch Ivanti’s advisory or Volexity’s report directly. Version and fix details come from the CVE records, CISA KEV data and Rapid7’s reproduction of the advisory. Attacker behavior and indicators come from press summaries of Volexity’s findings, which we attribute throughout.
• CVE-2026-118527 had no CVE record when we checked, so its description rests on one source, CISA’s KEV entry.
• Fix status can change quickly. Treat “no confirmed fix” as true for 31 October 2026 only.

Sources and verification

CVE-2026-97229 is a remote code execution bug in self-managed GitLab Community and Enterprise Edition. GitLab’s 19.4.2 patch release says it “could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation.” GitLab scores it CVSS 3.1 10.0. CISA added it to the Known Exploited Vulnerabilities catalog on October 29, 2026, with a due date of November 1.

If you run self-managed GitLab, do two things today: upgrade to the October 21 patch release for your branch (not just the October 12 one), and check for signs that someone got there first.

What is affected and what fixes it

CVE-2026-97229 is one of four GitLab CVEs that trace back to bugs in Onigmo, the regular expression engine inside Ruby. GitLab fixed them in three patch releases between September and October. Ruby’s own advisory of October 23 ties them together.

Only CVE-2026-97229 is in KEV today. CISA’s SSVC entries in the CVE records list Exploitation as “active” for CVE-2026-97229 and “none” for the other three, as of the dates CISA recorded them. CVE-2026-110264 is also unauthenticated and rated 10.0, and its range reaches back to GitLab 7.0, so treat it with the same urgency.

Upgrade target: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, or anything later on the same branch. If you are on a branch older than 18.11, there is no backport; move to a supported branch. GitLab’s 19.5.1 release post lists no workaround, only “upgrade to the latest version as soon as possible.”

GitLab.com and GitLab Dedicated are already patched, according to both release posts. This is a self-managed problem.

Check a version quickly

The Version API returns the running version (GET /api/v4/version with a token). The script below compares a version string against the affected ranges in the four CVE records. We ran it with Python 3.13; the output shown is real.

#!/usr/bin/env python3
"""Check a GitLab version against the four Onigmo regex CVEs.
Fixed versions come from each CVE record's 'affected' ranges (read 2026-10-30)."""
import re, sys

FIXED = {  # CVE -> {(major, minor): first fixed patch}
    "CVE-2026-89078":  {(19, 2): 7, (19, 3): 3, (19, 4): 1},
    "CVE-2026-93577":  {(19, 2): 7, (19, 3): 3, (19, 4): 1},
    "CVE-2026-97229":  {(19, 2): 8, (19, 3): 5, (19, 4): 2},
    "CVE-2026-110264": {(18, 11): 13, (19, 0): 10, (19, 1): 9, (19, 2): 9,
                        (19, 3): 6, (19, 4): 3, (19, 5): 1},
}
OLD_RANGE_START = {"CVE-2026-110264": (7, 0)}  # affected from 7.0, no fix before 18.11

def check(ver):
    major, minor, patch = map(int, re.match(r"(\d+)\.(\d+)\.(\d+)", ver).groups())
    branch, out = (major, minor), {}
    for cve, fixes in FIXED.items():
        if branch in fixes:
            out[cve] = "FIXED" if patch >= fixes[branch] else f"VULNERABLE (fixed in {major}.{minor}.{fixes[branch]})"
        elif branch > max(fixes):
            out[cve] = "FIXED (newer branch)"
        elif cve in OLD_RANGE_START and branch >= OLD_RANGE_START[cve]:
            out[cve] = "VULNERABLE (no fix on this branch)"
        else:
            out[cve] = "not in affected range"
    return out

for v in sys.argv[1:]:
    print(v)
    for cve, status in check(v).items():
        print(f"  {cve:16} {status}")

$ python3 check_gitlab_regex_cves.py 19.4.2-ee 18.9.4
19.4.2-ee
  CVE-2026-89078   FIXED
  CVE-2026-93577   FIXED
  CVE-2026-97229   FIXED
  CVE-2026-110264  VULNERABLE (fixed in 19.4.3)
18.9.4
  CVE-2026-89078   not in affected range
  CVE-2026-93577   not in affected range
  CVE-2026-97229   not in affected range
  CVE-2026-110264  VULNERABLE (no fix on this branch)

The first result is the trap: an instance patched promptly on October 12 for the CVE that is now in KEV is still exposed to the sibling bug.

How the bug works, as far as the sources say

GitLab lets users supply regular expressions in places such as CI/CD configuration and compiles them with Ruby. Ruby’s advisory explains: “GitLab compiles regular expressions supplied by its users, such as patterns in CI configuration, with Regexp.new. GitLab found that specially crafted patterns could corrupt memory while Ruby compiles them, and that this could be turned into remote code execution on GitLab servers.”

The Ruby change behind CVE-2026-97229 (and CVE-2026-93577) is described as an “Integer overflow in the size of a compiled pattern”, fixed in ruby/ruby#19020. GitLab patched the Ruby it ships rather than waiting for a Ruby release.

GitLab says the bug is reachable by an unauthenticated user “under certain conditions” and does not spell those conditions out. The names of GitLab’s own detections (below) refer to the CI Lint feature and its GraphQL endpoint, which suggests where to look first, but that is our reading of the detection names, not a statement from GitLab. No public write-up of the exploitation we could find gives more detail; treat any blog that claims a precise attack path without citing GitLab or the reporter with caution.

Hunt: GitLab’s detections

The 19.4.2 release post lists six detections for self-managed instances, each linked to a write-up in GitLab’s gitlab-security-oss/tldr repository under Detections/platforms/GitLab/Vulnerability Detections/:

The 19.5.1 post adds two for CVE-2026-110264: “Onigmo native worker crash” and “Org mode render error burst”.

We have not reproduced these detections; use GitLab’s files for the exact log sources and queries. Practical order of work:

1. Look back before the patch date. Run the detections over logs as far back as your retention allows, up to the moment you upgraded. Worker crashes in the regex engine are not normal background noise.
2. Assume the GitLab host is a credential store. A GitLab server holds CI/CD variables, runner registration tokens, deploy keys, and access tokens. If you find hits, or you cannot rule exploitation out, rotate those secrets and review recent pipeline and runner activity. Our guide to detecting and rotating leaked API keys covers the rotation order.
3. Check for persistence. Look for new admin users, personal access tokens you did not create, new SSH keys on admin accounts, and unexpected files or processes on the host.

KEV marks this entry forensicTriage: Yes. Under CISA’s BOD 26-04 that means federal agencies must collect forensic data, not just patch; our BOD 26-04 explainer covers what that involves and what private teams can borrow.

If you run Ruby but not GitLab

Ruby released 4.0.9, 3.4.12 and 3.3.13 with fixes for all the underlying Onigmo bugs. Ruby’s advisory is precise about who is affected:

These bugs are reached only when an application compiles a regular expression from a string that an attacker controls, for example by passing it to Regexp.new, Regexp.union or Regexp.compile, or by interpolating it into a regexp literal such as /#{input}/. Applications that only use regular expressions written by their own developers are not affected.

Two points in that advisory matter for anyone building search filters, routing rules or admin “match by pattern” features:

• “Regexp.timeout does not protect against these bugs.” Timeouts address ReDoS, not memory corruption during compilation.
• “Limiting the length of patterns does not reliably protect against them either, because some of them can be triggered by short patterns.”

Ruby has not requested its own CVE IDs, so scanners may not flag your Ruby runtime. A quick way to find candidates in a codebase (illustrative, not exhaustive):

grep -rnE 'Regexp\.(new|union|compile)\(|/[^/]*#\{' --include='*.rb' app lib

Review each hit for whether the pattern can come from a user. If it can, upgrade Ruby, and consider whether users need regexes at all: plain substring or glob matching is a much smaller attack surface.

Limits of this article

• GitLab has not published the exact preconditions for unauthenticated exploitation, and we have not tested an exploit. The CI Lint connection above is inferred from detection names.
• KEV listing tells you exploitation has happened, not how widely. We found no primary source for a count of exposed or compromised instances.
• Version data comes from the CVE records as updated on 2026-10-30. If GitLab revises them, the records win over this page.

For how to weigh a KEV entry against CVSS and EPSS in your own queue, see CVSS vs EPSS vs KEV, and for reading the SSVC values quoted above, our Vulnrichment guide.

Sources and verification

CVE-2026-48356 is the Magento file-upload flaw that Sansec calls PolyShell, and it is now on CISA’s Known Exploited Vulnerabilities catalog (added October 27, 2026; federal due date November 10). Adobe shipped the fix in APSB26-73 on July 14, 2026. If your store is not on a 2026-jul build, update now. If it was exposed for any time since March, hunt as well. Attackers have used the flaw to plant webshells and to inject JavaScript loaders into CMS blocks, and an update removes neither.

What is affected and what fixes it

The table comes from Adobe’s CVE record and the APSB26-73 solution table, which agree on the fixed builds.

Two details matter here.

2.4.9 is listed as affected. Sansec’s PolyShell write-up says Adobe released the fix in 2.4.9 on May 12, 2026, and backported it to the supported release lines through APSB26-73 on July 14. Adobe’s CVE record, however, lists 2.4.9 among the affected versions and 2.4.9-2026-jul as unaffected. We have not diffed the two releases, so we can’t say which is right. The safe reading is Adobe’s: move to 2.4.9-2026-jul.

Older Open Source lines are not listed at all. Adobe lists 2.4.4 and 2.4.5 2026-jul builds only for Adobe Commerce. For Magento Open Source 2.4.5 and older, the record names neither an affected nor a fixed version. Don’t read that as safe: Sansec says every version up to 2.4.9-alpha2 is affected. If you run one of those lines, plan an upgrade and treat the server-side mitigations below as essential in the meantime.

Check what you run with bin/magento --version or composer show magento/product-community-edition (magento/product-enterprise-edition for Commerce), and compare the result with the table.

How PolyShell works

Sansec describes the flaw in the REST API’s handling of file uploads for cart item custom options, where a product option has type “file”. The most exposed routes are the unauthenticated guest-cart ones:

• POST /V1/guest-carts/:cartId/items
• PUT /V1/guest-carts/:cartId/items/:itemId

Uploaded files are written to pub/media/custom_options/quote/. Sansec says the GraphQL mutations use a different code path and are not vulnerable.

What an upload leads to depends on the server. Sansec lists code execution through an uploaded PHP file for Apache before 2.3.5 without php_flag engine 0, for stock nginx configs on 2.0.0 to 2.2.x, and for any nginx config that passes every .php request to PHP-FPM. Stored XSS is possible on versions before 2.3.5 and on custom web server configurations.

Adobe describes the same CVE differently. The CVE record says exploitation “requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page” and scores it CVSS 3.1 9.3 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N). The regional copy of the bulletin we read shows 9.6 with A:L and labels the impact “Privilege escalation”. We report both; neither changes the action. A KEV listing outranks the UI:R in the vector. Our CVSS vs EPSS vs KEV guide explains why.

What attackers have done with it

Sansec reported a mass wave on March 30, 2026: 471 stores compromised in one hour, with a backdoor named accesson.php dropped across multiple directories and loaders injected into CMS pages and static blocks. That was months before Adobe’s July backport.

On October 26, The Hacker News reported Sansec’s findings on a longer campaign: 953 stores infected since July 2025 with a JavaScript loader stored in Magento’s cms_block table. Per that report, Sansec attributes 471 of those infections to CVE-2026-48356, and about 102 more to file uploads through PolyShell or CVE-2025-54236 (SessionReaper). One store on 2.4.7-p10 with no missing core patches was compromised through a rogue administrator account. The report also describes webshells disguised as PNG files in pub/media/custom_options/quote/. The loader’s final payload is not known.

These figures are Sansec’s, as reported by The Hacker News. CISA’s catalog entry does not say who is exploiting the flaw, and lists known ransomware use as “Unknown”.

Step 1: Install the fixed build

Update to the 2026-jul build for your release line, then redeploy static content and clear caches as your normal release process requires. If you can’t update this week, do steps 2 and 3 now anyway: they limit what a successful upload can do and tell you whether one has already happened.

Sansec suggests a WAF rule that blocks the vulnerable API calls. That buys time, but it is a mitigation, not a fix.

Step 2: Make sure uploads can’t be served or executed

Magento ships deny rules for this directory. Check that your live config still has them.

nginx. The stock nginx.conf.sample in the 2.4-develop branch denies the directory and only hands named entry points to PHP. These are excerpts from that file, not a complete config:

location /media/custom_options/ {
    deny all;
}

location ~ ^/(index|get|static|errors/report|errors/404|errors/503|health_check)\.php$ {
    # ... fastcgi_pass to PHP-FPM ...
}

# Banned locations (only reached if the earlier PHP entry point regexes don't match)
location ~* (\.php$|\.phtml$|\.htaccess$|\.htpasswd$|\.git) {
    deny all;
}

The risky pattern is a hand-written or hosting-panel config with a generic location ~ \.php$ { fastcgi_pass ...; } and no deny for /media/custom_options/. With that, a PHP file uploaded to the directory is executed. Sansec recommends a deny all location for custom_options placed before any \.php$ block.

Apache. The repository ships pub/media/custom_options/.htaccess containing Require all denied (Apache 2.4) or deny from all (older). Confirm it exists on disk and that AllowOverride lets Apache read it. Sansec also recommends php_flag engine 0 there.

Neither rule stops the upload. Both stop the uploaded file from being fetched or run through the web server.

Step 3: Hunt for an existing compromise

Run these from the Magento root, or adjust the paths. Sansec published the first checks; we added the database queries.

Files in the upload directory. Customer uploads can be legitimate, but any script file there is a strong sign of compromise:

# Everything uploaded through custom options, newest first
find pub/media/custom_options/ -type f ! -name '.htaccess' -printf '%TY-%Tm-%Td %TH:%TM  %s  %p\n' | sort -r | head -50

# Script extensions there are a red flag
find pub/media/custom_options/ -type f \( -iname '*.php*' -o -iname '*.phtml' -o -iname '*.phar' \)

# The backdoor name from the March wave, anywhere in the docroot tree
find /var/www -name 'accesson.php' -type f

The October report describes webshells disguised as .png. A PNG that starts with <?php is not an image. Check with file or head -c 64 on anything recent in that directory.

Injected scripts in CMS content. The loader lives in the database, so file scans miss it. Run this against a replica or read-only connection (add your table prefix if you use one):

SELECT 'block' AS kind, block_id AS id, identifier, update_time
FROM cms_block
WHERE content LIKE '%<script%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%lanhd6549tdhse%'
UNION ALL
SELECT 'page', page_id, identifier, update_time
FROM cms_page
WHERE content LIKE '%<script%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%lanhd6549tdhse%'
ORDER BY update_time DESC;

Column names come from Magento’s Cms module schema; we checked the query’s syntax against a small SQLite copy of those tables, not against a live MySQL store. Many stores have legitimate scripts in CMS blocks, so review hits by update_time and by where the script loads from. The October report lists these loader domains: manulfie[.]click, neswnsssn[.]click, lanhd6549tdhse[.]top, additionalver[.]com and deepveindrilling[.]com. Sansec’s March write-up adds jslibrary[.]net and canevaslab[.]com. Add any you want to the LIKE list.

Admin accounts you didn’t create. One store in the October report was compromised through a rogue admin:

SELECT user_id, username, email, created, logdate, is_active
FROM admin_user
WHERE created >= '2026-03-01'
ORDER BY created DESC;

Web logs. Look for requests to the guest-cart item routes, which usually sit under /rest/V1/ or /rest/<store_code>/V1/:

grep -E '"(POST|PUT) /rest/([a-z0-9_]+/)?V1/guest-carts/[^/ ]+/items' /var/log/nginx/access.log* | head

Headless storefronts call these routes legitimately, so a hit is not proof. Line up timestamps with new files in pub/media/custom_options/quote/ and with cms_block updates.

If you find a webshell or an injected loader, treat the store as compromised. Remove the artifacts, rotate admin, database and integration credentials, check for other persistence (cron, other PHP files, modified app/etc/env.php), and consider your payment-card obligations, since these loaders run in shoppers’ browsers. Our PHP2Shell response guide covers the server-side hunt for PHP webshells in more detail.

Hardening after the patch

• Keep pub/ as the document root and let PHP run only for Magento’s named entry points. Sansec’s RCE conditions are old releases or web server configs that execute PHP files in upload directories.
• Turn off PHP execution in every writable media directory, not just this one. Our php.ini hardening guide covers related settings.
• If you don’t use file-type custom options, Sansec’s WAF suggestion is cheap: block file uploads to the guest-cart item routes.
• Monitor cms_block and cms_page for changes. A loader injected through the database survives code deploys.

Limits of this article

We did not reproduce the exploit or diff the patched releases. Affected and fixed versions come from Adobe’s CVE record and bulletin. The upload mechanics, server conditions and campaign figures come from Sansec, the latter through The Hacker News. The adobe.com/trust copy of APSB26-73 could not be retrieved during research; we used Adobe’s regional helpx copy, which shows “Last updated on 14 July 2026” and may not reflect later revisions. We ran the find and grep commands against a mock directory tree and sample log lines, and the SQL against SQLite, not against a production store.

Sources and verification

CVE-2026-109618 and CVE-2026-109619, which the security community has nicknamed “PHP2Shell”, are two memory-safety flaws in PHP’s core that can give an unauthenticated attacker remote code execution on a server running PHP for the web. The fixes are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog on October 26, 2026, and gave federal agencies until October 29 to act.

These are bugs in the PHP interpreter, so they apply regardless of your framework or CMS. If you run PHP behind a web server, update the PHP package today, restart every PHP worker, then look for signs that someone got in first. Everything below comes from the PHP project’s advisory and CVE records and CISA’s KEV entry unless we say otherwise.

Are you affected?

The CVE records list PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12 as affected. PHP’s advisory adds who is at risk: “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.” It rates mod_php highest, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”

The CVE records only list 8.2 to 8.5. Do not read that as “8.1 is safe”: PHP says 8.1 and older “no longer receive updates” and published source backports for 7.4, 8.0 and 8.1 because of the severity.

Why php -v can mislead you

Most production PHP comes from a distribution or a container base image, and those vendors backport fixes without changing the upstream version number. PHP says Linux distributions and LTS vendors “received the patches in advance”.

We checked an Ubuntu 24.04 host. php -v reports 8.3.6, which is far below 8.3.36, yet the package changelog shows the fix:

$ dpkg -l php8.3-cli | tail -1 | awk '{print $2, $3}'
php8.3-cli 8.3.6-0ubuntu0.24.04.13
$ zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | head -4
php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via

So for a distribution build, search the package changelog for the CVE IDs. On Debian or Ubuntu, zcat /usr/share/doc/php*-common/changelog.Debian.gz | grep -m1 CVE-2026-109618 works; on RPM-based systems the equivalent is rpm -q --changelog <php package> | grep CVE-2026-109618 (illustrative; we did not run the RPM form). For official php Docker images and source builds, the upstream version is the one that counts.

Also check the binary that actually serves traffic. The CLI, php-fpm and libapache2-mod-php can come from different packages and be updated at different times.

A version check for upstream builds

This script compares upstream version strings against the fixed releases. We ran it with PHP 8.3 CLI (php php2shell-check.php 8.2.34 8.4.27 8.1.31). It cannot see distribution backports, so a “VULNERABLE” result on a distro build means “check the changelog”, not “definitely exposed”.

<?php
// Compares upstream PHP versions with the fixed releases for
// CVE-2026-109618 / CVE-2026-109619. Does not detect vendor backports.
$fixed = ['8.2' => '8.2.35', '8.3' => '8.3.36', '8.4' => '8.4.27', '8.5' => '8.5.12'];

function status(string $v, array $fixed): string {
    $branch = implode('.', array_slice(explode('.', $v), 0, 2));
    if (!isset($fixed[$branch])) {
        return version_compare($v, '8.2', '<')
            ? 'END OF LIFE: no upstream fix; needs vendor backport or upgrade'
            : 'UNKNOWN branch: check php.net';
    }
    return version_compare($v, $fixed[$branch], '>=')
        ? "fixed upstream (>= {$fixed[$branch]})"
        : "VULNERABLE upstream (< {$fixed[$branch]}) unless your vendor backported the fix";
}

foreach (array_slice($argv, 1) ?: [PHP_VERSION] as $v) {
    printf("%-10s %s\n", $v, status($v, $fixed));
}

$ php php2shell-check.php 8.2.34 8.4.27 8.1.31
8.2.34     VULNERABLE upstream (< 8.2.35) unless your vendor backported the fix
8.4.27     fixed upstream (>= 8.4.27)
8.1.31     END OF LIFE: no upstream fix; needs vendor backport or upgrade

What the two flaws do

Both bugs leave PHP’s internal request state inconsistent and let later code trust it.

• CVE-2026-109618, “RCE via OOM corruption”. The CVE record says PHP “uses longjmp() for out-of-memory (OOM) errors to exit the current context”. Some code paths “leave request memory in an uninitialized state before performing an allocation”, and “the subsequent request cleanup procedure may read or branch on this memory.” An attacker who can push a request into an out-of-memory failure at the right moment can trigger it.
• CVE-2026-109619, “RCE via stale global state”. Global state that “temporarily points into request memory” may not be reset, so it “may refer to request memory even after it has been freed.” PHP’s advisory explains the consequence: “A later request handled by the same worker may use that stale state before normal initialization resets it.”

Both carry a CVSS v4.0 base score of 9.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H): network-reachable, no privileges, no user interaction, but high attack complexity with attack requirements present. If you want to decode the vector, see our guide to reading a CVSS v4.0 vector string. The fix shipped in all four branches as one change, described in PHP’s NEWS file as “Avoid state corruption via bailout”.

Credits in the CVE records name Wiz, Ryan at Calif.io and OpenAI as reporters or finders.

Exploitation status

The public picture is mixed, so here is what each source says:

CISA’s Vulnrichment SSVC entry in the CVE records, dated October 21, still says Exploitation: none. That predates the KEV listing. For how these signals usually relate, see CVSS vs EPSS vs KEV.

Our reading: mass scanning started within hours, working exploits exist, and CISA has listed both as exploited. Whether specific attacks succeeded against production servers is not yet established in public sources. That uncertainty is a reason to hunt after patching, not a reason to wait.

What to do now

1. Inventory. Find every PHP runtime that serves HTTP: VMs, containers, base images, appliances with embedded PHP, and managed hosting. Container images need a rebuild and redeploy; patching the host does nothing for them.
2. Update. Move to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or your vendor’s patched package. For 8.1 and older, use a vendor backport or upgrade. PHP 8.2 itself reaches end of life on December 31, 2026, according to PHP’s release notes, so plan that upgrade too.
3. Restart every worker. CVE-2026-109619 is about state that persists across requests in the same worker. Restart PHP-FPM pools, Apache (for mod_php) and any long-running PHP servers after the package update.
4. Prioritise internet-facing mod_php, then FPM behind public web servers, then internal applications.

If you cannot update today

PHP lists stopgaps and is explicit that “only an update is a complete solution” and these “do not make an installation safe”:

; php.ini or FPM pool config, applied before request parsing, then restart workers.
; Illustrative: check each value against your application's needs.

; CVE-2026-109618 (OOM corruption)
; In an FPM pool use php_admin_value[memory_limit] = -1 so applications can't override it.
memory_limit = -1
; 8M if the app takes no uploads, 32M if it needs them; keep upload_max_filesize below it
post_max_size = 8M
upload_max_filesize = 2M

; CVE-2026-109619 (stale global state)
session.upload_progress.enabled = 0
; PHP 8.5 only:
; fatal_error_backtraces = 0

The reasoning behind each, from the advisory:

• memory_limit=-1 “removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.” With no PHP memory limit, a container or cgroup memory limit becomes your availability boundary. PHP warns: “Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.”
• Low post_max_size, plus limits at the web server or proxy on decoded request size, field count, multipart part count, header count and nesting depth. These “must also cover requests without a usable Content-Length.”
• session.upload_progress.enabled=0 “blocks the confirmed session paths but not other variants”. Set it in php.ini, the FPM pool or server config; PHP says “Do not rely on ini_set() or FPM .user.ini.”
• Hiding errors does not help: “Hiding diagnostics with error_reporting, display_errors or @ does not help.”

php_admin_value matters here because, per the PHP-FPM documentation, “Settings defined with php_admin_value and php_admin_flag cannot be overridden with ini_set.”

What to hunt for after patching

Patching removes the bug, not an attacker who already used it. Preserve web server and PHP logs before you rotate or rebuild anything. The indicators below come from VulnCheck’s published honeypot observations. They describe scanners and one attempt; real attackers can change every one of them.

• User agents: php2shell-scan/109618, php2shell-verify/1.0, Mozilla/5.0 (php2shell-poc).
• Requests: multipart POSTs to /index.php that upload two files named a and b through the upload-progress path; follow-up GET requests using php://filter to read a session file.
• Session files containing PHP code. The attempt VulnCheck saw tried to plant a webshell through a session file, with a payload that prints PWNED::. A legitimate PHP session file contains serialized data, never <?php.

Two checks you can run on a Linux host. We tested both against sample files; adjust paths to your log format and to the session.save_path of the pool that serves traffic (php -i shows the CLI’s value, not necessarily FPM’s):

# Web logs: known scanner user agents and php://filter reads
grep -hE 'php2shell|php://filter' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null

# Session files that contain PHP code or the test marker
grep -lE '<\?php|PWNED::' /var/lib/php/sessions/sess_* 2>/dev/null

Then do the usual post-compromise checks for a web server: new or changed .php files under the document root since October 17, unexpected child processes of the PHP worker or web server user (shells, curl, wget), and outbound connections from web hosts. Our guide to logging for incidents covers which of these you will wish you had recorded.

Federal agencies have to follow CISA’s forensic triage requirements for this KEV entry. If you want to borrow that process, our explainer on CISA BOD 26-04 covers it.

Limits of this article

We have not read the full GitHub security advisories, which PHP says contain the technical details; they were not reachable from our research environment. Exploitation reporting comes from vendors and press summaries we cite, not from our own telemetry. The hunting indicators come from one vendor’s honeypots and will not catch a modified attack. Exposure counts published by vendors differ widely, so we have not repeated them.

Sources and verification

CVE-2026-0322 is a code injection vulnerability in the management interface of Palo Alto Networks PAN-OS. An attacker who is authenticated and can reach that interface over the network can execute arbitrary code with root privileges on the firewall. It affects PA-Series and VM-Series firewalls and Panorama, there is no workaround, and Palo Alto Networks says it has observed “very limited exploitation”. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on October 14, 2026, and gave federal agencies until October 17 to act.

If you run PAN-OS, find your exact version, upgrade to the matching fixed release below, and use the upgrade window to check who can reach the management interface at all. Everything in this article comes from Palo Alto Networks’ CVE record and CISA’s KEV entry unless we say otherwise.

Are you affected?

You are affected if you run PAN-OS on a PA-Series or VM-Series firewall, or Panorama (virtual or M-Series), and your version is below the fixed release for its maintenance range. Palo Alto Networks says “no special configuration is required to be affected”. Cloud NGFW and Prisma Access are not impacted.

This is the solutions table from the CVE record as published on October 14, 2026. Two details are easy to miss. First, a hotfix only fixes its own maintenance release: 11.1.4-h37 is fixed, but 11.1.5 is not, because 11.1.5 sits in the next row with its own fix (11.1.6-h39). Second, the record’s affected range for 12.1 starts at 12.1.0, while the solutions table starts at 12.1.2; if you are on 12.1.0 or 12.1.1, move to 12.1.10-h2. Branches older than 10.2 are not listed; check the Palo Alto Networks advisory for their status.

Check a list of versions

With a fleet, a lookup beats reading the table by eye. This Python 3 script encodes the table above. We checked it against the record: its 20 in-line fixes are the same set as the 20 changes entries in the record’s affected data, and its per-branch upper bounds match the record’s lessThan values. We ran it on Python 3 with the versions shown.

#!/usr/bin/env python3
"""Check PAN-OS versions against the CVE-2026-0322 fix table (CVE record, 2026-10-14).
Usage: python3 check_0322.py 11.1.6-h20 10.2.18-h12 ..."""
import re, sys

# (first version in range, last minor in range, in-line fix, newest fix on the branch)
ROWS = [
    ("12.2.0", "12.2.3", "12.2.4", "12.2.4"),
    ("12.1.8", "12.1.10", "12.1.10-h2", "12.1.10-h2"),
    ("12.1.5", "12.1.7", "12.1.7-h8", "12.1.10-h2"),
    ("12.1.2", "12.1.4", "12.1.4-h12", "12.1.10-h2"),
    ("11.2.14", "11.2.15", "11.2.16", "11.2.16"),
    ("11.2.11", "11.2.13", "11.2.13-h3", "11.2.16"),
    ("11.2.8", "11.2.10", "11.2.10-h15", "11.2.16"),
    ("11.2.5", "11.2.7", "11.2.7-h21", "11.2.16"),
    ("11.2.0", "11.2.4", "11.2.4-h22", "11.2.16"),
    ("11.1.14", "11.1.16", "11.1.16-h3", "11.1.16-h3"),
    ("11.1.11", "11.1.13", "11.1.13-h15", "11.1.16-h3"),
    ("11.1.8", "11.1.10", "11.1.10-h35", "11.1.16-h3"),
    ("11.1.7", "11.1.7", "11.1.7-h11", "11.1.16-h3"),
    ("11.1.5", "11.1.6", "11.1.6-h39", "11.1.16-h3"),
    ("11.1.0", "11.1.4", "11.1.4-h37", "11.1.16-h3"),
    ("10.2.17", "10.2.18", "10.2.18-h12", "10.2.18-h12"),
    ("10.2.14", "10.2.16", "10.2.16-h11", "10.2.18-h12"),
    ("10.2.11", "10.2.13", "10.2.13-h26", "10.2.18-h12"),
    ("10.2.8", "10.2.10", "10.2.10-h41", "10.2.18-h12"),
    ("10.2.0", "10.2.7", "10.2.7-h38", "10.2.18-h12"),
]
# "lessThan" bound of each affected range in the record's affected[] data
LESS_THAN = {"12.2": "12.2.4", "12.1": "12.1.10-h2", "11.2": "11.2.16",
             "11.1": "11.1.16-h3", "10.2": "10.2.18-h12"}

def key(v):
    m = re.fullmatch(r"(\d+)\.(\d+)\.(\d+)(?:-h(\d+))?", v.strip())
    if not m:
        raise ValueError(f"unrecognised version: {v}")
    a, b, c, h = m.groups()
    return (int(a), int(b), int(c), int(h or 0))

def check(v):
    k = key(v)
    for start, last, fix, newest in ROWS:
        if key(start) <= k and k[:3] <= key(last)[:3]:
            if k >= key(fix):
                return f"{v}: fixed (in-line fix {fix})"
            return f"{v}: AFFECTED -> upgrade to {fix}" + ("" if fix == newest else f" or {newest}")
    branch = ".".join(map(str, k[:2]))
    if branch in LESS_THAN:
        if k >= key(LESS_THAN[branch]):
            return f"{v}: not affected (at or above {LESS_THAN[branch]})"
        return f"{v}: AFFECTED per the record, no row in the fix table -> {LESS_THAN[branch]}"
    return f"{v}: branch {branch} not listed in the CVE record (check the advisory)"

for v in sys.argv[1:]:
    print(check(v))

Sample output from our run:

$ python3 check_0322.py 11.1.6-h20 11.2.15 10.2.18-h12 12.1.1 10.1.14
11.1.6-h20: AFFECTED -> upgrade to 11.1.6-h39 or 11.1.16-h3
11.2.15: AFFECTED -> upgrade to 11.2.16
10.2.18-h12: fixed (in-line fix 10.2.18-h12)
12.1.1: AFFECTED per the record, no row in the fix table -> 12.1.10-h2
10.1.14: branch 10.1 not listed in the CVE record (check the advisory)

To get the input, read the running software version from each firewall and Panorama: on the CLI, show system info is the usual place to look (illustrative; we did not run it against a device). Feed those values to the script, and remember to include Panorama itself.

What the vulnerability does

The record classifies the flaw as CWE-94, improper control of generation of code (“code injection”). Its title is “Authenticated Remote Code Execution (RCE) in the Management Interface”, and the impact is code execution “with root privileges on the firewall”. Palo Alto Networks found it internally; the record credits an internal reporter and gives no technical detail of the vulnerable code path.

Palo Alto Networks publishes two CVSS v4.0 scores for two deployment scenarios:

Both vectors carry E:A (attacked), AU:N (not automatable) and U:Red. If you want to read the vector strings metric by metric, our guide to CVSS v4.0 vectors walks through each field.

The small gap between the two scores understates the operational difference. Restricting the interface to a jump box does not fix the bug, but it shrinks the set of places an attacker can attempt it from to one host you control and monitor.

“Authenticated” does not mean “safe to wait”

The CVSS vectors rate privileges required as High, so an attacker needs a valid management login. That is a real barrier, but not a high one when the interface is reachable. Speaking to CSO Online, IDC analyst Yih Khai Wong pointed to “weak management-access hygiene”: administrator credentials stolen through phishing or reuse, internet-reachable management interfaces, or an earlier compromise that left the attacker with valid logins.

PAN-OS management and edge services have a history here. CISA’s KEV catalog lists 16 Palo Alto Networks entries, including two management-interface flaws added on the same day in November 2024: CVE-2024-0012, an authentication bypass, and CVE-2024-9474, an OS command injection. In 2026 alone, CVE-2026-0322 is the third PAN-OS entry, after CVE-2026-0300 (an unauthenticated buffer overflow in the User-ID Authentication Portal, added May 6) and CVE-2026-0257 (a GlobalProtect authentication bypass, added May 29, which CISA marks as known to be used in ransomware campaigns). None of those records links them to CVE-2026-0322. The point is simpler: if your management access depends on nobody having a valid password, it is weaker than it looks.

Exploitation status

What the primary records say:

• Palo Alto Networks: “Very limited exploitation has been observed targeting the Palo Alto Networks management interface.” The record’s initial publication time is October 14, 2026, 16:00 UTC.
• CISA KEV: added October 14, 2026; due date October 17; known ransomware campaign use “Unknown”; forensic triage flag “Yes”. The required action points to BOD 26-04 and its forensic triage requirements.
• CISA SSVC (in the CVE record): Exploitation “active”, Automatable “no”, Technical Impact “total”. Our explainer on Vulnrichment SSVC values covers how to turn those into a patch decision.

What is reported but we could not confirm at the source: BleepingComputer reported that Palo Alto Networks shared three IP addresses linked to the activity, 66.42.72[.]14, 208.83.239[.]114 and 149.248.47[.]234. The Hacker News lists the same three as “assessed to be linked to the exploit attempts”. We did not read them on the advisory page itself, so treat them as reported indicators, and check the advisory for the current list. Neither outlet describes what attackers did after exploitation, and Palo Alto Networks has not said who is behind it or when it began.

What to do now

1. Upgrade to the fixed release for your maintenance range, firewalls and Panorama both. There is no workaround.
2. Preserve evidence before you upgrade if the management interface was reachable from anywhere you do not fully control. Export system, configuration and authentication logs, and take a tech support file, so the upgrade does not become the only record of the device’s state.
3. Restrict who can reach the management interface. Palo Alto Networks’ administrative access guidance says: “Do not enable access to your management interface from the internet or from other untrusted zones”, “Isolate the management interface on a dedicated management VLAN” and “Restrict the IP addresses that are permitted to access the management interface”. On the firewall this is the Permitted IP Addresses list on the management interface (Device > Setup > Interfaces > Management in the PAN-OS admin guide). An empty list allows access from any IP address.
4. Check dataplane interfaces too. If you manage the firewall through an interface management profile on a data port, restrict it the same way. The guidance is explicit that a profile allowing HTTP, HTTPS, Telnet or SSH must not be attached to an interface where a GlobalProtect portal or gateway is configured, because that exposes management to the internet.
5. Tighten administrator accounts. One account per person, the default admin password changed, and MFA through external authentication for administrators with change privileges. Rotate credentials for any administrator who logged in from outside the management network recently.
6. Use the Threat IDs only as a stopgap. Threat IDs 510046 and 510047 (Applications and Threats content 9159-10287 and later) offer what Palo Alto Networks calls limited coverage. They only work if management traffic is routed through a dataplane port with a management profile, its certificate is replaced, inbound management traffic is decrypted, and threat prevention is applied to it.

What to review after patching

Upgrading closes the hole; it does not tell you whether someone used it. Root code execution on a firewall means an attacker could have changed configuration, added accounts, or used the device as a foothold. Scope the review from the earliest date you think the interface was exposed, and at least from early October 2026.

As illustrative starting points in the PAN-OS CLI, show admins all lists administrators and their sessions, and show log system and show log config read the system and configuration logs. Check the CLI reference for your release for filters and exact syntax; we did not run these against a device.

If you find activity you cannot explain, treat the device as compromised rather than just patched: rebuild from a known-good configuration, rotate every credential and key the firewall holds (administrator passwords, API keys, certificates, VPN and directory service secrets), and involve Palo Alto Networks support. Our incident logging guide covers what to keep while you do.

Limits of this article

We did not test the vulnerability or run the CLI commands on a PAN-OS device. The fixed-release table and checker come from the CVE record as published on October 14, 2026; Palo Alto Networks can update the advisory, so check it before you finalise a change. The three IP addresses come from press reports, not from our reading of the advisory. Palo Alto Networks has not published technical details of the flaw or of the exploitation it observed.

Sources and verification

A Kubernetes audit policy is the file that tells kube-apiserver which API requests to record and how much of each to keep. Without one, upstream kube-apiserver records nothing. A good policy logs everything at Metadata at minimum, keeps request bodies for changes that alter access, and never logs the contents of Secrets. Rule order is what makes that work: the first matching rule wins, and a broad rule placed too high will quietly write Secret values into your logs. We demonstrate that below.

This guide gives a six-rule policy we ran against kube-apiserver v1.34.1, shows what each rule captured, and ends with queries you can run against the log during an incident.

How kube-apiserver evaluates a policy

Every request produces audit events at one or more stages:

The policy is a list of rules. kube-apiserver compares each event with the rules in order, and the first rule that matches sets the event’s level:

Request and RequestResponse don’t apply to non-resource URLs such as /healthz. A rule can match on users, userGroups, verbs, resources (group, resource, subresource and resourceNames), namespaces and nonResourceURLs. A rule with no match fields matches everything, which is what you want for the last rule and exactly what you don’t want near the top.

The policy file is passed with --audit-policy-file. If the flag is omitted, no events are logged, and a policy with no rules is rejected.

A policy that answers incident questions

The policy below is built around the questions you get asked during an incident: who read this Secret, who exec’d into that Pod, who granted this binding, and was it allowed. It is a starting point, not a complete production policy; see the limits at the end.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  # 1. Drop health and version probes.
  - level: None
    nonResourceURLs: ["/healthz*", "/livez*", "/readyz*", "/version"]
  # 2. Sensitive payloads: who touched them, never the contents.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "serviceaccounts/token"]
      - group: "authentication.k8s.io"
        resources: ["tokenreviews"]
  # 3. Interactive access into running workloads.
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach", "pods/portforward", "pods/proxy", "nodes/proxy"]
  # 4. Changes to who can do what, and to admission control.
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete", "deletecollection"]
    resources:
      - group: "rbac.authorization.k8s.io"
      - group: "admissionregistration.k8s.io"
  # 5. Other writes: keep the submitted object.
  - level: Request
    verbs: ["create", "update", "patch", "delete", "deletecollection"]
  # 6. Everything else (reads, watches, non-resource URLs).
  - level: Metadata

Why each rule is where it is:

Pod Security Admission and our RBAC permission audit tell you what could happen. The audit log is how you find out what did.

What it recorded

We ran the policy on kube-apiserver v1.34.1 (the envtest build from the kubernetes-sigs/controller-tools releases) with etcd and RBAC authorization, then made requests as a system:masters user and as an unprivileged user alice. There were no nodes, so no Pod actually ran. Results:

Two details from the test are worth building detections around:

• Exec shows up under more than one verb. That single kubectl exec produced events with verb get and verb create for the exec subresource. Filter on objectRef.subresource == "exec", not on the verb.
• Impersonation keeps both identities. The authenticated user is in user and the identity they acted as is in impersonatedUser. If you only alert on user.username, impersonated actions look like they came from the admin’s own account.

Also keep in mind what the API reference warns about two fields: userAgent is reported by the client “and must not be trusted”, and in sourceIPs all entries except the last “can be arbitrarily set by the client”.

The rule-order mistake that leaks Secrets

We then moved rule 5 (Request for all writes) above rule 2, restarted kube-apiserver with that policy, and created a Secret with the value S3cretValue-456. The audit log now contained:

"data":{"key":"UzNjcmV0VmFsdWUtNDU2"}

That is the base64 encoding of S3cretValue-456. The broad write rule matched first, logged the request body at Request level, and the Metadata rule for Secrets was never reached. With the correct order, the equivalent test (a Secret holding S3cretValue-123) left no trace of either the plain or the encoded value in the log.

This is the most common way an audit log becomes a credential store. Your audit pipeline usually has wider read access than the cluster’s Secrets do, so treat a body-logging rule above your Secrets rule as a bug. Check it in code review with a simple test: create a dummy Secret in a test cluster and search the log for its encoded value.

If you already store Secrets encrypted at rest, remember that encryption protects etcd, not the audit log. And a Secret-based service account token leaked this way never expires.

Backends and volume

There are two backends: a log file and a webhook.

• Log backend: --audit-log-path sets the file (- means stdout). Rotation is controlled by --audit-log-maxage (days), --audit-log-maxbackup (files) and --audit-log-maxsize (megabytes). Batching is off by default for the log backend.
• Webhook backend: --audit-webhook-config-file points at a kubeconfig-format file for the remote endpoint. Batching is on by default, with a maximum of 400 events per batch and a 30-second maximum wait.
• Truncation of oversized events is off by default for both backends and has to be enabled explicitly.

The Kubernetes docs also note that auditing increases API server memory use, because some context is kept for each request, and that the increase depends on the policy. RequestResponse on a busy resource is where cost grows: the GCE reference policy, for instance, logs get, list and watch at Request level rather than RequestResponse because “Get responses can be large”.

Ship the log off the control plane. An attacker with control-plane access can edit a local file, and an incident log is only useful if it survives the incident.

Managed Kubernetes

On EKS, AKS and similar services the provider runs kube-apiserver, so you generally choose whether audit events are exported, not what the policy contains. Check your provider’s documentation for what its policy logs.

• Amazon EKS: control plane logs are not sent to CloudWatch Logs by default. Enable the audit log type per cluster, for example with aws eks update-cluster-config --logging. The audit stream is named kube-apiserver-audit-<id> in the /aws/eks/<cluster>/cluster log group. AWS notes delivery is best effort and standard CloudWatch Logs charges apply.
• Azure AKS: resource logs are not collected until you create a diagnostic setting. Microsoft’s guidance warns that kube-audit can be costly and suggests kube-audit-admin, which leaves out get and list events. That saves money but drops exactly the read events, such as Secret reads, that matter in a credential-theft investigation. Decide that trade-off deliberately.

Queries to keep ready

These run against a JSON-lines audit log with jq. We ran each one against the log from the test above.

# Who read or changed Secrets (excluding the API server itself)
jq -c 'select(.objectRef.resource=="secrets" and .user.username!="system:apiserver")
  | {ts:.requestReceivedTimestamp, user:.user.username, verb, ns:.objectRef.namespace,
     name:.objectRef.name, code:.responseStatus.code}' audit.log

# Every exec into a Pod, with the command line
jq -c 'select(.objectRef.subresource=="exec")
  | {ts:.requestReceivedTimestamp, user:.user.username, ns:.objectRef.namespace,
     pod:.objectRef.name, uri:.requestURI}' audit.log

# Denied requests, including impersonated ones
jq -c 'select(.annotations["authorization.k8s.io/decision"]=="forbid")
  | {user:.user.username, as:.impersonatedUser.username, verb,
     res:.objectRef.resource, ns:.objectRef.namespace}' audit.log

# RBAC writes by people rather than the control plane, with what they granted
jq -c 'select(.objectRef.apiGroup=="rbac.authorization.k8s.io"
       and (.verb|test("create|update|patch|delete"))
       and (.user.username|startswith("system:")|not))
  | {user:.user.username, verb, res:.objectRef.resource, name:.objectRef.name,
     subjects:.requestObject.subjects, role:.requestObject.roleRef.name}' audit.log

A burst of forbid events from one identity across many resources can be a sign that someone is enumerating what a stolen credential can do.

Limits of this article

We tested on a single kube-apiserver v1.34.1 with no nodes, no controller manager and static token authentication, so no workload actually ran and no kubelet or controller traffic was present. A real cluster produces far more events, and you will want extra None or Metadata rules for high-volume system traffic (the GCE policy is a good reference). The policy does not cover custom resources that hold credentials; add those to rule 2. Request level on Pod writes will log any credentials placed directly in environment variables. We did not test the webhook backend or any managed service.

Sources and verification

CVE-2026-114625 is a SQL injection in on-premises Arista VeloCloud Orchestrator (VCO) that lets any authenticated portal user gain operator privileges and act as the local “superuser operator”. The lowest built-in tenant role, Enterprise Read Only, is enough. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on October 23, 2026. Upgrade to VCO 5.2.3.18, 6.1.3.10 or 6.4.2.12 or later, restrict the web interface to administrative networks until you can, and then check the orchestrator for signs that someone used it before you did.

It is also the third exploited VCO vulnerability in three months. If you patched in July or September and stopped there, you are still exposed.

Are you affected?

You are affected if you run VCO on-premises on one of these versions, as listed in Arista’s CVE record:

Arista says hosted VCO, including Dedicated, was affected and has already been patched. The record lists no 7.0 range for this CVE and marks unlisted versions as unaffected, but Arista’s September advisory did list 7.0 builds as affected by an earlier flaw. If you run 7.0, confirm your status with Arista rather than relying on the absence of a row. With the July flaw, Arista said it had not assessed end-of-support releases, so if you are on an older train, ask Arista’s Technical Assistance Center (TAC) about upgrade paths.

VCO is the management plane for VeloCloud SD-WAN. It holds configuration, device inventory and credentials for the Edges it manages, so treat it as a tier-0 system even if it doesn’t look like one in your asset inventory.

What the vulnerability does

Arista’s description in the CVE record: on an affected system, “any authenticated user can gain operator privileges and masquerade as a local ‘superuser operator’ user”. That includes functionality meant for internal use only and not meant to be reachable remotely. The record classifies it as CWE-89 (SQL injection).

The conditions, per the record’s configuration notes:

• VCO is exposed by default, and “there is no configuration that can prevent the exposure”.
• The attacker needs network access to the VCO web interface.
• The attacker needs a valid authenticated session on the VCO portal. The minimum role is Enterprise Read Only.

That last condition matters more than it first appears. In a multi-tenant VCO, a read-only user at one customer or one business unit could reach operator-level control over the whole orchestrator. Every tenant login, including service accounts, shared logins and accounts left behind by former staff or partners, is a possible starting point.

Arista scores it CVSS 3.1 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) and CVSS 4.0 9.4. The PR:L (low privileges required) is the only thing keeping it off 10.0. The record says the issue was discovered externally. Arista published Security Advisory 0199 and the CVE record on October 22, 2026.

Exploitation status

The evidence of exploitation comes from CISA rather than from Arista’s CVE text:

• KEV: CISA added CVE-2026-114625 on October 23, 2026, with a due date of October 26, 2026 for US federal civilian agencies. The entry has the forensic triage flag set, so under BOD 26-04 agencies must also check for compromise, not just patch. Known ransomware use is listed as “Unknown”.
• SSVC: CISA’s Vulnrichment entry in the CVE record, timestamped October 22, rates Exploitation active, Automatable no and Technical Impact total. If you use the SSVC deployer model, “active” plus “total” puts an internet-facing VCO at the top of the queue even though the flaw needs a login.

Arista’s records for the July and September VCO flaws said explicitly that they were “known to be actively exploited”. The October record does not, and at the time of writing we found no public detail on who is exploiting this one or how. Treat attribution and scale as unknown.

Third exploited VCO flaw since July

CISA’s KEV catalog now lists three VeloCloud Orchestrator vulnerabilities, all added in 2026:

Each fix moved the floor. We checked a set of common builds against the affected ranges in all three CVE records:

That table was generated by comparing each build to the affected version ranges in the three CVE JSON records from the CVEProject/cvelistV5 repository. It reflects what the records say, not testing against a VCO. Arista’s September advisory did not list a fixed 6.1 or 7.0 build for CVE-2026-93952 when it was published, so for those trains check Arista’s current advisory before assuming you’re clear.

The practical point: an orchestrator that was patched once and then left alone has been inside at least one exploited vulnerability window for most of the last three months. That changes the hunting question from “was I hit last week?” to “has this box been clean since July?”

What to do now

1. Find every VCO you run. Include lab, DR and acquired-company instances. Record version, train and whether the web interface is reachable from the internet.
2. Restrict the web interface to trusted administrative networks now, before the upgrade window. This is Arista’s first interim control. It does not remove the risk from users who already have access.
3. Upgrade to 5.2.3.18, 6.1.3.10 or 6.4.2.12 or later. If you are on 7.0 or an unsupported train, open a case with Arista TAC.
4. Preserve evidence first if anything below looks wrong. Arista’s September advisory asks for web access logs, application and system logs, database logs and file-system timestamps to be kept before remediation. An upgrade can overwrite exactly the files you need.
5. Cut back portal accounts. Remove dormant tenant users, rotate shared credentials, and check that partner and MSP accounts are still needed. This flaw turns every one of them into a path to operator rights.
6. Block outbound traffic from the VCO host that normal operation doesn’t need. Arista lists this in the October workarounds.

For the wider prioritization question, our guide to matching the KEV feed against a scanner export shows how to catch the next one automatically.

How to hunt

Arista’s October record lists the same detection areas as its earlier VCO advisories: access from known malicious IPs, unexpected outbound network activity from the VCO host, backdoor daemons and web shells, and unexpected administrator activity. It does not publish indicators specific to CVE-2026-114625.

Arista did publish concrete indicators with the September flaw, CVE-2026-93952 (Security Advisory 0183). Arista has not said they are linked to the October issue. Because most builds vulnerable today were also exposed to CVE-2026-93952, they are a sensible baseline:

A starting point on the VCO host, run as root. This is illustrative and was not tested against a VCO; adjust log paths to your build:

# Persistence files named in Arista advisory 0183
ls -la /usr/local/sbin/.vcnode.js /usr/local/sbin/vc-sysmond \
       /etc/systemd/system/vc-sysmon.service 2>/dev/null
md5sum /usr/local/sbin/vc-sysmond 2>/dev/null

# Header and source IPs from the same advisory in nginx logs
zgrep -il 'x-vc-opt' /var/log/nginx/*access* 2>/dev/null
zgrep -hE '142\.93\.149\.77|104\.248\.126\.159' /var/log/nginx/*access* 2>/dev/null | head

# Unexpected outbound connections from the orchestrator
ss -tnp state established

Beyond file indicators, Arista’s advisories point to behavior worth reviewing in the VCO’s own audit trail:

• operator-level actions taken by accounts that only hold tenant roles, or by the local superuser operator at times nobody on your team was working
• sensitive configuration changes or privileged maintenance actions with no matching change ticket
• database exports, new archive files, or unexpected access to device inventory, certificates and keys
• configuration pushed to Edges that you did not approve

If you find a compromise, Arista’s guidance from the earlier advisories applies: rotate credentials, validate the state of every managed Edge, and restore or replace the orchestrator from a trusted source. Patching a compromised VCO does not remove an attacker who is already there.

Limits of this article

We could not retrieve Arista’s Security Advisory 0199 page directly. The affected versions, conditions, workarounds and description above come from the CVE record Arista published as the CNA, which carries the advisory’s content. We have not tested any VCO build, and the hunting commands are a starting point, not a validated detection. There is no public technical write-up of the exploit at the time of writing.

Sources and verification

If your Nextcloud server runs the Collabora Online - Built-in CODE Server app (richdocumentscode) at any version before 26.4.303, treat it as exposed to unauthenticated remote code execution. Update the app to the current release or remove it today, then hunt for web shells: the fix shipped on September 11, 2026, attacks were reported from September 10, and the CVE was not published until October 14. CISA added CVE-2026-110447 to its Known Exploited Vulnerabilities (KEV) catalog on October 23, with a due date of October 26 for US federal civilian agencies.

Are you affected?

The CVE record is specific: the flaw is “not present in standalone Collabora Online servers; only this deployment with CODE Server is affected.”

The two app names are easy to confuse. richdocuments is the Nextcloud Office connector. richdocumentscode is the optional app that bundles a CODE (Collabora Online Development Edition) AppImage and starts it on the Nextcloud host. Only the second is in scope.

Check which you have from the Nextcloud directory:

# Run as the web server user; adjust the user and path for your install
sudo -u www-data php occ app:list | grep -E 'richdocuments(code)?:'

The vulnerability

The AT:P (attack requirements present) in the vector reflects that precondition: the bundled server has to be down. That is less of a barrier than it sounds. Restarts, app upgrades and crashes all stop it, and in the vulnerable code an unauthenticated ?status request to proxy.php is what asks for the server to be started when it is not running. If you are new to v4.0 vectors, our guide to reading a CVSS v4.0 vector string walks through each metric.

The CVE record also says this is “a different vulnerability than CVE-2025-66208”, so a host patched for that earlier issue is not covered.

What the fix changed

The CVE record describes the bug only as command injection in proxy.php. The app’s public repository shows more. This section is our reading of that source, not a vendor statement.

In 26.4.302, startCoolwsd() built the launch command as one string. Two values derived from the request, the HTTP Host header and the request URI (used to build a font-configuration URL), were each passed through PHP’s escapeshellarg(), which wraps them in single quotes. The whole command was then placed inside a double-quoted bash -c "..." string and handed to the shell. Single quotes have no special meaning inside double quotes, so shell command substitution in those values was still evaluated by the outer shell.

The 26.4.303 change, committed on September 9, wraps the entire inner command in escapeshellarg() before passing it to bash -c. The current code goes further: it passes an argument array to proc_open() and runs a fixed script that receives the options as "$@", so no request value is ever parsed by a shell.

Two practical consequences follow. First, the attacker-controlled input sits in ordinary request fields, so web server access logs and any proxy logs that record the Host header are your best evidence. Second, the vulnerable proxy.php in 26.4.302 includes no Nextcloud bootstrap at all, which fits Collabora’s warning that disabling the app does not help: if the web server serves the file, it runs.

Timeline

A month passed between a public fix and a CVE. Collabora, according to BleepingComputer, attributed much of the delay to GitHub’s CVE-processing backlog. Whatever the reason, anyone who waited for a CVE or a scanner signature before updating was exposed for the entire window, which is why the hunt below matters more than the patch date. Our explainer on CISA BOD 26-04 covers what KEV’s “forensic triage: yes” flag asks federal agencies to do. Private teams can borrow the same approach.

What to do now

1. Decide whether you need the built-in server. If you only installed it to try Nextcloud Office, remove it:

   sudo -u www-data php occ app:remove richdocumentscode
   ls -d apps/richdocumentscode 2>/dev/null && echo "directory still present"
   

   Confirm the directory is actually gone. A leftover proxy.php is the risk.

2. Otherwise update it. The latest release at the time of writing is 26.4.502 (October 23). Anything at or above 26.4.303 contains the fix.

   sudo -u www-data php occ app:update richdocumentscode
   sudo -u www-data php occ app:list | grep 'richdocumentscode:'
   

3. If you are on Nextcloud 29 or older, 26.4.303 will not install, because the app now requires Nextcloud 30. Remove the app or upgrade Nextcloud first. Those Nextcloud releases are end of life.

4. Block the file at the edge as a stopgap if neither is possible in the next few hours. Denying requests to /apps/richdocumentscode/proxy.php at the reverse proxy breaks the built-in server, but it removes the unauthenticated entry point. This is a stopgap of our own, not vendor guidance, and it does nothing about a shell that is already there.

How to hunt

Run these checks whether or not you have already patched. The indicators below come from administrators’ reports in the app’s GitHub issue #354, as summarized by eSecurityPlanet and WZ-IT; we could not read the issue directly, so treat them as a starting point, not a complete list.

Files

cd /var/www/nextcloud   # your Nextcloud root

# Reported web shell names, then any PHP file that is not part of the release
find apps/richdocumentscode -maxdepth 2 \( -name 'shx*.php' -o -name 'shrf4645.php' \)
sudo -u www-data php occ integrity:check-app richdocumentscode

integrity:check-app compares the app directory with the signed release and lists extra files as EXTRA_FILE. A clean result after an update is good news; a hit means you go to the response steps below. Also look for recently modified PHP files elsewhere under apps/ and in the data directory, since an attacker with a shell can write anywhere the web server account can.

Web server logs

# Requests to proxy.php that carry shell syntax, raw or URL-encoded
zgrep -hiE 'richdocumentscode/proxy\.php' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
  | grep -iE '\$\(|%24%28|\$\{IFS\}|%24%7BIFS|%2e%2e'

We ran the find and log-search commands above against sample files with GNU findutils and grep to confirm they match the reported patterns; adapt the paths to your install. The reported patterns are $( or %24%28 (command substitution), ${IFS} (used to avoid spaces) and %2e%2e (path traversal), along with bursts of proxy.php?status requests. Because the injected value can travel in the Host header, check whether your log format records it; the default combined format does not. If it does not, look at reverse proxy or load balancer logs that do. Go back to at least September 10, 2026.

Host signals

• Outbound connections from the web server to webhook.site or other request-capture services, which reported payloads used to send back system information.
• Failed sudo attempts by www-data or your equivalent web server user in the auth log.
• New cron entries, SSH keys or processes owned by the web server user.

Reported post-exploitation activity included searches for password manager files, cryptocurrency wallets and keystores. Published reporting we reviewed does not confirm data exfiltration or root access.

If you find a web shell

The web server account can read Nextcloud’s config/config.php, which holds the database password, the instance secret and any object storage, SMTP or other service credentials configured there. It can also read every file in the data directory.

1. Preserve the suspicious files and logs before you delete anything.
2. Isolate the host, then rebuild it or restore from a backup taken before the first suspicious request. Deleting the shell does not remove anything else the attacker set up.
3. Rotate every secret in config.php and any credential the web server account could reach.
4. Tell users whose files were on the server, and follow your own incident and notification obligations.

Prioritizing this against everything else

This one does not need a scoring debate. It has an active-exploitation SSVC value, it is in KEV, it needs no credentials, and the vulnerable component is reachable on the same host and port as Nextcloud. If you use the three signals together, as we argue in CVSS vs EPSS vs KEV, every one of them points the same way. CISA’s SSVC values are explained in our guide to reading Vulnrichment SSVC data.

Limits of this article

We could not read Collabora’s advisory (GHSA-g3vx-3m76-fghh), the Nextcloud forum warning or GitHub issue #354 directly. Statements attributed to them come from the CVE record, CISA’s KEV entry and press coverage, and are labelled as such. The root-cause description is our reading of the public source diff. We have not tested exploitation, and the indicator list comes from early victim reports, so absence of these indicators is not proof that a server is clean.

Sources and verification

CVE-2026-21589 lets an unauthenticated attacker read files from the web root of self-managed Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible and Fisheye. If you run any of them, upgrade to a fixed release now, check your access logs back to early October, and rotate credentials stored in configuration files if a read may have succeeded. CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 15, 2026.

Atlassian Cloud is not part of the job: Atlassian says it has already patched affected Cloud products.

The vulnerability

Atlassian’s CVE record describes an arbitrary file access flaw (CWE-552, files or directories accessible to external parties) that “allows an unauthenticated attacker to access specific files within the web application root directory.” Atlassian scores it CVSS 4.0 9.3, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H.

Read that vector carefully (our CVSS v4.0 walkthrough covers each metric). The vulnerable product loses confidentiality only (VC:H, VI:N, VA:N). The high scores for subsequent systems (SC:H/SI:H/SA:H) reflect what stolen files can unlock elsewhere: credentials in a configuration file are worth more than the file.

Two limits from the record matter for triage:

• The attacker needs the exact name and path of the file. The flaw “does not allow attackers to enumerate or list directory contents.”
• Atlassian says “in some configurations, there may be some sensitive files that make this highly severe.” Whether a given instance is a nuisance or a breach depends on what sits in its web root.

Root cause, per watchTowr

watchTowr Labs diffed vulnerable and patched Jira, Confluence and Bitbucket builds and, as summarized by Rapid7, found a path traversal in Atlassian’s web-resource handling where double-colon (::) sequences can act as path separators during request processing. In watchTowr’s testing the attacker could not leave the Tomcat context but could read files throughout the web root, including the protected WEB-INF/web.xml.

The most serious example in the research is Crowd. In a Crowd deployment connected to Jira, reading WEB-INF/classes/crowd.properties exposed application credentials. watchTowr used them to create a user and add it to jira-administrators. Rapid7 notes that Crowd’s IP allowlisting for applications can block that second step.

Timeline

Reports differ on what was published. Help Net Security says watchTowr built but did not publish an exploit and released a vulnerability checker. Rapid7 says file-read proof-of-concept scripts and a Nuclei template are publicly available. Either way, detailed root-cause analysis has been public since October 6, and you should assume working exploits exist.

CISA’s SSVC values in the CVE record are Exploitation active, Automatable no, Technical Impact total. “Automatable: no” fits the need to know file paths per target; it is not a reason to wait. Our Vulnrichment guide explains how to read these fields.

What to patch

Upgrade to one of these releases or later. Versions are from Atlassian’s CVE record; Atlassian’s Jira ticket says versions past end of life may also be affected, so an unsupported release needs a move to a fixed supported line, not a hunt for a patch.

Don’t forget the quiet ones. Crowd and Bamboo often run on separate hosts owned by a different team, and Crowd is where the published credential-theft path lives.

If you cannot patch today

Atlassian offers three interim mitigations, described in its per-product Jira tickets:

1. A WAF or reverse-proxy rule (all products) that blocks URLs where .. sits next to /, \ or ::, including URL-encoded forms. Atlassian asks you to test that encoded variants are blocked.
2. A Tomcat RewriteValve (Confluence, Jira Software, Jira Service Management, Bamboo, Crowd): add <Valve className="org.apache.catalina.valves.rewrite.RewriteValve" /> inside the application’s <Context> in conf/server.xml, install Atlassian’s rewrite.config under the application’s WEB-INF, and restart each node in turn.
3. A urlrewrite.xml rule for Bitbucket.

Take the rule content from Atlassian’s ticket for your product, not from a third-party blog. Atlassian is direct about the value: the mitigations are “limited and not a replacement for patching.” Where possible, remove unpatched instances from internet reach until they are upgraded.

How to hunt

Patching closes the hole; it does not tell you whether someone already read a file. Rapid7 recommends checking for compromise even after patching and describes a log search: decode each request line up to twice, then look for .. directly next to /, \ or ::.

Here is a small implementation of that approach. It is our script, not Atlassian’s published regex, and it will flag some benign requests. We ran it with Python 3 against a five-line synthetic log; the request paths in that test were made up to exercise the matcher and are not real exploit strings.

#!/usr/bin/env python3
"""Flag access-log lines with '..' next to '/', '\\' or '::' after up to two
rounds of URL decoding. Illustrates the approach Rapid7 describes for
CVE-2026-21589; it is not Atlassian's published regex.
Usage: python3 scan_access_log.py access_log.txt"""
import re
import sys
from urllib.parse import unquote

PATTERN = re.compile(r"(\.\.(/|\\|::))|((/|\\|::)\.\.)")

def suspicious(line):
    candidates = [line]
    decoded = line
    for _ in range(2):
        decoded = unquote(decoded)
        candidates.append(decoded)
    return any(PATTERN.search(c) for c in candidates)

with open(sys.argv[1], errors="replace") as f:
    for n, line in enumerate(f, 1):
        if suspicious(line):
            print(f"{n}: {line.rstrip()}")

On the synthetic log it flagged a raw ::..:: request, a double-encoded %252e%252e%252f request and an encoded backslash variant, and ignored a filename containing report..final.

When you triage hits:

• Start from October 5. Scan back at least to the advisory date; extend further if your logs allow, because the CVE record lists every release before the fixes as affected.
• Look at the status code and size. A 200 with a body on a traversal-shaped request deserves more attention than a 404.
• Check every node and the proxy. In a Data Center cluster each node has its own Tomcat access log; a WAF or load balancer in front may log what the nodes did not.
• Note what the path aimed at. Requests for WEB-INF paths, configuration files or .properties files tell you which secrets to rotate.

If a read may have succeeded

Treat any secret in a web-root file as exposed, then contain and rotate in this order:

1. Crowd application credentials from crowd.properties, and review Crowd’s application IP allowlists.
2. Recently created users and group changes, especially additions to jira-administrators or other admin groups since October 5.
3. Database credentials, API tokens and integration secrets held in configuration files the requests could have reached.
4. Downstream systems those credentials unlock: build agents behind Bamboo, repositories behind Bitbucket, SSO-linked applications behind Crowd.

Rapid7’s advice matches: contain first, then rotate exposed credentials and secrets. If you work to US federal timelines, this flaw also falls under BOD 26-04’s forensic triage requirements, which the required action of every KEV entry added in October cites.

Limits of this article

We have not tested the vulnerability or Atlassian’s mitigations. The root-cause details come from watchTowr’s research as reported by Rapid7 and Help Net Security; we did not reach watchTowr’s original post or Atlassian’s main advisory page during research, and rely on the CVE record and Atlassian’s public Jira tickets for versions and mitigations. No public source we found names the files requested in observed attacks.

Sources and verification

BeyondTrust Remote Support appliances running version 26.2.3 or earlier have an authentication bypass, CVE-2026-102764, that was exploited as a zero-day for about six weeks before it was disclosed. If you run a self-hosted appliance, apply the BT26-05-RS patch now. Then assume the appliance may have been compromised and check it, because the actor behind the attacks installed a web shell, a tunnel and a root backdoor that a patch does not remove.

Scope. On October 22, 2026 we read the CVE record, the KEV catalog (version 2026.10.21), BeyondTrust’s blog post on BT26-05 (last updated October 16), Google Threat Intelligence Group’s analysis, the Canadian Centre for Cyber Security’s alert AL26-025 and Rapid7’s analysis. BeyondTrust’s advisory page for BT26-05 did not load for us, so patch and version details below come from the CVE record, the Cyber Centre and Google, and we say so where it matters. We did not test the vulnerability.

The vulnerability

The CVE record, published by BeyondTrust on October 15, 2026, says internal components of Remote Support “did not adequately validate the origin of the messages it received”, which “could allow an attacker to perform file operations on the appliance”. It is classified as CWE-290, authentication bypass by spoofing, and affects Remote Support versions up to and including 26.2.3.

BeyondTrust scores it CVSS 4.0 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H): reachable over the network, no privileges, no user interaction. CISA’s enrichment in the record rates it exploitation active, automatable yes, technical impact total. The Cyber Centre describes the impact as unauthorized file operations “including arbitrary file uploads, potentially leading to full appliance compromise”.

That combination matters more than the score. Remote Support appliances sit at the edge, broker privileged sessions into internal systems and can store credentials. An unauthenticated file upload on such a device is a direct path to the systems it administers.

Timeline

As of its last update on October 16, BeyondTrust said it knew of only those two affected customers and had seen no adversary activity since August. That is a statement about what BeyondTrust has observed, not a guarantee about every appliance.

What to patch

The Cyber Centre also advises checking that automatic updates are enabled where appropriate. If you have more than one appliance, inventory them first; a forgotten secondary or lab instance is a common gap.

What the attackers did

Google Threat Intelligence Group attributes the exploitation to ARMORY CASTLE, “a suspected PRC-nexus espionage threat actor (formerly tracked as UNC5221)”. BeyondTrust attributes it, with moderate to high confidence, to the same group under its earlier name. Google’s analysis describes:

• SAWFLY, an obfuscated PHP web shell named mangoapi.php, placed under the appliance’s Laravel public directory, that returns HTTP 404 unless a specific POST parameter (_c94mfe) is present.
• BARECLAW, a tunneler at /tmp/ingredi_ws providing a SOCKS5 proxy over WebSocket, listening on local TCP port 19800 and exposed through an added HAProxy route, /uidchanarge, in /ns/config/haproxy.conf.
• A copy of /bin/sh at /usr/bin/dbus-authd, owned by root with the SUID bit set.
• Persistence through /home/bomgar/sbin/post_boot.d/zz-root-persist, which adds a passwordless sudo rule to /ns/config/sudoers.template and rebuilds /etc/sudoers.
• Deletion of logs on the appliance.

Google publishes these SHA-256 hashes:

Rapid7 notes that customers cannot audit the appliance’s host file system directly and should coordinate host-level inspection with BeyondTrust Support. BeyondTrust offers a threat-hunting package through its trust portal.

How to hunt without relying on hashes

BeyondTrust warns that indicators from one victim “rarely reappear at the next” and that evidence stored only on the appliance may be missing or manipulated. Its blog and Google’s analysis suggest hunting for behavior instead:

• Successful /login sessions from residential broadband or commercial VPN addresses, or outside business hours.
• user_changed events that raise Jump Item or team roles, and any unauthorized changes to accounts, permissions or session policies.
• Requests to unknown .php paths, and WebSocket upgrades from unexpected sources.
• Web service accounts spawning shells.
• Gaps in syslog forwarding, especially gaps that start and end within one session.

The last one depends on external logs. If the appliance does not already forward syslog and session events to a SIEM, BeyondTrust’s advice is to start now; as Rapid7 points out, logging enabled today cannot recover evidence that was already deleted.

If an appliance may be compromised

Google’s recommended order, condensed:

1. Preserve evidence first. Snapshot virtual appliances with memory, and collect syslog, reverse-proxy or WAF and firewall logs before reboots or changes.
2. Contain. Block inbound traffic at the perimeter, restrict egress, end sessions, and disable, rather than delete, Jump Clients, Jumpoints and API accounts.
3. Rebuild rather than clean. Redeploy from a clean, patched image, and restore only configuration backups from before the exposure window.
4. Rotate credentials after patching or rebuilding, in dependency order: credentials in the vault and Password Safe, and any credential typed into a support session during the window. BeyondTrust adds: watch for unmanaged logins and review new MFA registrations on privileged accounts.
5. Restrict the admin interfaces. Limit /login and /appliance by IP and require single sign-on with phishing-resistant MFA.

If you find evidence of exploitation, BeyondTrust asks customers to open a severity 1 support case citing BT26-05.

For federal agencies, the KEV due date was October 19 and forensic triage is required; our BOD 26-04 explainer covers what that triage involves and what private teams can borrow from it. For how a KEV listing should outrank a score when you prioritize, see CVSS vs EPSS vs KEV.

Limits of this article

BeyondTrust’s BT26-05 advisory page did not load for us; we relied on its blog post, the CVE record, Google and the Canadian Cyber Centre for versions and patch names. Rapid7’s article is a secondary source and is used only for statements it attributes to BeyondTrust or Mandiant and for its own clearly labelled advice. Attribution and indicators are Google’s and BeyondTrust’s; we have not verified them. Details may change as the vendors update their guidance.

Sources and verification

Checked on October 22, 2026.

Plex Media Server builds older than 1.43.3.10861 contain four vulnerabilities that the US Cybersecurity and Infrastructure Security Agency (CISA) added to its Known Exploited Vulnerabilities (KEV) catalog on October 20, 2026. Plex says that, chained together, they let an unauthenticated remote attacker run code on the server, and that exploitation is now wide. The fix has been available since September. If you run Plex anywhere, at home, in a lab or on a company network, update it, then check whether it was compromised before you updated.

Scope. We read the four CVE records in the CVE List, CISA’s machine-readable advisory VA-26-266-01, the KEV catalog (version 2026.10.21) and Plex’s security thread on its forums, including the October 19, 2026 update, on October 22, 2026. We did not test the vulnerabilities or the proof of concept. For how KEV deadlines work, see our explainer on BOD 26-04.

What is affected and what fixes it

Every one of the four CVE records lists Plex Media Server before 1.43.3.10861 as affected and 1.43.3.10861 as unaffected. CISA, acting as the CVE Numbering Authority, published the records and the advisory on September 23, 2026.

The individual scores look moderate. That is the trap: each score rates one flaw on its own, while the risk comes from the chain. Plex’s update says that chained, the four “allow an unauthenticated remote attacker” to execute code as the server process. Plex has not published the chain step by step, and we have not reproduced it. Our reading of the CVE descriptions is that the request-forgery and injection flaws provide the access that the file-write flaw, which on its own needs admin rights, requires. Treat that as interpretation, not a confirmed sequence.

The same advisory lists a fifth flaw, CVE-2026-96651, a path traversal in /system/agents/media/get that can read files including the PlexOnlineToken, which the advisory says “grants control of the Plex account and server”. It is not in KEV, and CISA’s enrichment dated September 23 records no exploitation. The same build fixes it.

What changed: from routine update to active exploitation

KEV details

Each KEV entry says the flaw can be chained with the other three. The deadlines bind US federal civilian agencies under BOD 26-04; for everyone else they are a signal of urgency. CISA’s catalog does not explain why two flaws got three days and two got fourteen.

What to do now

1. Update and confirm the build number

Update Plex Media Server to 1.43.3.10861 or later, then confirm the version under Settings → General in Plex Web, as Plex’s notice describes. “1.43.3” alone is not enough to be sure: Plex’s later update gives the full build number as the threshold. Plex also tells desktop users to update Plex Desktop.

2. Decide whether the server was exposed

Plex’s guidance is that a server running an older build that was reachable from the internet “may be compromised”. Exposure usually came from Plex’s Remote Access feature or a port forward. Plex specifically advises against forwarding port 32400 directly and suggests turning remote access off if you don’t need it.

3. Look for the signs Plex lists

Plex’s October 19 update names these indicators:

• Processes you don’t recognize running as the Plex user.
• Unfamiliar .so (Linux) or .dll (Windows) files in the Plex Codecs folder.
• Outbound connections to proxystream.st.
• High CPU use while nothing is playing.
• Transcoder options you did not set in Preferences.xml, which ties directly to CVE-2026-96656’s TranscoderH264Options behavior.

The location of the Codecs folder and Preferences.xml depends on your operating system and install method; Plex’s support documentation lists them. A clean result is not proof of a clean server: these are the indicators Plex has published so far, and an attacker can remove files.

4. If you find something, or can’t rule it out

Plex’s update recommends rebuilding from a clean installation, clearing the Codecs folder and reviewing Preferences.xml. It also says to sign out of all devices and change the Plex account password, and to treat any network shares or credentials the Plex service account could reach as potentially exposed. Because CVE-2026-96651 can expose the server token, signing out all devices after updating is sensible even without other signs; Plex’s notice does not explicitly address token rotation.

For companies

If Plex appears in an asset inventory or scanner export, check for it on employee-run lab machines and NAS devices too. Media servers often run under accounts with broad read access to shared storage, which is what turns a hobby service into a foothold. Our guide to matching the KEV feed against a scanner export shows how to flag entries like these automatically. If you are new to SSRF, our SSRF explainer covers why “make the server send a request” is so often the first link in a chain.

Limits of this article

We did not run the proof of concept or confirm the chain’s steps. Plex’s statements about exploitation, the proof-of-concept date and the indicators come from its forum post and are not independently verified. We did not read the researcher’s write-up referenced in the CVE records. KEV entries and Plex’s guidance may change; check the sources below for updates.

Sources and verification

Checked on October 22, 2026.

Multi-factor authentication verifies identity at the moment of login. It says nothing about what happens to the session afterward — and that gap is exactly what token theft attacks exploit. A user can enter their password, complete their MFA prompt correctly, and still hand an attacker full account access, because the thing worth stealing isn’t the password or the MFA code anymore. It’s the session token issued after both succeed.

How token theft actually works

The dominant technique is adversary-in-the-middle (AiTM) phishing, using open-source tooling such as Evilginx2, which Microsoft Threat Intelligence documented in a July 12, 2022 report on a campaign it said targeted more than 10,000 organizations from September 2021 and was followed by business email compromise fraud. The attacker doesn’t build a fake login page — they proxy the real one. The victim lands on a domain that looks wrong on close inspection, but the page itself is the actual login flow, relayed through the attacker’s server in real time.

The victim enters their real username and password, and completes MFA exactly as they normally would — push approval, OTP, whatever the org uses. The legitimate service verifies everything correctly and issues a session cookie or token, because as far as the identity provider is concerned, a real authentication just happened. The attacker’s proxy captures that session token in transit before relaying the successful login back to the victim, who notices nothing wrong.

From that point, the attacker doesn’t need the password or MFA again. They load the stolen session token directly into their own browser and are treated as an already-authenticated user — because they are one, technically, just not the one the identity provider thinks.

Why traditional MFA doesn’t stop this

MFA that relies on a human relaying a value — typing an OTP, tapping “approve” on a push notification — is phishable by design, because nothing prevents that value from being captured and relayed through a proxy. The code or approval doesn’t know which site it’s being used on. Microsoft’s report describes this as not being a flaw in MFA itself: the attacker obtains an authenticated session cookie, so access follows regardless of the sign-in method used. We have not verified how the technique behaves on specific platforms other than those in that report.

Phishing-resistant authentication (FIDO2/WebAuthn passkeys and security keys) closes this specific gap because the cryptographic challenge is bound to the actual domain — an AiTM proxy sitting on a different origin can’t get a valid signed response out of it, even with a perfect visual clone of the login page. But phishing-resistant login doesn’t retroactively protect a session token that’s already been issued under older MFA methods, which is why detection matters as much as prevention. Microsoft’s report recommends phish-resistant MFA (FIDO v2.0 and certificate-based) plus conditional access that evaluates signals such as device compliance and trusted IPs.

What detection actually needs to catch

Standard login monitoring looks for failed authentication attempts and unusual login locations. Token theft typically produces neither — the original login succeeded legitimately, and the attacker’s subsequent access uses a valid token, not a new login attempt. What it does produce, if you’re watching for it:

• The same session token used from two meaningfully different locations or devices close together in time — not a new login, but continued use of an existing session from an inconsistent source
• Impossible travel on session activity, not just login events — a session that was active in one region and is suddenly active somewhere geographically implausible minutes later
• Anomalous behavior after a legitimate-looking login — mailbox rule changes, unusual OAuth app consent grants, or access patterns inconsistent with the user’s normal activity, occurring shortly after a routine sign-in

What actually reduces the risk

• Shorten session and token lifetimes so a stolen token has a narrower window of usefulness before it expires and forces re-authentication
• Bind sessions to device and network signals where your identity provider supports it, so a token replayed from a different device or context gets challenged again rather than accepted silently
• Move toward phishing-resistant authentication for the accounts where a compromised session would matter most, since it removes the initial credential-and-code capture step the whole attack depends on
• Monitor session and token reuse patterns specifically, not just login failures — this is the signal that actually exists in this attack, and most detection stacks aren’t tuned to look for it

Token theft is a reminder that “did MFA succeed” and “is this session legitimate right now” are different questions. Most security programs have built strong controls around the first and comparatively little around the second, which is exactly the gap this attack class is built to walk through.

If you run Citrix NetScaler ADC or NetScaler Gateway with SAML authentication, check your build number today. CVE-2026-88779, a memory overflow that can take a SAML-configured appliance offline, is being exploited, and the fix is in builds newer than the ones Citrix shipped for last week’s two zero-days. An appliance upgraded to 14.1-73.37 or 13.1-64.23 on or after September 27 is still inside the affected range.

This article separates what Citrix, CISA and the security researchers have each confirmed, because early reporting mixed denial of service with remote code execution. For the two earlier flaws, see our patch-and-hunt guide for CVE-2026-88771 and CVE-2026-88772.

What is confirmed

NetScaler, acting as its own CVE Numbering Authority (the organization authorized to assign and describe CVE IDs for its products), published the record for CVE-2026-88779 on October 4, 2026 at 02:35 UTC. The record’s public date is 02:19 UTC on October 4, which is the evening of October 3 in US time zones. Sources that say Citrix published its bulletin, CTX697174, on “October 3” and the CVE record’s “October 4” describe the same event in different time zones.

CVSS (Common Vulnerability Scoring System) is the standard 0 to 10 severity scale; this score uses version 4.0. KEV is CISA’s Known Exploited Vulnerabilities catalog.

Why last week’s patch level is not enough

The earlier bulletin, CTX697096 of September 27, 2026, fixed CVE-2026-88771 through CVE-2026-88778 in builds 14.1-73.37 and 13.1-64.23 (and 14.1-73.37 FIPS and 13.1-37.279 for FIPS and NDcPP ADC). The new record uses “before” ranges that start higher:

An appliance on 14.1-73.37, for example, is earlier than 14.1-73.41, so the record lists it as affected. SecurityWeek reported that appliances already patched for the earlier flaws were hit; that matches the version arithmetic. The practical consequence is that “we patched the NetScaler last week” is no longer a complete answer, and the target build is the newer one.

Two limits apply. The Gateway records list only the 14.1 and 13.1 non-FIPS builds, which is why the FIPS builds are shown for ADC only. And we did not test any build; this is the reading of the published ranges.

What attackers can do with it, and what is unconfirmed

The evidence supports one consequence: denial of service. CISA’s catalog entry says the flaw “could allow for a denial of service”. Citrix said, as quoted by The Hacker News, that it observed targeted attacks on unmitigated deployments that can lead to denial of service, and that it had not identified an impact on the integrity of customer data. Help Net Security also quotes Citrix as saying that if the condition is triggered repeatedly, the service may remain unavailable.

Several details in early coverage deserve caution:

• Remote code execution. Help Net Security says attackers reportedly attempt to download and install web shells. SOC Prime, citing SecurityWeek, describes authentication requests containing shell commands in username fields and a researcher’s report of a malware binary downloaded on one honeypot. These are described as attempts. None of the sources we read shows code execution through CVE-2026-88779 itself. SecurityWeek reported that watchTowr concluded the flaw is a denial-of-service issue that can only crash systems. The earlier flaws, CVE-2026-88771 and CVE-2026-88772, are the ones for which web shell deployment has been documented, and some of that traffic may be aimed at them.
• Why attackers would crash appliances. watchTowr suspects, according to SecurityWeek, that crashing appliances may be intended to speed up exploitation of CVE-2026-88771. That is a researcher’s hypothesis, not a confirmed attacker goal.
• A reboot after a set number of crashes. One summary we read claims the appliance reboots after a particular number of crashes. We could not confirm that in Citrix’s or watchTowr’s own text, so we are not repeating the number.
• Which flaw caused a given crash. Administrators told reporters that patched appliances were rebooting and that interim workarounds sometimes failed to stop the crashes, per SecurityWeek. Those are reports from the field, not measurements of a specific flaw.

What CISA’s data says

CISA added the flaw to KEV on October 4, 2026 with a due date of October 7, marked forensic triage as required, and listed ransomware campaign use as “Unknown”. The due date comes from Binding Operational Directive 26-04 and applies to US Federal Civilian Executive Branch agencies, not to private organizations; CISA encourages everyone to adopt the same risk-based approach.

CISA’s own enrichment of the CVE record rates exploitation as “active”, the flaw as automatable by an attacker (“yes”), and technical impact as “partial”. The Exploit Prediction Scoring System (EPSS), a model that estimates the chance of exploitation in the next 30 days, gave the flaw 0.00534 (about 0.5%, 43rd percentile) on October 5, 2026. That number is low despite confirmed exploitation. Use it as a reminder that EPSS lags new disclosures, not as a reason to wait.

What to do, in order

This sequence is our recommendation, built on the vendor and researcher guidance cited above.

1. Establish whether SAML is configured

watchTowr says the condition is a SAML service provider or identity provider setup. WorkOS suggests searching the configuration file for the two relevant commands; the search itself changes nothing:

grep -E "add authentication saml(Action|IdPProfile)" /nsconfig/ns.conf

Run it from the appliance shell and read the result against the Citrix bulletin. A match means the appliance meets the described condition. No match is encouraging but the safe default is still to move to the fixed build, since every build you would choose in the next maintenance window should be at or above the newer ones.

2. Upgrade to the new fixed build

Target 14.1-73.41 or later, or 13.1-64.28 or later (or the FIPS and NDcPP builds in the table above). Confirm exact build strings on Citrix’s download page before upgrading FIPS or NDcPP appliances, because our earlier article noted inconsistent formatting of the 13.1 FIPS string in CVE records. Versions 12.1 and 13.0 are end-of-life, and we found no statement on whether they are affected; plan the migration rather than assuming they are not.

3. Apply interim mitigation if you cannot upgrade today

watchTowr and Help Net Security both point to Citrix’s Global Deny List signatures, delivered through NetScaler Console, as the interim step; WorkOS also mentions responder policies available from Citrix Support. SecurityWeek’s reporting that workarounds sometimes failed to stop the crashes means mitigation buys time and is not a substitute for the fixed build.

4. Look for crashes, then for what came with them

WorkOS lists crashes in /var/log/ns.log or /var/log/messages, repeated daemon restarts, “Pitboss declaring system failure” messages and unexplained reboots since late September as signs to look for. Help Net Security reports that Citrix offers an indicator-of-compromise script run through NetScaler Console. We did not run either.

A denial-of-service flaw should not close the investigation. If an appliance rebooted unexpectedly in the past two weeks, check it for the configuration theft and web shell activity described in our CVE-2026-88771 and CVE-2026-88772 article. Preserve logs first; our piece on logging for incidents explains why off-box copies matter.

5. Decide what an outage costs you

Many organizations authenticate staff to everything through the same NetScaler SAML configuration. A flaw that can crash it is an availability risk to every application behind it. Whether you can reach critical systems when the gateway is down is worth testing, and our vulnerability backlog piece covers how to rank exposed and exploited items ahead of the rest. The general sequence for flaws attacked before a patch plan existed is in our zero-day response guide.

What to take from this

Two security bulletins in under a week for one product means the version you recorded last week is stale. Track the fixed build per advisory, not “patched” as a status, and recheck the product’s bulletin page after any exploited-flaw announcement before closing the ticket.

Sources and verification

Checked on October 6, 2026. We did not test the vulnerability, run any script or access a NetScaler appliance. Citrix’s own bulletin pages (CTX697174 and the Citrix community post) returned an access error from our environment, so Citrix’s statements are quoted through the CVE record, CISA data and the secondary reports named in the table.

If you run Cisco Catalyst SD-WAN Manager (formerly vManage) on your own infrastructure, you need to do two things today: confirm whether it is reachable from the internet, and look at two log files for requests that mention j_security_check. Cisco says the flaw, CVE-2026-76504, lets an unauthenticated attacker act as the admin user through the manager’s API, and that its security team became aware of active exploitation in September 2026. The only remediation is a software upgrade.

What Cisco has published

Cisco published advisory cisco-sa-sdwan-webauth-xr8beuuU on September 30, 2026. Version 1.1, dated October 2, 2026, added information about a temporary protection called Live Protect. Cisco rates it Critical.

CVSS (Common Vulnerability Scoring System) is the standard 0 to 10 severity scale; this score uses version 3.1.

Cisco describes the mechanism this way: improper handling of URI encoding in an HTTP request lets a request bypass an authentication rule meant to restrict access to a specific API endpoint. URI encoding replaces a character with a percent sign and two hexadecimal digits, so j can be written %6a. Cisco’s description implies the check looks at the encoded form while the application later treats it as the plain character. That last step is our reading of the mechanism, not a statement in the advisory.

Which releases are fixed

Cisco’s advisory gives these first fixed releases:

Two points on reading this table. First, the table lists only these trains. If you run a train that is not in it, the advisory neither marks that train fixed nor says it is unaffected, and we could not find a Cisco statement on it. Treat it as unresolved and ask Cisco TAC rather than assume it is covered. Second, Cisco says it validates only the affected and fixed release information in the advisory, so use the advisory, not a scanner’s interpretation of the CVE record, to decide.

For Cisco-hosted deployments, Cisco says the flaw is addressed in SD-WAN Cloud (Cisco Managed) release 20.15.605 with no customer action needed.

The Live Protect shield: what it is and is not

Cisco’s October 2 update says it released a Live Protect shield for this CVE “to provide temporary security coverage to allow time for software upgrade planning”. Cisco is explicit about the limits: it “offers only temporary partial protection” and “the only way to remediate this vulnerability is to upgrade to the first fixed software release”. It also warns of a side effect: a legitimate user who uses URI encoding might not be able to log in to SD-WAN Manager once the shield is applied.

Our reading: use the shield, if you use it at all, to buy days while you schedule the upgrade, not as the end state. “Partial” means Cisco is not claiming it blocks every variant. Cisco’s documentation for the feature is Live Protect for Cisco Catalyst SD-WAN. We did not test the shield.

Reduce exposure first

Cisco’s mitigation for on-premises deployments is to restrict access from unsecured networks, including the internet. If you need internet access to the manager, Cisco says to restrict it to known, trusted hosts on the ports and protocols in its user guides, and to place the control components behind a filtering device such as a firewall. Cisco’s advisory says managers “exposed to the internet” with ports exposed are at risk.

Practical steps that follow from that:

• Find out whether the manager’s web and API ports are reachable from the internet. Check from outside your network, not from the configuration alone.
• If they are, restrict them to a management network or a named allowlist before you do anything else. This does not fix the flaw, but it removes the unauthenticated attacker’s path while you plan the upgrade.
• Remember what the manager controls. SD-WAN Manager is the administrative plane for the WAN, so admin API access is access to the network’s configuration. That is our assessment of impact, not a Cisco statement of what an attacker did.

Check for exploitation

Cisco says its indicators may also occur during normal operations, so assess them against your usual traffic. It names two files:

1. /var/log/nms/containers/service-proxy/serviceproxy-access.log. Look for entries related to j_security_check from unknown or unauthorized IP addresses. Cisco’s example is a POST /%6a_security_check request.
2. /var/log/nms/vmanage-server.log. Look for entries related to j_security_check from unknown or unauthorized IP addresses, specifically for users whose names start with viptela-reserved-. Cisco’s example reads Request Stored in Map is (/%6a_security_check) for user (viptela-reserved-..).

viptela-reserved- accounts are system service accounts that Cisco documents in the authentication section of its SD-WAN configuration guide. A request that authenticates as one of them from an outside address is the pattern Cisco is pointing to.

Cisco states the %6a form is only an example: “the vulnerability will allow any one character that is encoded in the request to be used to exploit this.” So searching for %6a alone will miss other variants. As an untested starting point (ours, not Cisco’s), also list every request to the endpoint whose path contains a percent-encoded character:

grep -E 'POST /[^ ]*%[0-9A-Fa-f]{2}[^ ]*' serviceproxy-access.log

Review the results against your normal logins. Expect some noise, because other legitimate requests can contain encoded characters.

Cisco’s other guidance:

• To determine whether a system has been compromised, open a Cisco TAC case as Severity 3 with CVE-2026-76504 in the title. Before opening it, run request admin-tech on the manager so the diagnostic file can go to TAC.
• Cisco publishes Snort rule 67179 for this advisory, for teams that run Snort-based inspection in front of the manager.
• Send manager logs to an external server and retain them long enough for investigations, which is also general hardening advice in the advisory. Our piece on logging for incidents rather than dashboards covers why.

Upgrade, then decide what else to rotate

Cisco’s advice is to upgrade to a fixed release as soon as possible. The advisory does not describe what an attacker with admin API access did in the observed attacks, and we found no public report that does. So the following is general incident response practice, not vendor guidance, and applies if your logs show a suspicious request:

• Treat the manager’s configuration as readable and changeable by an outsider for the period of exposure. Review recent user, template and policy changes.
• Rotate the administrator credentials and any API keys or integration credentials the manager holds.
• Cisco’s hardening list also says to change the default administrator password and to restrict the administrator account by creating named user accounts based on access needs. Do both if you have not.

What the CISA entry means

CISA added CVE-2026-76504 to its Known Exploited Vulnerabilities (KEV) catalog on September 30, 2026, the day Cisco published. The entry sets a due date of October 3, 2026, requires forensic triage, and lists ransomware campaign use as “Unknown”. CISA’s enrichment data on the CVE record rates exploitation “active”, automatable “yes” and technical impact “total”. The due date comes from Binding Operational Directive 26-04 and applies to US Federal Civilian Executive Branch agencies; it does not bind private companies.

What this adds up to

This section is editorial analysis.

CISA’s catalog added Citrix NetScaler (September 27), this Cisco flaw (September 30), Fortinet FortiMail (October 1) and Zammad (October 2) within six days. They are different products and different bugs, but each is software reachable over the network that was already being exploited when the advisory appeared. We covered the FortiMail file-write zero-day, the Citrix NetScaler zero-days and the Zammad zero-days separately. Three habits shorten the next response:

• Keep management planes off the public internet. Cisco’s own mitigation is this. If the only thing standing between the internet and admin access is a login check, one encoding bug removes it.
• Know your release train before the advisory arrives. The table above only helps if you can say in a minute which train you run.
• Ship manager logs off the box. Cisco’s indicators are log lines. They are only useful if the logs exist and an intruder could not have edited them. For triage order, see what a zero-day is and how to respond to one and the vulnerability backlog that never shrinks.

Sources and verification

Checked on October 5, 2026. We did not test the vulnerability, the Live Protect shield or the grep pattern on a Cisco SD-WAN Manager. We could not open CISA’s website from our environment, so CISA data was read from CISA’s published KEV data file and from CISA’s entry embedded in the CVE record.

If you run Zammad, the helpdesk and ticketing system, check your version today. Anything on 6.5 or older is on a branch Zammad no longer patches and is the version range where the remote code execution flaw, CVE-2026-102489, can be used. Moving to Zammad 7.2.0, the version Zammad currently recommends, closes that path. It does not, on the evidence available as of October 5, 2026, settle the second flaw, CVE-2026-102490, which lets someone who already runs code as the zammad user become root.

This article separates what the CVE records, the discoverer, the vendor and CISA each say, because on this incident they do not fully agree.

What happened

The Dutch Institute for Vulnerability Disclosure (DIVD) is a non-profit made up largely of volunteer security researchers. It was breached. In its public timeline for the incident (case DIVD-2026-00014), DIVD dates the first malicious access to September 21, 2026 and says it became aware of the activity on September 22. On September 30 it said the attackers got in through two previously unknown flaws in Zammad, an open-source helpdesk it ran, which it then tracked as CVE-2026-102489 and CVE-2026-102490. On October 1 it said volunteer data had been taken, including email addresses and possibly contact details.

DIVD also says the intrusion was run by an automated AI agent that chose each next step itself, and that the agent moved from the Zammad user to root “in seconds”. That is DIVD’s own assessment from its forensic work with Merlon Security. We have not seen independent forensic evidence, and the trade press (Help Net Security) notes it is unknown whether this was part of a larger attack or a capability test. Treat the AI-agent description as DIVD’s account.

DIVD’s response gives a useful second detail. It says network segmentation and its incident team’s actions stopped the attackers from going deeper into its systems.

The two flaws

CVSS (Common Vulnerability Scoring System) is the standard 0 to 10 severity scale. These scores use version 4.0 and were assigned by DIVD, which also acted as the CVE Numbering Authority, the body that issued these CVE IDs.

Two details in secondary coverage are easy to get wrong. Some reports say both flaws score 9.4. In DIVD’s records, 9.4 is the score for the chain; each flaw alone scores lower. And one report describes an attack going “from unauthenticated access to root”. That is the chain, not a single flaw: the first needs no account, the second needs the foothold the first provides.

Where the sources disagree

Is there a fix? Help Net Security reported on October 1 that both flaws were “currently without a fix”. DIVD’s case file lists patch status as “Available” with the recommendation “Upgrade to Zammad version 7”. Zammad’s statement says CVE-2026-102489 does not affect current versions and that it hardened the code anyway in 7.2.0. These are not the same claim. The consistent reading is that 7.x removes the remote path for the first flaw, and no fix has been announced for the second.

Affected versions. The CVE record’s structured data lists CVE-2026-102489 as affected from 6.3.0 up to, but not including, 6.5.4. DIVD’s case file and the record’s own description say 6.3.0 to 6.5.4. A scanner that reads only the structured field could skip 6.5.4. Zammad’s wording is broader still: “6.5 and older”. Use Zammad’s range if you are deciding whether to act.

How the flaw was disclosed. DIVD’s case file says it reported the vulnerabilities to Zammad on September 24, 2026 and scanned for exposed instances and created a limited disclosure on September 26. Zammad says it first received a report about the session issue in August 2026, and that DIVD had not given it technical details of the second flaw until October 1. Zammad also wrote that it does “not consider this a responsible way to handle vulnerabilities”. We cannot reconcile the August report with DIVD’s September 24 date from the public record, so we state both. For readers the practical point is the same: the CVE IDs were public before the vendor had published fixes or an advisory for the second flaw.

How exploitable is the second flaw? DIVD’s case file says it affects “all versions”. Zammad said on October 1 that it “cannot be exploited remotely on its own. An attacker would already need access to your server.” Both can be true: it matters most as the second step of a chain, which is exactly how it was used.

What CISA says

CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog on October 2, 2026. The entries set a due date of October 5, 2026, mark forensic triage as required, and list ransomware campaign use as “Unknown”. CISA’s required action is to apply mitigations per vendor instructions or stop using the product if mitigations are unavailable. The due date comes from Binding Operational Directive 26-04 and applies to US Federal Civilian Executive Branch agencies, not to private organizations.

CISA’s own enrichment data on the CVE records rates exploitation as “active” and technical impact as “total” for both. It rates the first flaw “automatable: yes” and the second “automatable: no”, which fits the difference above: one can be launched against many servers over the network, the other needs a foothold.

One data point worth knowing, with its limits. The Exploit Prediction Scoring System (EPSS), a model that estimates the probability a CVE will be exploited in the next 30 days, gave CVE-2026-102489 a score of 0.0140 (about 1.4%, 71st percentile) and CVE-2026-102490 0.0063 (about 0.6%, 48th percentile) on October 4, 2026. Exploitation has already been confirmed for both. A low EPSS number soon after disclosure reflects how little public data the model had, not safety. Do not use it to lower priority for a flaw on CISA’s exploited list.

What to do, in order

This sequence is our recommendation, built on DIVD’s, Zammad’s and the Dutch NCSC’s published advice as cited. Vendor advice is marked as such.

1. Find every Zammad instance and its version

Include test, staging and forgotten copies. DIVD’s recommendation covers any version, and its affected range for the root escalation begins at 1.5.0. Record whether each one is reachable from the internet.

2. Preserve logs before you upgrade

The Dutch National Cyber Security Centre (NCSC-NL) advised copying application and network logs before updating, because they may help you check later for abuse of the second flaw, as reported by Help Net Security. Do this first. Our piece on logging for incidents rather than dashboards covers why off-server copies matter.

3. Remove the remote entry point

Zammad recommends moving to 7.2.0, released September 23, 2026 according to its release page. If you cannot upgrade today, DIVD’s alternative is to take the instance offline. Our addition: if the helpdesk must stay up for staff, restrict it to a VPN or an allowlist of source addresses until you have upgraded. If you are on 6.5 or older, treat the upgrade as overdue regardless of this incident, since Zammad says those versions get no security fixes.

4. Check for compromise, even after upgrading

DIVD published a log-check script for indicators of compromise, linked from its case file. We did not run it. Read any script before running it against production logs, and run it on a copy. A clean result lowers the likelihood of this specific activity. It does not prove a server was never accessed, and DIVD itself says it assumes breach until it can prove otherwise.

Upgrading after an intrusion does not remove an attacker who already has root. If the logs show suspicious sessions or code execution, plan a rebuild rather than a patch.

5. Assume the ticket system holds more than tickets

This part is analysis, not vendor guidance. A helpdesk typically stores customer emails and attachments, internal notes, and credentials for connected channels such as mailboxes and chat. If a server may have been reached, rotate those integration credentials and API tokens, and revoke active sessions. Our zero-day response guide covers the general order of work.

6. Watch for the second fix

Follow Zammad’s GitHub security advisories for CVE-2026-102490. When a fixed version is named, that becomes the target, not “version 7” in general.

The lesson that does not depend on Zammad

Two points from DIVD’s account apply to any internal tool, offered here as our reading of it.

• Low-severity entry points still matter when a second step exists. The first flaw lands on a service account with limited rights. The second turns that into root. Defenders who triage each CVE alone can underrate a chain. When two advisories name the same product on the same day, read them together.
• Segmentation is what limited the damage. DIVD credits it for stopping lateral movement. A ticketing server that can reach everything is a larger risk than the ticketing software itself.

The same pattern of an edge or internal service exploited before a full patch plan existed appeared in the FortiMail zero-day and the Citrix NetScaler zero-days in recent days, and the vulnerability backlog is where “exposed and exploited” should jump the queue.

Sources and verification

Checked on October 5, 2026. We did not test either vulnerability, run DIVD’s script or install Zammad. We could not open Zammad’s GitHub security advisories page or CISA’s website from our environment, so CISA data was read from CISA’s published KEV data file and from CISA’s entries embedded in the CVE records.

If you run Fortinet FortiMail and the IBE service is switched on, switch it off today or take the webmail interface off the internet. Fortinet says the flaw tracked as CVE-2026-104286 is being exploited, and as of October 4, 2026 its advisory still describes the fixed builds as “upcoming”. Then check whether someone has already used it, because the attacks Fortinet describes change the appliance’s mail archiving settings.

This article covers what Fortinet has confirmed, where the public records disagree with each other, and the order to work in.

What Fortinet disclosed

On October 1, 2026, Fortinet published advisory FG-IR-26-175. It describes the flaw as a path traversal weakness (CWE-22) combined with improper neutralization of a NULL byte (CWE-158) that “may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests.”

The advisory adds: “This has been reported to be exploited in the wild, customers are urged to apply the workaround below.”

CVSS (Common Vulnerability Scoring System) is the industry-standard 0 to 10 severity scale; this score uses version 3.1.

The workaround and the indicators both point at one feature: IBE, or identity-based encryption. Fortinet’s administration guide describes it as a scheme that “uses identities (such as email addresses) to calculate encryption keys.” In practice it is the feature that lets FortiMail send an encrypted message to an outside recipient, who then opens it through a web link. That web-facing piece is what the workaround turns off.

Fortinet’s advisory does not say whether IBE is enabled by default, and we could not confirm it from the documentation we read. Check your own configuration rather than assuming either way.

Affected and fixed builds, according to Fortinet’s advisory

We read the advisory on October 4, 2026. Its timeline showed a single entry, “2026-10-01: Initial publication”, and the solution column still used the word “upcoming”. We found no Fortinet statement giving a release date. That status can change at any time, so read the advisory itself before you plan around it.

Note what this means for the 7.2 branch: Fortinet lists no fixed 7.2 build. The stated path is a migration to 7.4 or later, which is a larger change than a patch release.

The CVE record does not match the advisory

This is the part most likely to cause a wrong decision this week.

The CVE record is published by Fortinet as the CVE Numbering Authority (the organization authorized to describe CVE IDs for its own products). We retrieved it on October 4, 2026; it was last updated on October 2, 2026. It disagrees with the advisory, and with itself:

The CVE record’s solutions field also mentions FortiRecorder, a different product that the advisory does not mention at all.

Why this matters: vulnerability scanners and asset inventories usually match on the structured version data, not on the advisory text. A tool reading that data could report FortiMail 8.0.1, 7.6.6, 7.4.7 or 7.4.8 as not affected, while Fortinet’s advisory lists all four as affected. The record’s solutions field would also lead you to treat 7.6.6 as the fix when the advisory says 7.6.7.

We do not know which source Fortinet will correct. Until it does, the cautious reading is the advisory’s wider range, plus the 7.0 branch that only the CVE record lists. If your scanner says a FortiMail build on these branches is clean, verify the build number by hand.

What attackers have been doing

Fortinet’s advisory lists indicators of compromise rather than a narrative, but the indicators tell a story. Three kinds of entry appear in the system event log examples it publishes:

• A scheduled job running as root: a log line beginning msg="(root) CMD (/bin/sh -c 'O=/migadmin ..., with ui=cron.
• An administrator logout with no interface recorded: msg="User admin logged out from (null)."
• A new mail archive account pointing off the appliance: msg="Added 'archive234' to 'archive account'" with destination[remote], remote-ip[79.141.169.187] and remote-directory[/uploads].

The third one is the consequence to worry about. An archive account with a remote destination sends copies of mail to another server. Beazley Security, summarizing the same indicators, describes “attackers creating a remote mail archive account” that “sends archived mail” to that address. For a mail gateway that sees an organization’s inbound and outbound email, that is a continuing leak of message content, not a one-time break-in.

The advisory also lists two entries from the encryption logs: an IBE decryption error ending 'Invalid Base64 Encoding at pos 0. Character=0x2a', and a failed login for an internal user written as *@domain.tld.

Fortinet names two IP addresses: 79.141.169.187 and 45.129.0.192. Attacker addresses change, so treat a match as strong evidence and a non-match as weak evidence.

Two security firms, Truesec and Beazley Security, additionally list files they say were added or modified on compromised appliances. Their lists overlap but are not identical. Beazley Security presents the files as Fortinet’s indicators and publishes hashes for each; we did not see a file list in the advisory text we were able to read, so we attribute them to those firms:

No source we read attributes the activity to a named group, gives a count of affected organizations, or says when exploitation began. CISA’s catalog entry lists ransomware use as “Unknown”.

What to do, in order

1. Find out whether you are exposed

Treat the appliance as exposed if it runs a build on the 8.0, 7.6, 7.4, 7.2 or 7.0 branch at or below the versions in the tables above and its web interface accepts requests from networks you do not control. Record the exact build number and whether the IBE service is on. Fortinet’s advisory does not spell out the exact conditions for exploitation, so do not rule an appliance out on the IBE setting alone until you have confirmed it in the configuration.

2. Preserve logs before you change the configuration

The indicators Fortinet published are log entries. Export the system event logs and encryption logs off the appliance first, and take a snapshot if FortiMail runs as a virtual machine. A compromised appliance can have its local logs altered, and a later upgrade or rebuild may discard them. Our piece on logging for incidents rather than dashboards covers why off-device copies matter.

3. Apply the workaround

Fortinet’s primary workaround is to disable IBE feature support. In the GUI, the advisory gives the path as Encryption, then IBE, then set IBE Service to off. From the CLI:

config system encryption ibe
set status disable
end

The trade-off is functional: with the service off, FortiMail stops providing IBE encrypted delivery. If your organization relies on it for outside recipients, tell the people who use it before you switch it off, and decide what they should use in the meantime.

The advisory lists two alternatives:

• Disable access to the FortiMail webmail interface from the internet, or limit access to a trusted private network.
• If a web application firewall sits in front of FortiMail, block POST requests to /ibe that contain ../.

Our assessment, not Fortinet’s: treat the firewall rule as the weakest of the three. A rule that matches the literal string ../ depends on how the firewall decodes and normalizes a request before matching, and this flaw involves a second trick (the NULL byte) alongside the traversal. Removing the exposed feature or the exposed interface does not depend on matching the attacker’s exact input.

4. Check for compromise

Search the exported logs for the patterns above:

• Any archive account you did not create, especially one with a remote destination. archive234 is the name in Fortinet’s example; an attacker can choose a different one, so review every archive account, not only that name. Beazley Security gives the GUI location as Email Archiving, then Archive Account.
• Cron entries running shell commands as root.
• Administrator logouts recorded as coming from (null).
• IBE decryption errors mentioning Invalid Base64 Encoding.
• Connections to or from 79.141.169.187 and 45.129.0.192 in firewall and proxy logs, not only on the appliance.

If you have shell-level visibility through Fortinet support, compare against the file list above. A clean result lowers the likelihood of this specific activity. It does not prove the appliance is clean.

5. If you find indicators

Fortinet’s advisory gives no recovery procedure, so this is general incident response practice rather than vendor guidance:

• Isolate the appliance and open a case with Fortinet support.
• Remove the unauthorized archive account, and work out from its creation time in the logs how long mail was being copied. That period defines what may need to be reported under your breach notification obligations.
• Rotate credentials the appliance holds or has seen: administrator passwords, LDAP bind accounts, API keys and TLS private keys.
• Plan a rebuild from known good firmware rather than cleaning files by hand. Several of the reported files, including an ld.so.preload entry, are the kind used to reload attacker code after a restart.

6. Upgrade when the builds ship

Watch the advisory for the release of 8.0.2, 7.6.7 and 7.4.9, and upgrade when your branch is available. Keep the workaround in place until then. If you run 7.2, start planning the move to 7.4 now, since that is the only path the advisory gives.

What the CISA deadline means for you

CISA added CVE-2026-104286 to its Known Exploited Vulnerabilities (KEV) catalog on October 1, 2026, the same day Fortinet published. The catalog entry sets a due date of October 4, 2026 and marks forensic triage as required.

Two points of scope. First, the due date comes from Binding Operational Directive 26-04, which, according to Tenable’s analysis of the directive, applies to US Federal Civilian Executive Branch agencies and is not binding on private companies. Second, the required action in the entry is to “apply mitigations in accordance with vendor instructions” or to “discontinue use of the product if mitigations are unavailable.” With the fixed builds listed as upcoming, the vendor instruction available today is the workaround.

For everyone outside the US federal government, read the three-day window as a statement of urgency, and note that CISA paired the mitigation with a compromise check. That is the same sequence as the steps above.

The pattern worth fixing afterward

This section is editorial analysis rather than reported fact.

A mail gateway is an unusually valuable thing to compromise. It reads every message, it is trusted by the mail servers behind it, and it is expected to accept connections from anywhere. Three habits reduce the cost of the next advisory like this one:

• Turn off web-facing features you do not use. The exposed surface here was one optional feature. An inventory of which optional services are enabled on each edge device turns “are we affected?” into a lookup.
• Alert on configuration changes that redirect data. A new archive destination, a new forwarding rule or a new administrator account on a mail system should raise an alert whoever makes the change.
• Do not let one data source decide exposure. This week the advisory and the CVE record disagree. A process that checks the vendor advisory for any actively exploited flaw would catch that.

We covered the same patch-then-hunt sequence for a different edge device in the Citrix NetScaler zero-days, and the general response order in what a zero-day is and how to respond to one. For where this belongs in your queue, see the vulnerability backlog that never shrinks.

Sources and verification

Checked on October 4, 2026. We did not test the workaround or the indicators on a FortiMail appliance; the commands and log patterns are quoted from Fortinet’s advisory.

If you run Citrix NetScaler ADC or NetScaler Gateway and are not yet on one of the fixed builds listed below, upgrade now. If the appliance was reachable from the internet at any point in September, also assume the upgrade is only half the job: both flaws were being exploited before Citrix disclosed them, and none of the vendor reports says an upgrade removes what attackers installed.

This article covers what is confirmed, where the vendor reports differ, and the order to work in.

What Citrix disclosed

On September 27, 2026, Citrix published security bulletin CTX697096 covering eight vulnerabilities, CVE-2026-88771 through CVE-2026-88778. Two of them were already under attack. BleepingComputer quotes the bulletin as saying exploits of CVE-2026-88771 and CVE-2026-88772 “on unmitigated NetScaler deployments have been observed.”

The details below come from the CVE records that NetScaler itself published as the CVE Numbering Authority (the organization authorized to assign and describe CVE IDs for its own products).

CVSS (Common Vulnerability Scoring System) is the industry-standard 0 to 10 severity scale; these scores use version 4.0.

The other six CVEs in the bulletin, CVE-2026-88773 through CVE-2026-88778, carry CVSS 4.0 base scores between 7.0 and 9.3 in their CVE records. As of October 3, 2026, none of the six is in CISA’s Known Exploited Vulnerabilities catalog. All eight records list the same fixed builds.

Affected and fixed builds

A formatting note: seven of the eight CVE records write the last build as “13.1.37.279”, while the record for CVE-2026-88773 and Tenable’s summary write “13.1-37.279”, the format NetScaler build numbers normally use. We read these as the same build; confirm the exact build string on the Citrix download page before upgrading a FIPS or NDcPP appliance.

Versions 12.1 and 13.0 are end-of-life and receive no security updates. Tenable noted on September 27 that Citrix had not said whether they are affected. If you still run either, the absence of a statement is not evidence of safety; plan the migration rather than waiting for one.

The DTLS precondition

Rapid7 and Tenable both report that CVE-2026-88771 affects default configurations, while CVE-2026-88772 requires DTLS to be enabled. DTLS (Datagram Transport Layer Security) is TLS adapted for UDP, and NetScaler Gateway uses it on UDP port 443 alongside the usual TCP port 443.

That precondition narrows less than it sounds. NetScaler’s own documentation states: “By default, the DTLS functionality is set to ON for the existing SSL VPN virtual server.” Unless someone turned it off, a Gateway deployment meets the condition.

What is known about exploitation

Three security vendors have published observations. They do not contradict each other, but each describes only what its own telemetry or incident response work showed, so the dates differ.

The practical reading: the exposure window for an unpatched, internet-facing appliance opened weeks before the bulletin, not on the day of it. Unit 42 does not attribute the activity to a named group.

On scale, Unit 42 says its Cortex Xpanse scanning “identified 50,277 exposed instances that could potentially be vulnerable” as of September 27, 2026. That is a count of exposed appliances, not of confirmed compromises.

Tenable reported no public proof-of-concept exploit for either flaw as of September 27, 2026. Rapid7 reports that exploitation widened after disclosure. Treat the September 27 statement as a point in time, not a current guarantee.

What attackers did after getting in

The behavior described by Google and Rapid7 explains why patching alone is not enough:

• Configuration theft. Rapid7 observed tar czf /var/netscaler/gui/vpn/c -C /flash nsconfig, which packs the configuration directory into a location the web server will hand out. Rapid7 notes that directory holds encrypted administrator passwords, SSL certificates and private keys, and SSH host keys.
• Web shells behind innocent-looking extensions. Google documented changes to /etc/httpd.conf that make Apache run .deb and .sig files as PHP, plus an AliasMatch rule that maps .ico requests under /vpn/media/ onto those files. The shells answer with HTTP 404, so they look like misses in a casual log review.
• Root persistence. Google observed chmod u+s /bin/sh, which sets the SUID bit so later web requests execute with root privileges.
• Tunneling into the network. Google named two tools: WHIPSHOT, a PHP web shell acting as a tunnel front end, and SLAPSHOT, a Python proxy that listens on a loopback port and records it in /tmp/.uxdport.

What to do, in order

1. Preserve evidence before you change anything

If the appliance is a virtual machine, take a snapshot that includes memory before rebooting or upgrading. Google recommends this explicitly, and Citrix’s guidance for a suspected compromise lists a snapshot, a technical support bundle and a packet engine core dump as the first step. An upgrade reboots the device and discards memory-only evidence.

2. Upgrade to a fixed build

Move to the fixed build for your branch from the table above. Google lists the upgrade as its recommended option and advises opening a Severity 1 support case with Citrix if you cannot locate the right build.

If you cannot upgrade immediately, Google describes compensating controls for CVE-2026-88772 only:

• Disable DTLS on internet-facing Gateway virtual servers where you do not need it. The documented command is set vpn vserver <name> -dtls off.
• Block inbound UDP port 443 on the perimeter firewall or edge router. Google warns that ACLs on the appliance are not sufficient, because the traffic reaches the vulnerable packet engine first.

Neither control addresses CVE-2026-88771. They buy time for one of the two bugs; they are not a substitute for the upgrade.

3. Hunt for compromise

Run these on the appliance shell. All commands are taken from Google’s published hunting guidance. A clean result reduces the likelihood of this specific tooling; it does not prove the device is clean.

Check for tampering in the web server configuration:

grep -En -i "application/x-httpd-php|php_flag|AliasMatch" /etc/httpd.conf

Look for handlers that register non-PHP extensions such as .deb or .sig as PHP, and for AliasMatch rules pointing /vpn/media/, /vpn/theme/ or /vpn/images/ at script directories.

Search the web directories for PHP where none belongs:

grep -rlE "<\?php|eval\(|base64_decode\(|shell_exec\(" /var/netscaler/gui/ /netscaler/ns_gui/ /var/vpn/ /netscaler/portal/ 2>/dev/null

Check for the tunneling tool’s files, the SUID shell and stray Python processes:

ls -la /tmp/.uxdport* /tmp/.uxdlock
ls -l /bin/sh
ps aux | grep -E "python.*(\.uxd|uxdport|uxdlock|base64)"

Permissions of -rwsr-xr-x on /bin/sh indicate the SUID change. Either /tmp/.uxd* file means the proxy is running or ran recently.

Also check for two artifacts from Rapid7’s report: a file at /var/netscaler/gui/vpn/c, which is the output path of the archive command it observed, and a web shell at /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver.

In logs, Google flags two patterns worth alerting on. The first is a DTLS handshake failure with ClientVersion DTLSv1.0 and the reason “Handshake failure-Internal Error”, followed within minutes by a crash of NSPPE (the NetScaler Packet Processing Engine) in /var/log/messages. The second is HTTP 404 responses to /vpn/media/*.ico that carry multi-kilobyte bodies.

Network indicators such as IP addresses and file hashes change quickly. Pull current lists from the Google, Rapid7 and Unit 42 reports rather than a copy in an article. Google also publishes YARA rules for the web shells and the configuration tampering.

4. If you find anything, rebuild rather than clean

Citrix’s guidance for a suspected compromise is to remove the appliance from the network, erase and reinstall firmware, upgrade to the latest version, and restore a known good backup that predates the compromise. Google adds one step that is easy to miss in a high-availability pair: disable HA synchronization and assess each node on its own, so a tampered configuration is not replicated to the healthy node.

Given the early September exploitation dates above, a “known good” backup should predate early September 2026 at a minimum, not merely the bulletin. That is our inference from the reported timeline, not vendor guidance.

5. Rotate what the appliance knew

Because the configuration directory was a target, Google advises assuming credentials on a compromised appliance are exposed, and rotating them after the appliance is patched:

• NetScaler administrator and local account passwords, and SSH keys
• TLS certificates and their private keys
• LDAP bind and service accounts, RADIUS shared secrets, TACACS credentials
• SNMP community strings and NITRO API credentials

Invalidate active administrative, Gateway and VPN sessions as well. Citrix’s guidance goes further on restored devices: rotate the Key Encryption Keys and replace all SSL certificates.

Then look downstream. Google recommends reviewing StoreFront servers, Delivery Controllers and virtual desktop hosts for unexpected interactive logons, RDP activity and signs of credential dumping, since the appliance sits directly in front of them.

What the CISA deadline means for you

CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog on September 27, 2026, with a due date of September 30, 2026. The catalog entry also requires forensic triage, noting that “customers must conduct forensic triage as directed by BOD 26-04.”

Two points of scope. First, according to Tenable’s analysis of Binding Operational Directive 26-04, CISA issued the directive on June 10, 2026, it applies to US Federal Civilian Executive Branch agencies, and it is not binding on the private sector, though CISA encourages adoption. Second, the due date has already passed. For an organization outside the federal government, the deadline is useful as a signal: three days is the shortest remediation window in the directive as Tenable describes it, and CISA paired the patch with a mandatory compromise check, which is the same sequence recommended above.

The pattern worth fixing after the incident

This section is editorial analysis rather than reported fact.

Edge appliances are attractive targets for structural reasons: they face the internet by design, they hold credentials for the directory and authentication systems behind them, and most cannot run the endpoint detection agents that cover servers and laptops. Three changes reduce the cost of the next advisory of this kind:

• Ship appliance logs off the device. The hunting steps above depend on ns.log, /var/log/messages and the HTTP access and error logs. Logs that live only on the appliance are available to whoever compromises it. Our piece on logging for incidents rather than dashboards covers what to retain.
• Default-deny outbound traffic from the appliance. Google recommends permitting only approved destinations such as DNS, NTP, certificate status checks and the backend applications. A tunneling tool is far less useful on a device that cannot open arbitrary connections.
• Keep management interfaces off the internet. Restrict the NSIP management address, SSH and the NITRO API to administrative networks.

For triage of the rest of your queue, an actively exploited flaw on an internet-facing device is the case that should jump every line. We cover that prioritization in the vulnerability backlog that never shrinks, and the general response sequence in what a zero-day is and how to respond to one.

Sources and verification

Checked on October 3, 2026. We could not load the Citrix bulletin page directly, so bulletin details are taken from the CVE records NetScaler published and from vendors quoting the bulletin; those rows are marked Qualified.

FirewallSync has not tested these vulnerabilities or run the hunting commands against a compromised appliance. This is research-based analysis of the sources above.

Most logging strategies get built to answer “what does normal look like” — the questions a dashboard needs. Incident response needs the opposite: enough detail to reconstruct exactly what an attacker did, in order, across systems that don’t share a clock or a request ID. Those are different design goals, and optimizing for one quietly starves the other.

Correlation IDs matter more than log volume

Teams often respond to “we couldn’t reconstruct the incident” by logging more of everything, which mostly adds noise. The actual gap is usually that a request touching five services produces five sets of logs with no shared identifier linking them. A consistent correlation ID propagated through every service call turns a volume problem into a query problem — you can pull the full story in one search instead of manually time-correlating timestamps across systems that drift by seconds.

Log the auth decision, not just the auth attempt

Most systems log “login succeeded” or “login failed” but not why an authorization check passed or failed for a specific resource — which role, which policy, which condition matched. During an incident, “did this account have access to this resource, and under what policy” is one of the first questions asked, and without decision-level logging, answering it means reverse-engineering the access control logic from scratch under time pressure.

Retention matters more than most teams budget for

Attackers increasingly wait weeks or months between initial access and objective — meaning the logs you need to reconstruct the intrusion may have already rolled off retention by the time you’re investigating. Check your actual log retention against your industry’s typical dwell time, not against your storage budget’s comfort zone; a shorter retention window than your realistic detection lag means some incidents are unreconstructable by design, regardless of how good your logging schema is.

A tabletop exercise where everyone sits in a conference room and narrates what they’d do tests whether people remember the runbook. It doesn’t test whether the runbook survives contact with a real incident — degraded communication tools, a key person on vacation, or an attacker who doesn’t follow the scenario’s script.

Run at least one exercise with a communication channel down

The single most common real-incident failure mode isn’t a missing step in the runbook — it’s that Slack, your usual coordination tool, is either compromised or unavailable (because it’s hosted on the infrastructure that’s on fire). If your tabletop always assumes normal tooling, you’ve never actually tested your incident response — you’ve tested your ability to read a document out loud. Run one exercise per year with the primary comms channel explicitly ruled out of scope.

Inject a wrong turn, not just a scenario

Most tabletop scripts hand the team accurate information and let them respond correctly. Real incidents include red herrings — a misleading log entry, an alert that points at the wrong service, a well-meaning engineer who changes something mid-incident without telling anyone. Build at least one deliberate wrong signal into your next exercise and see how long it takes the team to notice and correct course; that recovery time is a more useful metric than whether they reached the “right” answer eventually.

Test the decision-maker’s availability, not just their competence

Plans routinely name a single incident commander with no tested backup. Pick a tabletop date and explicitly remove that person from the exercise without warning the rest of the team beforehand — if response quality collapses, you’ve found a single point of failure that a real 2am incident will find for you anyway, just with worse timing.

Most orgs respond to alert fatigue with rotation schedules, mental health check-ins, or hiring more analysts. All reasonable, none of them fix the actual problem: a detection pipeline generating more noise than signal, which is a tuning failure, not a staffing shortfall.

Track signal-to-action ratio, not alert volume

Counting total alerts tells you nothing useful — it doesn’t distinguish between 10,000 alerts that each require a decision and 10,000 that are auto-closeable duplicates. The metric that matters is what fraction of alerts result in an actual action (escalation, ticket, remediation) versus a dismiss-and-forget. If that ratio is under 5%, your rules are too broad, and adding headcount just spreads the same noise across more people instead of removing it.

Kill rules before you tune them

The instinct when a rule is noisy is to tighten its thresholds. Often the faster fix is deleting it and confirming nothing important was riding on it — most legacy detection rules were written for an environment that no longer exists, and nobody owns the decision to retire them. Run a 90-day audit of which rules have never once led to a real action, and sunset them explicitly rather than letting them quietly erode trust in the rest of the pipeline.

Separate “needs a human now” from “needs a human eventually”

A huge share of fatigue comes from routing informational alerts through the same channel as ones requiring immediate triage. If a Slack channel or pager gets both “unusual login from a new device, self-resolved” and “ransomware indicator on a production host,” analysts learn to skim everything — including the alert that actually mattered. Split your routing by required response time, not by source system, and the urgent channel becomes trustworthy again.

Blameless postmortems are now the default at most engineering orgs, which is progress. But a document being blameless doesn’t automatically make it useful. The most common failure mode isn’t blame creeping back in — it’s that the postmortem produces a list of action items that never get prioritized against feature work, so the same root cause resurfaces in six months wearing a different symptom.

The action item graveyard

If your postmortem template has an “action items” section with no owner, no deadline, and no forcing function to revisit it, you don’t have a prevention process — you have a documentation exercise. Action items from incidents need to compete for sprint capacity the same way any other ticket does, with a visible cost to deferring them repeatedly.

Root cause is rarely singular

Most postmortems stop at the first plausible technical explanation: a bad deploy, a missing rate limit, an expired certificate. The more useful question is what allowed that technical failure to become a customer-facing incident — was there no monitoring on that path, no runbook, no one on call who knew the system well enough to catch it early? Fixing the technical trigger without fixing the detection gap guarantees a different trigger produces the same outcome later.

Track recurrence, not just resolution

Most incident tracking measures time-to-resolution and calls it done. Add one more metric: how many incidents this quarter share a root cause category with an incident from last quarter. If that number isn’t trending toward zero, your postmortem process is documenting problems, not solving them.

What a working process looks like

• Every action item gets a named owner and a sprint, not a someday-list
• Postmortems ask what let the failure surface to users, not just what failed technically
• Recurrence rate is tracked as a metric leadership actually looks at

The blameless part was never the hard part. Follow-through is.