Cisco Talos published a new report on 2026-10-28 tying this flaw to historical UAT-11473 intrusions, BleepingComputer the same day reported Volt Typhoon using it as a zero-day, and Cisco revised its advisory on 2026-10-28 — a controller or manager still on an affected release remains open to unauthenticated takeover of the whole fabric.
A flaw in the peering authentication mechanism of Cisco Catalyst SD-WAN Controller (vSmart), Manager (vManage) and Validator (vBond) lets an unauthenticated remote attacker send crafted requests and log in as an internal high-privileged non-root account. From there the attacker reaches NETCONF and can rewrite the configuration of the entire SD-WAN fabric; no workaround exists and public exploit code is available.
Affected: Cisco Catalyst SD-WAN Manager releases earlier than 20.9, and 20.9 through 20.18 releases before the first fixed release for their train in advisory cisco-sa-sdwan-rpa-EHchtZk; Cisco Catalyst SD-WAN Controller (vSmart) and Validator (vBond) releases covered by advisory cisco-sa-sdwan-rpa-EHchtZk
How to Test
Check the running release on each SD-WAN Manager, Controller and Validator against the affected list in Cisco advisory cisco-sa-sdwan-rpa-EHchtZk (Cisco bug CSCws52722). To look for compromise, review authentication logs on Controllers and Managers for logins by the internal high-privileged non-root peering account from unexpected peers, audit NETCONF sessions and configuration changes to the fabric that no administrator made, and run the hunts in CISA's Hunt & Hardening Guidance for Cisco SD-WAN Devices referenced by Emergency Directive 26-03.
How to Patch
Upgrade every Catalyst SD-WAN Manager, Controller and Validator to the fixed software release Cisco lists for your release train in advisory cisco-sa-sdwan-rpa-EHchtZk; Cisco states there are no workarounds. Where an upgrade cannot happen immediately, follow CISA Emergency Directive 26-03 mitigation steps and restrict network reachability of the controller peering interfaces to known peers.
Evidence: CISA KEV ↗, VulnCheck KEV ↗, CISA SSVC: active ↗, Cisco Talos UAT-11473 KeyDrift report, 2026-10-28, cited by VulnCheck KEV as exploitation source ↗, BleepingComputer 2026-10-28: Volt Typhoon zero-day exploits include CVE-2026-20127 ↗, Cisco Talos: active exploitation by UAT-8616 ↗, Cisco Talos: ongoing exploitation of Catalyst SD-WAN vulnerabilities ↗, Rapid7 Labs: CVE-2026-20127 exploited in the wild ↗, Public exploit ↗ On 2026-10-28 the Canadian Centre for Cyber Security updated its advisory to say the flaw is exploited in the wild, and threat intelligence firm Defused reported attackers scanning for unpatched EBS systems; an internet-facing EBS instance without the October 2026 CPU can be taken over without credentials.
A flaw in the Core component of Oracle Application Object Library in E-Business Suite 12.2.3–12.2.15 lets an unauthenticated attacker with HTTP access take over the component. Public reporting describes it as an unauthenticated SQL injection that can be turned into remote code execution.
Affected: Oracle E-Business Suite – Oracle Application Object Library (Core) 12.2.3 through 12.2.15
How to Test
Check the EBS release level (12.2.3–12.2.15 is affected) and whether the October 2026 Critical Patch Update has been applied to Application Object Library. Review web-tier and application access logs for unauthenticated HTTP requests to EBS endpoints from unfamiliar sources starting around 2026-10-20, and look for unexpected database activity, new accounts or new files on the application tier.
How to Patch
Apply the Oracle Critical Patch Update for October 2026 (released 2026-10-20), which fixes CVE-2026-101767 in Oracle Application Object Library 12.2.3–12.2.15. Until the patch is in place, limit internet access to the EBS web tier so that only trusted networks can reach it.
VulnCheck's canary sensors recorded exploitation attempts on 2026-10-28 and VulnCheck added the flaw to its KEV catalog the same day, so an unpatched Camunda engine that attackers can reach risks command execution on the host.
AdhocQueryValidator.validate() does not check the expression maps of sub-queries in the orQueries field of TaskQueryDto. That gets around the enableExpressionsInAdhocQueries restriction and lets a malicious JUEL expression (for example dueAfterExpression) call java.lang.Runtime.exec. The result is operating-system command execution as the engine service user. VulnCheck's advisory says the attacker must be an authenticated user, while the CVE record's CVSS 4.0 vector scores it as needing no privileges, so treat any reachable REST API as at risk.
Affected: Camunda 7 7.24.0 through 7.24.13 (fixed in 7.24.14); Camunda 7 7.23.0 through 7.23.16 (fixed in 7.23.17)
How to Test
Check the running Camunda 7 engine version (in the web apps or the distribution's version information). Versions 7.24.0–7.24.13 and 7.23.0–7.23.16 are affected. In REST API access logs, look for task query requests whose bodies contain an orQueries array with expression fields such as dueAfterExpression, especially values that include reflection or Runtime.exec patterns. Also look for unexpected child processes started by the engine service user.
How to Patch
Upgrade Camunda 7 to 7.24.14 or later on the 7.24 branch, or to 7.23.17 or later on the 7.23 branch, using the Camunda enterprise download page. Until then, restrict network access to the Camunda REST API and web apps to trusted users and hosts.
Unverified public report · no CVERemote Code Executionhigh
WordPress 7.1.4 and its same-day backports, which fix this race condition, shipped on 2026-10-28, so blocking wp-content/upgrade/ at the web server now closes the window that the update itself reopens.
WordPress 7.1.4, released on 2026-10-28, fixes 22 vulnerabilities across 17 advisories; Patchstack says almost all of them need an account first, usually a Contributor. The exception, according to Patchstack, is a race condition in the core upgrade process: while any install or update runs, WordPress unpacks the package into wp-content/upgrade/ under a predictable folder name and first deletes the index.php that blocks directory listing, so for a few seconds a full WordPress copy sits at a guessable, browsable path. Patchstack says an attacker who requests its wp-admin/setup-config.php in that window could run the installer against a database they control inside the victim's document root, which Patchstack says could lead to remote code execution with no account and would not be visible to a PHP-level firewall, though Patchstack rates the attack complexity high (AC:H) and does not consider it practical to exploit. The window reopens on every update, including unattended ones, and the flawed code dates back to WordPress 2.8. The release also fixes an unauthenticated leak of unpublished Customizer changesets. Patchstack lists no CVE for these flaws, and no exploitation is reported.
Affected: WordPress 2.8 through 7.1.3 (fixed in 7.1.4 and same-day backports down to 4.7.39)
How to Test
Check the WordPress version under Dashboard → Updates or in wp-includes/version.php. Anything older than 7.1.4, or older than the latest backport on your branch, is affected. Request https://<site>/wp-content/upgrade/ from outside: it should return 403, or at worst an empty index.php page, and never a directory listing. Between updates the folder should hold only index.php. In access logs, look for requests to wp-content/upgrade/*/wp-admin/setup-config.php.
How to Patch
1. Update to WordPress 7.1.4, or to the same-day backport release for your branch, using Dashboard → Updates or WP-CLI (wp core update). 2. Before updating, add a web-server rule that blocks wp-content/upgrade/. For nginx: location ^~ /wp-content/upgrade/ { deny all; }. For Apache: 'Require all denied' in that directory. 3. Turn off directory listing for the site.