What landed in CVE-land this week

The week ending 2026-09-26 was heavy on management-plane and edge-appliance flaws, the kind of software that sits one hop from an attacker and one hop from your identity fabric. CISA added seven CVEs to the Known Exploited Vulnerabilities catalogue between 2026-09-21 and 2026-09-24, and Cisco shipped a bundle of critical advisories on 2026-09-26 covering Secure Firewall Management Center, Identity Services Engine, and Secure Email Gateway. Rather than survey all of them, we go deep on two: the F5 BIG-IP APM heap overflow that CISA confirmed is being exploited in the wild, and the Cisco Secure FMC Java deserialization bug published this morning. Both are unauthenticated, both target appliances that hold the keys to your remote access and firewall estate, and both are tractable if you know where to look.

Lead: unauth heap overflow in F5 BIG-IP APM (CVE-2026-94127)

CVE-2026-94127 is a heap-based buffer overflow in the BIG-IP Access Policy Manager (APM) data plane. Per CISA's KEV entry (added 2026-09-22), the vulnerability triggers "when access policy and an OAuth profile are configured on a virtual server," and the outcome is unauthenticated remote code execution. That precondition is the entire game: this is not a blanket BIG-IP bug. It fires only on virtual servers that terminate an APM access policy and have an OAuth profile attached. That combination appears in two common shapes: APM as an OAuth or OIDC client fronting an internal application (federating to a corporate IdP at example.com), and APM as an OAuth resource server validating bearer tokens for an API tier.

Prerequisites are minimal. The affected code path sits in the pre-authentication OAuth handling on the virtual server, so an attacker needs only network reach to the listener. APM virtual servers are, by design, exposed to the internet in the majority of deployments; that is the point of a remote-access gateway. There is no credential requirement, no user interaction, and no phishing step. Heap-based overflows in long-running C daemons have a strong track record of yielding root-equivalent code execution once weaponised, and the KEV listing confirms active exploitation in the wild.

The concrete question for a defender: which virtual servers are actually vulnerable-shaped? Answer it in thirty seconds from the BIG-IP TMOS shell. On each active BIG-IP, enumerate virtual servers that reference both an APM access policy and an OAuth profile:

# On the BIG-IP: list virtuals with an access policy AND an oauth profile
tmsh -q list ltm virtual one-line | \
  awk '/profiles-oauth/ && /access-policy/ {
    for (i=1;i<=NF;i++) if ($i=="ltm" && $(i+1)=="virtual") print $(i+2)
  }'

# For each hit, dump the bound access policy and oauth profile for evidence:
tmsh -q list ltm virtual VS_NAME profiles access-policy
tmsh -q list apm profile oauth

Any virtual server returned by that first command is a candidate exposure. Cross-reference the listener address and port against your external attack surface: if the self IP or virtual address is routable from the internet, treat that appliance as an urgent patch target under CISA BOD 26-04, which as of 2026-06-10 carries the KEV remediation obligation. Interim mitigations, in order of preference: apply the fixed version from the vendor, remove the OAuth profile from any exposed virtual server that does not strictly require it, or restrict the virtual server's source address list to trusted network ranges while you schedule the patch window. Do not rely on a WAF signature; heap overflows in the OAuth parser trigger before the request reaches any application-layer inspection you own.

Runner-up: Cisco Secure FMC Java deserialization (CVE-2026-20242)

Published today alongside a broader Cisco Secure Firewall hardening release, CVE-2026-20242 is an unauthenticated remote code execution in the External Database Access feature of Cisco Secure Firewall Management Center Software. Per Cisco's advisory, the mechanism is "insecure deserialization of a user-supplied Java byte stream from a host that is configured in the external database access list." Sending a crafted, serialized Java byte stream to a specific TCP port on the FMC yields arbitrary command execution as root on the management appliance.

Two things set this apart. First, FMC is the control plane for your firewall estate. Code execution on FMC means policy tampering, log tampering, cert material access, and lateral pivots into every managed FTD device. Second, exposure is gated by a configuration list: "hosts that are configured in the external database access list." That is a defender-controllable input. On each FMC, check first whether External Database Access is enabled at all and, if it is, what the allowlist contains. In the FMC UI, this lives under System > Configuration > External Database Access; via API, query /api/fmc_platform/v1/info/serverversion and the platform settings endpoints. If your FMC does not need external database read access (the feature exists so third-party reporting tools can pull events over JDBC), disable it. If it does, tighten the allowlist to specific reporting hosts and ensure the FMC's management interface is not reachable from user segments.

The same 2026-09-26 Cisco release covers CVE-2026-20079 (an FMC authentication bypass via crafted HTTP requests that also lands root), CVE-2026-20329 (an ASA/FTD/FMC hardening release that Cisco flags as containing two vulnerabilities "known to be actively exploited"), CVE-2026-20340 (further FMC issues), and separately CVE-2026-20176, CVE-2026-20282, and CVE-2026-76423 across Identity Services Engine, plus CVE-2026-76461 in Secure Email Gateway. If you run any of these products, read the September release notes.

The blue-team read

The week's pattern is familiar. Attackers are not burning zero-days on your laptop fleet; they are burning them on the appliances that terminate your VPN, front your applications, and manage your firewalls. Two habits pay for themselves.

First, keep an authoritative inventory of every management-plane appliance that records the specific features enabled on each device, so that when an advisory lands with a feature-scoped precondition (OAuth profile plus access policy; External Database Access enabled) you can answer "are we exposed" in minutes, not days. Second, treat CISA KEV additions as the priority queue they are meant to be: BOD 26-04 exists because the KEV list is, by definition, the subset of CVEs where exploitation is confirmed.

Both of this week's lead flaws are patchable now. Both are detectable with a single query against configuration you already own. Neither should be sitting on an internet-facing listener by Monday.

Verifiable security.