KEV Supplement, September 13 to September 25, 2026: WordPress Core Under Active Exploitation, a Network-Reachable Kernel Flaw, and the Exploited Appliances the Catch-Up Could Not See

This supplement covers the half of the September 13 to 25 window that the September 25 catch-up declared it could not reach. That edition was written in an environment with no access to CISA KEV or any vendor advisory, so it covered the dependency surface only and said so. Those sources are reachable now, and the window held 17 KEV additions. The lead is WordPress Core CVE-2026-87902, an unauthenticated path traversal in page-template resolution that includes a chosen local PHP file. Patchstack, which tracks this closely, rates it 9.2, recorded its first exploitation traffic at 11:49 UTC on 22 September (the day of the patch) and reported on 23 September that the campaign had progressed from fingerprinting to writing attacker-controlled PHP to disk by chaining the inclusion through PEAR's pearcmd.php. Next, three Linux kernel flaws added on 18 September, one of which (CVE-2025-39682, CVSS 9.8) is network-reachable with no privileges required, unlike the other two. Then Acronis Backup's cPanel, Plesk and DirectAdmin plugins (CVE-2026-87886), a local privilege escalation on exactly the control panels this audience self-hosts; Adobe Commerce and Magento (CVE-2026-71362) for the second time in a month; and MikroTik RouterOS (CVE-2026-67279), fixed in the same builds as the flaw the previous round-up covered. Nine more exploited products follow, seven of them at CVSS 9.3 or higher and eight unauthenticated. If you do nothing else: update WordPress today, reboot into a patched kernel, and work the appliance table by what you actually expose.

Framing note: this is a supplement, not a new catch-up. It covers the same window as the September 25 bulletin and does not repeat that edition's nine dependency and developer-tooling items, which remain worth doing. Sources are the CISA KEV catalog (fetched 28 September, catalog version 2026.09.27, 1728 entries), the CVE Program records for each entry, the wordpress.org 7.1.2 release post and core version-check API, and Patchstack's exploitation analysis for the lead item. Every item here is on KEV, which is CISA asserting exploitation in the wild; that is a stronger basis than anything the parent edition could establish, and it is why this one carries CRITICAL where that one carried HIGH. For the lead item only, exploitation is additionally documented by a named research team with timestamps and payloads. Items are ordered by breadth of exposure for developers, ops, AI/ML infrastructure operators, and self-hosters, not by CVSS. One KEV addition is deliberately excluded: CVE-2026-58704, a Google Pixel cellular-modem privilege escalation, which fails this project's audience test. This supplement closes the KEV half of the parent's gap, not all of it: it does not cover non-KEV vendor advisories or Patch Tuesday, and none of Palo Alto, Fortinet or SolarWinds, which the parent flagged as unverified, appears in KEV for this window. All "as of" statements are anchored to September 28, 2026.

Priorities, by what you run

Every item in this table is on CISA KEV, so "Higher" does not distinguish exploited from unexploited. It distinguishes how much of this audience is likely to run the thing and how exposed it usually is.

Prioritization is this bulletin's own. KEV listing establishes that each item is exploited; it does not establish that each matters equally to this audience, which is what the ordering reflects.

1. WordPress Core: unauthenticated file inclusion, now writing PHP to disk (CVE-2026-87902)

WordPress shipped 7.1.2 on 22 September 2026 as a security release for a single critical flaw, crediting Robert Ressl. The release post describes it plainly: an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories, and if the preconditions for both the server environment and the active theme are met, that becomes remote code execution. The CVE record names the sink, get_page_template(). CISA added it to KEV on 25 September.

What turns "conditional RCE" into a live incident is documented by Patchstack, which rates it 9.2 and has published its firewall telemetry. Their first observed activity was 22 September at 11:49 UTC, hours after the release, and on 23 September they reported the campaign had moved through three stages. Stage one includes an ordinary core file such as wp-links-opml.php so the response reveals whether the host is vulnerable. Stage two points the inclusion at PEAR's pearcmd.php and appends +config-show; when PHP runs with register_argc_argv enabled the query string reaches the included script as $argv, so the response confirms PEAR is present and the trick works. Stage three swaps in +config-create, which writes a file wherever it is told with content the attacker controls. That is arbitrary file write with attacker-controlled PHP, which is code execution. Patchstack also report a named Nuclei template in circulation and mostly spoofed browser user agents, so the preconditions are now concrete and checkable rather than vague: register_argc_argv on, and a pearcmd.php the include path can reach.

Am I affected?

# === DO THIS BEFORE UPDATING. The update overwrites core files, so a checksum
# === comparison afterwards is clean by construction and tells you nothing.

# 1. Search access logs for the observed signatures. Log locations differ by
# platform, so cast wide and let "no such file" be visible rather than silent.
for f in /var/log/nginx/access.log* /var/log/apache2/access.log* \
         /var/log/httpd/access_log* /usr/local/apache/domlogs/* \
         /etc/apache2/logs/domlogs/* /home/*/logs/*; do
  [ -f "$f" ] || continue
  echo "== $f"
  case "$f" in
    *.gz) zgrep -iE 'pagename=[^ &]*(%2f|/)|pearcmd|config-(show|create)|CVE-2026-87902-POC-OK|LUCIFER-RCE-OK' "$f" ;;
    *)     grep -iE 'pagename=[^ &]*(%2f|/)|pearcmd|config-(show|create)|CVE-2026-87902-POC-OK|LUCIFER-RCE-OK' "$f" ;;
  esac
done

# 2. Core integrity, BEFORE the update
wp core verify-checksums --allow-root

# 3. Versions of every install under a docroot. wp-includes/version.php is
# authoritative; readme.html and the admin footer both lag a partial update.
find /var/www /home /usr/local/apache -name version.php -path '*wp-includes*' 2>/dev/null \
  | while read -r f; do printf '%s  ' "$f"; grep -oP "\\\$wp_version\s*=\s*'\K[^']+" "$f"; done

# 4. Are the code-execution preconditions present on this host?
php -i 2>/dev/null | grep -i register_argc_argv
ls -la /usr/local/lib/php/pearcmd.php /usr/share/php/pearcmd.php /usr/share/pear/pearcmd.php 2>/dev/null

# 5. If stage three ran, it wrote PHP somewhere. Check the obvious drop points:
find /tmp /var/tmp /dev/shm -name '*.php' -newermt '2026-09-22' 2>/dev/null
grep -rl 'CVE-2026-87902-POC-OK\|LUCIFER-RCE-OK' /tmp /var/tmp /var/www 2>/dev/null

The log search matches the request shapes Patchstack observed, not a guess: the parameter is pagename and the traversal is percent-encoded, which is why a search written around page_template= and ../ returns nothing on a host that is being attacked. It will also match some benign traffic, which is the correct trade. Known blind spots: a double-encoded traversal (%252e) and a payload delivered in a POST body rather than the query string will both slip past it, and if your logs have rotated past 22 September their absence proves nothing. The precondition check in step 4 tells you how bad a hit would have been: register_argc_argv off, or no reachable pearcmd.php, means stage three could not complete on your host, though stages one and two still disclose files.

Response

1. Search the logs and verify core checksums first, then update. The order matters and it is the reverse of the instinct: updating replaces the core files, so a checksum run afterwards compares the new files against the new manifest and comes back clean whether or not you were compromised. Capture the log evidence and the pre-update checksum output, then take 7.1.2 or your branch's current point release.
2. Update every install, including the ones you forgot. The failure mode on a shared host is six sites under one account where only the one you remembered gets updated. Step 3 above enumerates them. Anything below 4.7 has no fix at all and needs migrating or taking offline, which is a decision to make now rather than at the next advisory.
3. If you find a stage-two or stage-three request, treat the host as compromised, not as needing a patch. Stage three is arbitrary PHP written as the web server user. Isolate the site before cleaning it, preserve the log lines and any file the markers matched, then rotate the database credentials and every key in wp-config.php from a clean host. Rebuild from known-good source rather than deleting the dropped file: the same primitive that wrote to /tmp can write somewhere you will not think to look.
4. Turn off register_argc_argv if nothing needs it. It is the precondition that converts file disclosure into code execution here, and it is rarely required for web workloads. Disabling it does not fix the inclusion, so it is a hardening step to keep after patching rather than an alternative to patching.

2. Three Linux kernel flaws added to KEV on one day, and one of them is network-reachable

CISA added CVE-2025-39964, CVE-2026-53266 and CVE-2025-39682 to KEV on 18 September 2026. None is new: all three were fixed upstream and published as CVE records well before the listing, the oldest in September 2025. What changed is that CISA asserted exploitation, which turns three ordinary stable-tree fixes into something with a deadline.

They are not the same kind of bug, and the difference decides your order of work. Two are local privilege escalations: the AF_ALG crypto socket race at CVSS 7.8 and the bridge netfilter SNAT out-of-bounds write at 8.8, both AV:L with privileges required. The third, CVE-2025-39682 in the kernel TLS receive path, is rated CVSS 9.8 with AV:N and no privileges required: a remote peer supplies the zero-length record. If you terminate kernel TLS anywhere, that is the one to move on first. Two of the three carry CISA's end-of-life notice, advising users to discontinue use or move to a supported version, which is the catalog's way of flagging that some affected series will never receive a fix.

Am I affected?

# What is RUNNING, not what is installed. A patched kernel you have not booted
# into is not a fix, and this is the most common false clear on this item.
echo "running:   $(uname -r)"
echo "installed: $(ls -1 /boot/vmlinuz-* 2>/dev/null | sed 's|.*/vmlinuz-||' | tr '\n' ' ')"

# Is a reboot pending because a newer kernel is installed but not running?
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required
command -v needs-restarting >/dev/null && needs-restarting -r

# Distribution kernels backport, so check by CVE id rather than by version:
apt-get changelog linux-image-$(uname -r) 2>/dev/null | grep -cE 'CVE-2025-39964|CVE-2026-53266|CVE-2025-39682'
rpm -q --changelog kernel 2>/dev/null | grep -cE 'CVE-2025-39964|CVE-2026-53266|CVE-2025-39682'
# a non-zero count means your vendor's changelog references these CVEs

# CVE-2025-39682 is the network-reachable one. Do you terminate kernel TLS?
grep -qi '^tls' /proc/modules && echo "ktls module loaded"
ls /sys/module/tls 2>/dev/null && echo "ktls present"

# AF_ALG registers as uppercase ALG in /proc/net/protocols, and the module
# auto-loads on first use, so an empty result is not a clear.
grep -ci '^ALG ' /proc/net/protocols
ls /lib/modules/$(uname -r)/kernel/crypto/af_alg.ko* 2>/dev/null && echo "af_alg module available"

# Bridge netfilter (CVE-2026-53266), loaded on most container hosts:
lsmod 2>/dev/null | grep -E '^(ebtables|br_netfilter|bridge)\b'

The running-versus-installed comparison is the check that matters most, because unattended upgrades will install a fixed kernel and leave the vulnerable one running until something reboots the box. The module checks narrow scope rather than clear you: bridge netfilter is loaded on most container hosts whether or not anyone configured it, and af_alg auto-loads the first time any unprivileged process opens an AF_ALG socket, so "not loaded" means "not yet" rather than "not reachable".

Response

1. Prioritise CVE-2025-39682 where kernel TLS is in use. It is the only one of the three a remote, unauthenticated attacker may reach, and at 9.8 it is the highest-scored. Hosts terminating kTLS, which in practice means some load balancers, proxies and storage front-ends, go first.
2. Take your distribution's current kernel and reboot into it. For most readers this is the whole fix: one command and a restart. Do the restart. An installed-but-unbooted kernel is the default outcome of patching and the default reason a host is still vulnerable a month later.
3. Treat container hosts as the priority for the other two. Both are local privilege escalations, which makes them most valuable to an attacker who already has code running, and a container host is a machine whose job is running other people's code. If you cannot reboot one promptly, that is an argument for moving its workloads to a host you have patched.
4. Find out whether your series is still supported. Two entries carry CISA's end-of-life notice. If your series is absent from the fixed list above and your vendor has no backport, no patch is coming and the answer is a migration, not an update.

3. Acronis Backup plugins for cPanel and WHM, Plesk and DirectAdmin: local privilege escalation (CVE-2026-87886)

CISA added this to KEV on 16 September; Acronis published the CVE record the following day, 17 September, so the listing preceded the record. It is a local privilege escalation caused by insecure file permissions in the Acronis Backup plugin for cPanel and WHM on Linux before build 1.9.3.1021, the extension for Plesk before 1.8.11.638, and the plugin for DirectAdmin before 1.2.3.238. Acronis rates it CVSS 7.8, the lowest CVSS 3.x score in this supplement.

It ranks third anyway because of where it runs. A control panel host has many local accounts belonging to people you do not fully trust, usually one per customer or per site, and a local privilege escalation there is the exact shape of bug that turns one compromised site into the whole server. The attack needs a local account, which on a shared host is the normal state of affairs rather than a barrier.

Am I affected?

# Version, per panel. Paths vary by how the integration was installed.
cat /usr/local/cpanel/3rdparty/acronis*/VERSION 2>/dev/null
ls -la /usr/local/psa/admin/plib/modules/ 2>/dev/null | grep -i acronis
plesk bin extension --list 2>/dev/null | grep -i acronis
ls -la /usr/local/directadmin/plugins/ 2>/dev/null | grep -i acronis
rpm -qa 2>/dev/null | grep -i acronis ; dpkg -l 2>/dev/null | grep -i acronis

# The defect is file permissions, so look for it directly rather than trusting
# a version string. No -maxdepth: the Plesk tree sits seven levels down at
# /usr/local/psa/admin/plib/modules/acronis-backup and a shallow search misses it.
find / -xdev -type d -iname '*acronis*' 2>/dev/null | while read -r d; do
  echo "== $d"
  # group- or world-WRITABLE: anomalous on any file, this is the defect
  find "$d" -type f -perm /022 -printf '  writable %M %u:%g %p\n' 2>/dev/null | head -30
  # world-READABLE secrets: 644 is normal, so only flag files that look like
  # they hold credentials, otherwise this floods with ordinary files
  find "$d" -type f -perm /004 \
    \( -iname '*cred*' -o -iname '*secret*' -o -iname '*token*' -o -iname '*.key' \
       -o -iname '*.pem' -o -iname '*conf*' -o -iname '*.ini' -o -iname '*.json' \) \
    -printf '  readable %M %u:%g %p\n' 2>/dev/null | head -30
done

# Fixed builds: cPanel/WHM 1.9.3.1021, Plesk 1.8.11.638, DirectAdmin 1.2.3.238

The permission sweep is the more useful of the two checks because it looks for the actual defect rather than trusting a version string, and it is deliberately unbounded in depth: an earlier draft of this bulletin capped it at six levels and would have silently cleared every Plesk host, whose plugin tree is deeper than that. -perm /022 catches group- or world-writable files, which is the defect Acronis describes and is anomalous on any file. The second pass looks for world-readable files only where the name suggests credentials: mode 644 is world-readable and perfectly normal, so an unfiltered readability sweep returns every file in the tree and tells you nothing.

Response

1. Run the permission sweep and keep its output before you update. Updating corrects the permissions, which erases the evidence of what was exposed and to whom. Capture it first, then update to 1.9.3.1021 (cPanel and WHM), 1.8.11.638 (Plesk) or 1.2.3.238 (DirectAdmin). These are plugin builds, not panel versions: a current cPanel does not imply a current plugin.
2. Assume local users could have read or written whatever the permissions allowed. Backup tooling holds credentials for the storage it writes to, and on a control panel host often database access as well. If the sweep found anything, rotate the backup destination credentials and review the archives for access you cannot account for.
3. If you do not use the Acronis integration, remove it. A backup plugin installed by a hosting template and never configured still ships the files and the permissions. Uninstalling is a smaller job than tracking its next advisory.

4. Adobe Commerce and Magento: incorrect authorization, exploited, and a self-contradictory version table (CVE-2026-71362)

Adobe published this on 11 August 2026 and CISA added it to KEV on 24 September. It is an incorrect authorization flaw, CWE-863, that Adobe rates CVSS 9.1 with no user interaction required; successful exploitation gives elevated access to sensitive resources. The September 12 round-up covered a different exploited Magento flaw (CVE-2026-75650, the Sansec "StyleSmuggler" zero-day, KEV 8 September), so this is the second exploited Magento issue in a month and the second time a store that patched once is not done.

The version data needs care, because the CVE record contradicts itself for Adobe Commerce. Its affected list runs up to and including 2.4.9-2026-jul and the 2026-aug releases of 2.4.8 down to 2.4.4, while its unaffected list names the 2026-aug releases of 2.4.9 down to 2.4.4. The 2026-aug releases of 2.4.8 through 2.4.4 appear in both. Magento Open Source and Commerce B2B are internally consistent: for those, the 2026-jul release of each line is affected and the 2026-aug release is the fix. This bulletin could not reach Adobe's own bulletin APSB26-92 to settle the Commerce case (it returns 403 to automated fetches), so the safe reading is that the 2026-aug release is the minimum for every line, that 2.4.9 at 2026-aug is the only Commerce build the record calls unaffected without also calling it affected, and that Commerce operators on 2.4.4 through 2.4.8 should confirm against APSB26-92 rather than trusting either list here.

Am I affected?

# The numeric version alone does not tell you: 2.4.8-2026-jul and
# 2.4.8-2026-aug both report as 2.4.8. You need the date suffix.
php bin/magento --version

# composer.lock carries the resolved package version and its release time,
# which is what actually distinguishes the July build from the August one:
grep -A6 '"name": "magento/product-community-edition"' composer.lock 2>/dev/null | grep -E '"version"|"time"'
grep -A6 '"name": "magento/product-enterprise-edition"' composer.lock 2>/dev/null | grep -E '"version"|"time"'
grep -A6 '"name": "magento/extension-b2b"' composer.lock 2>/dev/null | grep -E '"version"|"time"'

# Full metadata if the lockfile is absent:
composer show -a magento/product-community-edition 2>/dev/null | head -20

# If no date suffix appears anywhere, you cannot resolve this locally:
# compare your install date against Adobe's APSB26-92 release table.

The trap is that 2.4.8 is the same string for the vulnerable July build and the fixed August one, and bin/magento --version prints only that. The composer.lock entries carry a time field alongside the version, which dates the build even when the version string does not. If your deployment pins by numeric version only, that pin will not move you onto the fix.

Response

1. Move to the 2026-aug release of your line. For Magento Open Source and Commerce B2B the record is unambiguous that this is the fix. For Adobe Commerce 2.4.4 through 2.4.8, check APSB26-92 first: the CVE record lists those August builds as both affected and fixed, and this bulletin cannot resolve it.
2. Audit administrative accounts and integration tokens after patching. The flaw grants elevated access with no user interaction, so the post-exploitation artifact is an identity rather than a file. Review admin users, integration tokens and API keys created or modified since August, and revoke what you cannot account for.
3. Treat the September 12 Magento item as still open. If you have not applied Adobe's September hotfix for CVE-2026-75650 (covered in the August 28 to September 12 round-up), do both in one maintenance window.

5. MikroTik RouterOS: SSH pre-authentication state bypass, fixed in the builds you may already have (CVE-2026-67279)

CERT-PL published this on 5 September and CISA added it to KEV on 25 September. RouterOS's SSH implementation enters the connection protocol after a client-requested rekey even though authentication was never attempted, letting an unauthenticated client open a session channel and send an exec request. The record describes the result as unauthenticated creation, overwrite and reconstruction of files in the RouterOS managed file namespace, including support files holding configuration and diagnostic data. CERT-PL rates it CVSS 6.9 under CVSS 4.0, and KEV notes it can be chained to reach unauthenticated exploitation of CVE-2026-86060.

The good news for anyone who acted on the September 12 round-up: CVE-2026-67279 and CVE-2026-86060 have identical affected ranges and are fixed by the same builds, so if you took 7.24.2, 7.23.4 or 6.49.21 then you are covered for both. What this entry does not do is settle the CVE-pairing disagreement that round-up noted between CERT Polska and CISA KEV; it adds a third identifier to it and leaves the discrepancy where it was.

Am I affected?

# From a RouterOS terminal
/system resource print
/system package update print

# Affected: 7.24 up to but NOT including 7.24.2; 7.0.0 up to 7.23.4;
#           6.0.0 up to 6.49.21
# Fixed:    7.24.2 (Stable), 7.23.4 (Long-term), 6.49.21 (Long-term)
#           per the CVE record's own fixed-version statement.
# If you are already on one of the three fixed builds, you are done.

# Is SSH reachable at all, and from where? This decides urgency.
/ip service print detail where name=ssh
/ip firewall filter print where dst-port=22

# Capture before you upgrade: RouterOS keeps its log in memory by default,
# so a reboot discards it.
/log print file=preupgrade-log
/export file=preupgrade-config

# From outside, against equipment you operate only:
#   nmap -Pn -p22 --open YOUR.ROUTER.IP

The version ranges are the CVE record's, which uses "less than" bounds, so 7.24.2, 7.23.4 and 6.49.21 are the fixed builds and not affected ones. The exposure question matters more than usual: this is a pre-authentication SSH flaw, so a RouterOS box with SSH on a WAN interface is the urgent case and one reachable only from a management VLAN is not.

Response

1. Restrict SSH now. This is the mitigation you can apply in a minute and it defeats the chain regardless of build: limit the SSH service to a management address list, or disable it and use Winbox over a VPN. A pre-authentication flaw is only reachable by whoever can open the port.
2. If SSH was reachable from an untrusted network on an affected build, capture before you upgrade. RouterOS logs to memory by default and an upgrade reboots the device, so upgrading destroys the record of what happened. Export the configuration and write the log to a file first, then compare against a known-good config and check the September 12 round-up's indicators.
3. Then upgrade to 7.24.2, 7.23.4 or 6.49.21. If step 2 found anything, rebuild from known-good rather than upgrading in place, and rotate anything the router held, including VPN pre-shared keys and any credentials in the exported configuration.

6. Roll-up: nine more exploited products, seven at CVSS 9.3 or higher

These are the remaining KEV additions from the window. Each is confirmed exploited by CISA; none gets a full section because the affected populations are narrower than the five items above, not because they are less serious. Eight of the nine are unauthenticated and seven are rated 9.3 or higher. Work the table against what you actually expose, then go to the vendor advisory for the fixed build on your platform, which this bulletin does not reproduce.

Am I affected?

# This is an inventory question before it is a version question: what of this
# list do you run, and what can reach it?

# Local listeners that are NOT loopback-only. Wildcard binds print as 0.0.0.0,
# * or [::]; do not discard stderr, or a missing tool looks like a clean result.
if command -v ss >/dev/null; then ss -lntpH; else netstat -lntp; fi \
  | grep -vE '127\.0\.0\.1:|\[::1\]:'

# The appliances themselves do not give you a shell, so the real question is
# what answers from outside. Management ports differ per product and this
# bulletin does not guess them: take the port from your own vhost, load
# balancer or firewall rules, then, against equipment you operate only:
#   nmap -Pn -p- --open YOUR.MGMT.HOST
# A full-range scan is slower but does not depend on a guessed port list.

# WSO2, if deployed from a package or tarball:
find / -xdev -maxdepth 6 -type d \( -iname 'wso2*' -o -iname '*api-manager*' \) 2>/dev/null | head

# SharePoint on-prem build, from the SharePoint Management Shell:
#   (Get-SPFarm).BuildVersion

No single command covers nine vendors, so the block answers the question that sets your priority: which of these is reachable from somewhere you do not control. An unauthenticated RCE on a management interface exposed only to a jump host is a scheduled patch; the same flaw answering from the internet is tonight's work. The port list is deliberately absent because this bulletin has not established one for these products, and a wrong list would clear you falsely: the Zyxel flaw, for instance, is in a CGI reached over plain HTTP.

Response

1. Sort by exposure, not by score. A 10.0 is worth nothing to an attacker who cannot reach the interface, and the 8.8 Zyxel flaw is LAN-reachable and unauthenticated, which on a flat office network is not much of a barrier. Patch what answers from outside first.
2. For any exposed device on a vulnerable build, capture before you patch. Appliance updates reboot, and VPN gateways and load balancers hold their evidence in memory. Pull the configuration, the logs and whatever the vendor's advisory names as indicators, then patch. Six of these end in unauthenticated code execution on a device that terminates VPNs, holds directory credentials or brokers API traffic.
3. Go to the vendor advisory for the fixed build. Cisco, F5, Check Point, Arista, WSO2, Zyxel and Microsoft each publish a per-line fixed version. CISA's federal due dates have passed or fall today, which is a useful signal about urgency even if the deadline is not yours.
4. Patch both Check Point entries, not one. CVE-2026-93616 affects management servers and SmartEvent; CVE-2026-85102 affects gateways and Spark firewalls running VPN. Separate products on separate release trains: a team that patches its gateways is not covered for its management server.

What the gap actually cost

Worth being concrete, because the parent bulletin disclosed a coverage gap without being able to measure it. The answer is 17 KEV additions, of which 16 were in scope for this audience: an unauthenticated file inclusion in the most widely self-hosted CMS there is, already being used to write PHP to disk; three kernel flaws including one rated 9.8 with a network vector; a privilege escalation on the control panels a lot of readers run; and nine exploited products. A reader who took the September 25 bulletin as their week's security reading would have updated their Python lockfiles and missed all of it.

That is not an argument against the parent edition, which said plainly what it could not see and told readers to check their own vendor feeds. It is an argument about tooling: the bulletin was narrowed by a network policy rather than by editorial judgment, and nothing in the output of a run can tell you what that run never fetched. The process change that followed lives in the repository rather than on this page, but the short version is that the research step now probes its sources before writing and reports what is blocked, instead of quietly producing a smaller bulletin. This supplement is also the first to go through the two-reviewer pass that change introduced, which caught two checks in an earlier draft that returned empty output on genuinely affected hosts.