Scope. This post is based on the CVE record published by Wordfence (the CNA), the CISA KEV entry and CISA’s SSVC assessment, the WordPress 7.1.4 release notes, and a diff we ran of the WordPress 7.1.3 and 7.1.4 source files. The exploitation telemetry is Wordfence’s, as reported by The Hacker News. We did not reproduce the attack.

What the vulnerability is

The CVE record’s description says: “WordPress Core is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3. This is due to predictable, web-accessible staging paths used during full-package core upgrades. This makes it possible for unauthenticated attackers to execute code on the server during the upgrade window.”

The attack complexity is High for a reason: the attacker has to hit files that exist only while a core update runs. According to The Hacker News’s summary of Wordfence’s analysis, exploitation needs a full-package update that includes the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time before WordPress deletes the temporary files. The same report says attackers have been repeatedly polling paths such as setup-config.php.

“Automatable: no” in the SSVC entry does not make this low priority. It reflects the narrow timing window, not the impact. Combined with active exploitation and total technical impact, it still puts the CVE near the top of a queue; our SSVC guide shows how your own mission and exposure values turn those three into a decision, and every public WordPress site is internet-facing.

Fixed versions

WordPress released 7.1.4 on 28 October 2026 and says: “Because this is a security release, it is recommended that you update your sites immediately.” The release fixes this issue (“A race condition during core updates that could lead to remote code execution reported by Umut Bayram”) along with 21 other listed items.

The CVE record lists 25 affected branches, each with an inclusive upper limit (lessThanOrEqual). We checked each against the backport list in the release notes; in every branch the fixed release is the next point release.

WordPress adds that backports are “a courtesy” and that “only the most recent version of WordPress is actively supported.” Sites on 4.6 or earlier get no fix at all.

What changed in 7.1.4

We fetched wp-admin/includes/class-wp-upgrader.php and wp-admin/includes/update-core.php from the 7.1.3 and 7.1.4 tags of the WordPress/WordPress GitHub mirror and diffed them. Three changes stand out.

1. The staging folder name becomes unguessable. In 7.1.3, unpack_package() names the working directory after the downloaded package file: $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' ), inside wp-content/upgrade/. In 7.1.4 a new get_working_dir_name() appends '-' . wp_generate_password( 16, false ).
2. The upgrade folder can no longer be listed. 7.1.3 deletes everything in wp-content/upgrade/ before unpacking. 7.1.4 skips index.php during that cleanup and writes one if missing, with a comment that the directory “is web-served” and must not be listed “so the name of the working directory created below cannot be discovered from a directory index.”
3. A staged wp-config.php is never copied into the live site. update_core() in 7.1.4 adds wp-config.php to the list of files it skips when copying the new release over the old one, with the comment “Never copy a wp-config.php, which could have been written to the working directory.”

Read together, the fix closes both halves of the race: finding the staged copy, and turning a file written into it into something that persists after the update. That is our reading of the diff; the CNA’s own advisory is the authority on the exploit chain.

Why the update itself is the risky moment

The vulnerable step runs in the code that is already installed. When WordPress updates core, Core_Upgrader::upgrade() calls unpack_package() from the running version’s WP_Upgrader class, and only then copies the new release’s update-core.php into place and runs it. So updating a 7.1.3 site to 7.1.4 stages the 7.1.4 package with the 7.1.3 naming and cleanup logic. The new wp-config.php skip does apply during that update, because it lives in the new update-core.php, but the staging folder is still predictable and listable for that one run.

Two practical consequences:

• Block the staging path before you update, not after. A web server rule that refuses every request under /wp-content/upgrade/ removes the public half of the race. WordPress writes to that folder through the filesystem, not over HTTP, so it should not need web access to it.
• Do not rely on a rule file inside wp-content/upgrade/. Affected versions delete everything in that folder before unpacking, so a .htaccess placed there is gone when it matters.

Illustrative configuration (we did not test these against a live site; adapt paths for subdirectory installs):

# nginx, inside the WordPress server block
location ^~ /wp-content/upgrade/ {
    deny all;
}

# Apache, in the site's root .htaccess or vhost (mod_alias)
RedirectMatch 403 ^/wp-content/upgrade/

Also check whether automatic updates already did the work. In 7.1.4’s Core_Upgrader::should_update_to_version(), the minor auto-update setting reads get_site_option( 'auto_update_core_minor', 'enabled' ), so minor (security) releases install automatically unless the WP_AUTO_UPDATE_CORE constant, a filter or that option turns them off. Many sites will have moved to their branch’s fix on their own; managed hosts and fleets that disable auto-updates will not have.

What to do this week

1. Inventory versions. On each site, wp core version (WP-CLI) or wp-includes/version.php gives $wp_version. Anything at or below its branch’s “last affected” row above needs the update. Anything on 4.6 or earlier needs a migration plan.
2. Block /wp-content/upgrade/ at the web server, reload, and confirm with a request that it returns 403.
3. Update to 7.1.4, or to your branch’s fixed release if you cannot move to 7.1 yet.
4. Check for leftovers. CISA marks this entry for forensic triage. At minimum:

# Run from the WordPress root. Illustrative; adapt the log path.
wp core verify-checksums                 # core files that differ from the release
ls -la wp-content/upgrade/               # should be empty apart from index.php after 7.1.4
find . -name 'wp-config.php' -not -path './wp-config.php'   # unexpected copies
grep -E '/wp-content/upgrade/' /var/log/nginx/access.log* | grep -v ' 403 '

Requests to /wp-content/upgrade/.../setup-config.php or install.php that did not get a 403, especially close to the time of a core update, are the lead to follow. Look for PHP files that verify-checksums does not explain, new administrator accounts, and changes to wp-config.php since the update.

5. Record the decision. If you track patch decisions as tickets, this is a KEV entry with active exploitation and total technical impact on internet-facing hosts; our vulnerability prioritization workflow shows how to carry those signals into the ticket, and the KEV JSON feed guide explains the dueDate and forensicTriage fields.

Limits of this article

• We did not reproduce exploitation. The preconditions and the 62,969-attack figure come from Wordfence via The Hacker News; we could not retrieve Wordfence’s own advisory page in this run.
• Which update package a given site downloads (full, no-content or partial) depends on what the WordPress update API offers it; we did not test which update paths stage the installer files.
• The web server rules are illustrative and untested; test them on a staging site first.

Sources and verification

Scope. This is a workflow guide built on public specifications and feeds, plus one script we ran. On November 2, 2026 we read the CVE JSON schema (5.2.0), CISA’s Vulnrichment README, CERT/CC’s SSVC deployer documentation and decision table, the OpenVEX specification and the EPSS repository README, and ran the script below against the KEV catalog (version 2026.10.30), the EPSS file scored 2026-11-01 and CVE records from cvelistV5. The assets, exposure ratings and the VEX document in the test are invented for the demonstration. The policy choices in the script are ours, not a standard.

The workflow in one table

Our comparison of CVSS, EPSS and KEV explains what each signal measures. This guide is the plumbing: the order in which a finding from a scanner or SBOM passes through the data, and what lands in the ticket.

Steps 1 to 3 remove work. Steps 4 to 6 order what remains.

Step 1: check the record state

A CVE record is either PUBLISHED or REJECTED (the schema’s two states), and published records can carry tags such as disputed. A rejected ID has no affected products to evaluate. In our test run, CVE-2026-23915 is a Fortinet-assigned ID that was rejected on January 20, 2026 with the reason “Not used”, so the finding closes. Our guide to CVE record states covers the tags and edge cases.

Step 2: confirm you are affected

The CNA’s affected block is an algorithm, not a list: walk versions, take the first match, otherwise use defaultStatus, and if that is missing the schema says the status is unknown. Scanner results that only match a product name skip this. Our explainer on CVE affected versions shows how lessThan, defaultStatus and versionType combine, with a tested evaluator. Keep three outcomes apart in the ticket: affected, unaffected, and unknown or undetermined. The last needs a person or the vendor advisory.

Step 3: apply supplier VEX

If the vulnerable component ships inside someone else’s product, the supplier may publish a VEX (Vulnerability Exploitability eXchange) statement. OpenVEX defines four statuses: not_affected (“No remediation is required regarding this vulnerability”), affected, fixed and under_investigation. A not_affected statement must carry a justification or an impact statement.

Two cautions. A VEX statement is about a specific product and version, so match on the product identifier, not on the CVE alone; a not_affected statement from an appliance vendor says nothing about your own services that use the same library. And read the justification before closing. Our guide to reading a VEX not-affected statement covers the five justifications and what to question.

Step 4: read the exploitation evidence

Two public sources answer “is this being exploited?”:

• KEV. The CISA KEV JSON feed lists CVEs with evidence of exploitation, with dateAdded, dueDate, knownRansomwareCampaignUse and, on newer entries, forensicTriage. The catalog we used (version 2026.10.30, released October 30, 2026) had 1,766 entries.
• CISA’s SSVC values in the CVE record. CISA’s Vulnrichment project writes three SSVC decision points (Exploitation, Automatable, Technical Impact) into a CISA-ADP container. Its README says CISA is “assessing new and recent CVEs”, and that it will not overwrite the CNA’s data. Each value set carries a timestamp. Our Vulnrichment guide shows where they sit and how to pull them with jq.

The SSVC documentation describes Exploitation as “the present state of exploitation”, not a prediction. A none from months ago can be stale, so a KEV listing should outrank an older ADP value. That is the rule our script applies.

Step 5: add EPSS for likelihood

For findings with no exploitation evidence, EPSS estimates “the probability [0-1] of exploitation in the wild in the next 30 days”, and percentile gives the share of scored CVEs with the same or a lower score. The file we used (model v2026.06.15, scored 2026-11-01) held 398,784 CVEs. EPSS is a ranking aid within the non-exploited queue. It does not replace step 4: in our run the KEV-listed FortiMail flaw scored 0.04573. See the EPSS data feed guide for the columns, model-version breaks and a scanner join.

Step 6: let exposure and impact decide

CERT/CC’s SSVC deployer model maps four inputs to a patch priority:

The decision table (deployer_patch_application_priority_1_0_0.csv, 72 rows) returns one of four outcomes, which the deployer documentation defines as: Defer (“Do not act at present”), Scheduled (“Act during regularly scheduled maintenance time”), Out-of-cycle (“Act more quickly than usual… during the next available opportunity”) and Immediate (“Act immediately; focus all resources on applying the fix”). In the table, Immediate appears in 3 rows, all with active exploitation and open exposure. Our SSVC deployer explainer walks through the inputs, including where Human Impact is easy to get wrong.

One mapping detail: CISA’s ADP data writes poc, while the deployer table uses public poc. They are not identical definitions. CISA’s tree uses the older PoC value, which also covers privately attested exploitation and widespread hearsay; the newer Public PoC value covers only public exploit code or a well-known method. Our script maps one to the other, which can understate cases CISA marked poc on private evidence.

A tested script that writes the ticket fields

The script reads a findings CSV, the KEV JSON, the EPSS daily file, the SSVC deployer CSV, a folder of CVE records and an optional OpenVEX file, and prints one ticket row per finding. Python 3.10 or later, standard library only.

#!/usr/bin/env python3
"""Turn scanner findings into patch-decision ticket rows.

Inputs : findings.csv (asset,product,cve,exposure,human_impact)
         KEV JSON, EPSS daily CSV (.csv.gz), SSVC deployer table CSV,
         a directory of cvelistV5 records, optional OpenVEX file.
Output : tickets.csv on stdout. Python 3.10+, standard library only.
"""
import csv, gzip, json, sys, argparse, pathlib

def load_kev(path):
    data = json.load(open(path))
    return {v["cveID"].strip().upper(): v for v in data["vulnerabilities"]}

def load_epss(path):
    scores = {}
    with gzip.open(path, "rt") as fh:
        rows = (line for line in fh if not line.startswith("#"))
        for r in csv.DictReader(rows):
            scores[r["cve"]] = (float(r["epss"]), float(r["percentile"]))
    return scores

def load_deployer(path):
    rows = list(csv.reader(open(path)))
    return {tuple(r[1:5]): r[5] for r in rows[1:]}

def load_vex(path):
    out = {}
    if path:
        for s in json.load(open(path)).get("statements", []):
            for p in s.get("products", []):
                out[(s["vulnerability"]["name"].upper(), p["@id"])] = s
    return out

def cisa_ssvc(record):
    """Return CISA ADP SSVC values (Exploitation, Automatable, Technical Impact, timestamp)."""
    for adp in record["containers"].get("adp", []):
        for m in adp.get("metrics", []):
            other = m.get("other", {})
            if other.get("type") == "ssvc":
                c = other["content"]
                opts = {k: v for o in c["options"] for k, v in o.items()}
                return (opts.get("Exploitation"), opts.get("Automatable"),
                        opts.get("Technical Impact"), c.get("timestamp"))
    return (None, None, None, None)

def main():
    ap = argparse.ArgumentParser()
    for a in ("findings", "kev", "epss", "deployer", "records"):
        ap.add_argument(a)
    ap.add_argument("--vex")
    args = ap.parse_args()
    kev, epss = load_kev(args.kev), load_epss(args.epss)
    table, vex = load_deployer(args.deployer), load_vex(args.vex)
    out = csv.writer(sys.stdout)
    out.writerow(["asset", "cve", "record_state", "vex_status", "kev_dateAdded",
                  "kev_dueDate", "kev_ransomware", "cisa_exploitation", "cisa_automatable",
                  "cisa_technical_impact", "cisa_ssvc_timestamp", "epss", "epss_percentile",
                  "deployer_exploitation", "deployer_priority", "next_step"])
    for f in csv.DictReader(open(args.findings)):
        cve = f["cve"].strip().upper()
        rec_path = pathlib.Path(args.records) / f"{cve}.json"
        if not rec_path.exists():
            out.writerow([f["asset"], cve, "NO RECORD"] + [""] * 12 + ["check the ID"])
            continue
        rec = json.load(open(rec_path))
        state = rec["cveMetadata"]["state"]
        if state == "REJECTED":
            out.writerow([f["asset"], cve, state] + [""] * 12 + ["close: CVE ID rejected"])
            continue
        v = vex.get((cve, f.get("product", "")), {})  # VEX applies to one product, not every asset
        k = kev.get(cve, {})
        exp, auto, ti, ts = cisa_ssvc(rec)
        e, pct = epss.get(cve, ("", ""))
        # Our policy choice: a KEV listing counts as active exploitation, whatever
        # the (possibly older) CISA ADP snapshot says. CISA writes "poc"; the
        # deployer table writes "public poc".
        dexp = "active" if k else {"poc": "public poc"}.get(exp, exp)
        prio = ""
        if dexp and auto:
            prio = table.get((dexp, f["exposure"], auto, f["human_impact"]), "")
        if v.get("status") == "not_affected":
            step = "close: supplier VEX not_affected (" + v.get("justification", "no justification") + ")"
        elif not prio:
            step = "manual triage: no CISA SSVC data"
        else:
            step = prio
        out.writerow([f["asset"], cve, state, v.get("status", ""), k.get("dateAdded", ""),
                      k.get("dueDate", ""), k.get("knownRansomwareCampaignUse", ""),
                      exp or "", auto or "", ti or "", ts or "", e, pct, dexp or "", prio, step])

if __name__ == "__main__":
    main()

The test input (findings.csv) used invented assets with real CVE IDs:

asset,product,cve,exposure,human_impact
edge-mail-01,fortimail,CVE-2026-104286,open,high
k8s-node-17,linux-kernel,CVE-2026-46300,controlled,medium
build-runner-03,pkg:cargo/gix-fs@0.22.1,CVE-2026-100419,small,medium
billing-api,pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1,CVE-2021-44228,open,very high
vendor-appliance-2,pkg:generic/example-appliance@4.2,CVE-2021-44228,open,very high
legacy-scan,unknown,CVE-2026-23915,open,low

The VEX file is an invented OpenVEX document from an “Example Appliance Vendor” stating not_affected with justification vulnerable_code_not_present for CVE-2021-44228 in pkg:generic/example-appliance@4.2. We ran:

python3 patch_decision.py findings.csv known_exploited_vulnerabilities.json \
  epss_scores-2026-11-01.csv.gz deployer_patch_application_priority_1_0_0.csv \
  records/ --vex vendor.openvex.json > tickets.csv

The data came from raw.githubusercontent.com/cisagov/kev-data, the empiricalsec/epss_scores repository (2026/epss_scores-2026-11-01.csv.gz), CERTCC/SSVC (data/csv/ssvc/) and CVEProject/cvelistV5 at commit 451e97a. Output, with some columns dropped for width:

Three things in that output are worth noticing:

• The same CVE got two different answers (Log4Shell rows) because the VEX statement applies to one product only.
• A KEV-listed kernel flaw came out Scheduled. CVE-2026-46300 is in KEV with forensicTriage: Yes and a three-day federal due date, but with controlled exposure, no automatability and medium Human Impact the deployer table says Scheduled. If you follow CISA’s directives, the due date wins. If you do not, the table is telling you the exposure is what drives urgency. Either way, keep both fields in the ticket, and consider a compromise check when forensicTriage is Yes; our BOD 26-04 explainer covers what that flag asks agencies to do.
• EPSS and KEV disagreed on FortiMail, as expected: one estimates future observed activity, the other records evidence already seen.

What the ticket should hold

Store the inputs, not just the priority, so a reviewer can see why. A suggested field list (ours, not a standard):

Keeping it current

The feeds move at different speeds: CISA updates KEV on weekdays, EPSS publishes daily, and CVE records and VEX documents change when their authors revise them. Re-run the flow on a schedule and on any change to a ticket’s inputs, and alert when a finding’s priority rises. Set your service-level targets per priority (for example, how many days “Out-of-cycle” means for you) in policy, not in the script; the deployer model does not define days.

Limits of this article

The script is a working example, not a product. It reads CVE records from a local folder (it does not fetch them), does not evaluate affected versions itself (pair it with a version check such as the evaluator in our affected-versions guide), handles OpenVEX JSON only, and uses one policy choice (KEV overrides an older CISA Exploitation value) that you may want to change. The four-value deployer inputs simplify real decisions: SSVC expects organizations to adapt trees to their context. We did not test it against commercial scanner exports.

Sources and verification

CVE-2026-41709 is not a bug that lets anyone in. It is a bug that helps whoever is already in avoid being seen. Broadcom fixed it on 29 July 2026 and rated it Low. On 28 October 2026 CISA added it to the Known Exploited Vulnerabilities (KEV) catalog, with a federal due date of 11 November 2026.

The short answer: update ESX hosts to the fixed build for your branch (ESX 8.0: ESXi80U3j-25429389; 9.0.x: ESXi-9.0.2.0100-25595025; 9.1.x: ESXi-9.1.0.0-25370933), confirm host logs are forwarded to a remote syslog collector, and treat any host that was compromised before patching as having an incomplete audit trail.

What the vulnerability is

Broadcom’s advisory, VMSA-2026-0006 (section 3e), describes it this way: “VMware ESX contains an insufficient logging vulnerability.” Its known attack vector: “A malicious administrator could exploit this issue to perform certain operations without them being logged.”

That is the whole public description. Broadcom does not say which operations escape logging, and the CVE record adds nothing beyond the weakness class, CWE-778 (Insufficient Logging). The advisory credits Ian Barton of CrowdStrike with reporting it. We found no public technical write-up or exploitation report as of 1 November 2026, so treat any claim about specific hidden operations with suspicion until Broadcom or the reporter publishes one.

Fixed builds

From the advisory’s response matrix, which matches the version ranges in the CVE record:

The CVE record lists ESX 9.1, 9.0 and 8.0 as affected and gives no ESX 7.0 entry for this CVE. The advisory’s August update (VMSA-2026-0006.2) added ESX 7.0 patch guidance for the Critical issues in the same advisory, not for this one.

To compare a host against the table, read its build number. On the host shell, esxcli system version get prints the version, update and build. Match the build number, not just the update name.

Why a Low score is the wrong signal here

CVSS scores the vulnerability in isolation. “Privileges required: high” pulls the score down, because an attacker first needs an administrator account. In an intrusion that reaches the hypervisor, the attacker may already have that account, and a way to then act without leaving entries in the host’s logs makes the response team’s job harder.

CISA lists vulnerabilities in KEV because of evidence of exploitation, not because of their score. Its SSVC entry for this CVE records “Exploitation: active”. CISA has not published details of the activity, and Broadcom’s advisory change log has no entry about exploitation. Our reading, which is interpretation and not a reported fact: this flaw is most likely being used as part of a chain, after an attacker has admin access by other means.

This is the situation CVSS vs EPSS vs KEV describes: a KEV listing should outrank a low base score. If you use SSVC, “active” exploitation with “partial” technical impact on a hypervisor you depend on usually lands well above routine patching; see our SSVC deployer walkthrough.

The vCenter half of the same advisory

VMSA-2026-0006 also fixed CVE-2026-59310, a vCenter directory-traversal flaw in the syslog server, which CISA added to KEV on 18 August 2026. Many teams patched vCenter quickly in August. ESX host updates are a separate job, usually rolled through clusters host by host, and they are easier to leave half done. If your August change record says “VMSA-2026-0006 remediated” and only covers vCenter, your hosts may still be on vulnerable builds.

Make the evidence leave the host

Patching stops the gap from being used from now on. It does not recover entries that were never written, and it does not protect the logs that are written from an admin who can delete them on the host. The control that helps in both cases is shipping logs off the host as they are written.

Broadcom’s KB Configuring syslog on ESXi notes that “by default in ESXi, these logs are placed on a local scratch volume or a ramdisk.” Its commands for sending them to a remote collector:

# On the ESXi host shell (per Broadcom KB 318939). Replace the address.
# Supported loghost formats include udp://host:514, tcp://host:514 and ssl://host:1514.
esxcli system syslog config set --loghost='ssl://syslog.example.internal:1514'
esxcli system syslog reload
esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true
esxcli network firewall refresh

We have not run these commands on a host; they are quoted from the KB. Prefer ssl:// where your collector supports it, set the same value through host profiles or your configuration tool so it does not drift, and alert when a host stops sending.

Broadcom’s log file reference lists the files worth prioritising on the collector:

Because Broadcom has not said which operations escape logging, you cannot write a detection for the missing entries themselves. What you can do is cross-check sources that an ESX-local gap would not touch: vCenter tasks and events, your collector’s copy of the host logs, and changes visible from outside the host (new VMs, changed datastores, powered-off guests). Logging for incidents, not for dashboards covers how to decide what to keep and for how long.

What to do this week

1. Inventory every ESX host and its build number; compare against the fixed-version table.
2. Patch hosts still below the fixed build. There is no workaround.
3. Confirm each host has a remote loghost set and that the collector has recent entries from it.
4. If a host was compromised, or admin credentials for it were exposed, before it was patched, record that its local logs may be incomplete for that period and lean on vCenter and remote copies for the investigation.
5. US federal civilian agencies: the KEV due date is 11 November 2026, with the BOD 26-04 requirements CISA attaches to the entry. The KEV entry’s forensic triage flag is “No”.

Limits of this article

Broadcom has not published which operations go unlogged, and CISA has not published the exploitation evidence behind the KEV listing. We have not tested the vulnerability or the fix. The esxcli commands are quoted from Broadcom’s knowledge base, not run by us. Check Broadcom’s advisory for updates before you rely on the fixed-version table.

Sources and verification

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

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.