I have enough from the briefs to write the piece; next I’ll lock a story-driven title and keep the F5 token-issuer thread distinct from the appliance articles already published.TITLE: The Token Issuer Never Asked Who Called

The F5 note hit inboxes on September 22 like a change ticket you can’t schedule. BIG-IP Access Policy Manager, configured as an OAuth authorization server, had a critical hole already in the wild. CVE-2026-94127 lets a remote caller execute code with no login. Hotfixes followed the disclosure. For a cybersecurity team that published that listener so apps could get tokens instead of passwords, the issuer just became the incident.

You know the box. It sits in a DMZ diagram with a green check. It terminates TLS. It talks to identity providers. Developers treat the tokens it mints as gospel. Attackers treated authentication on that mint as optional.

The mint sat on the side you published

F5 says the flaw hits systems where APM serves as an OAuth authorization server, issuing access tokens to applications. Narrow scope on the advisory. Wide blast radius if you centralized token issuance so every API could share one broker. That broker is a privileged operating system with a data plane, a policy engine, and a public URL. Unauthenticated remote code execution there is a token-factory problem with a network-appliance body.

Someone on the network team will say the APM gets patched monthly. Someone in IAM will say tokens are short-lived. Both can be true and you’ll still be late. F5 called the hole exploited. The engineering hotfix is the production change.

Anyone who can reach the listener can try the exploit. Your firewall likely allows that traffic because you meant the APM to be reachable. Brute-force noise against a login form is the wrong mental model. This path has no password prompt. Threat detection that counts failed logons will stay quiet. Threat-protection rules written for form spray will stay quiet too.

Once code runs on the APM, the attacker sits next to the process that mints bearer tokens. They can read local config, harvest client secrets, mint or steal tokens, and walk into every app that trusts the issuer. Incident response that opens the application logs first is searching the wrong building. The application never saw the packet.

Two more trust jobs failed the same week

Arista urged immediate patching of an exploited VCO zero-day. Remote attackers could trigger a critical-severity flaw and reach privileged internal functionality on the orchestrator that drives a lot of SD-WAN estates. That controller is the WAN brain. Management paths land on trusted networks that still include partners, jump boxes, and last year’s exception ticket.

WordPress shipped 7.1.2 to close CVE-2026-87902, a critical unauthenticated path traversal. An attacker can make the software load a PHP file of their choosing from outside the site’s active theme folders. On hosts where the server and the active theme meet certain conditions, that walk becomes code execution. The project lists every release from 4.7.0 through 7.1.1. That’s nearly a decade of CMS installs still publishing for governments, universities, and the campaign site that shares a VLAN with your IdP runbooks.

Reachability plus an unauthenticated bug was enough. That’s a bad look for any vendor that sold the product as the front door. It’s a worse look for operators who still patch the CMS and the broker on different calendars. Three products. Three jobs you file as infrastructure. The OAuth broker, the WAN orchestrator, and the CMS that publishes your public face all skipped the first access check. Cyber security programs that inventory applications and leave appliances, plus the WordPress box in marketing, on a slower patch cadence just sat a same-week exam.

Cybersecurity starts with who can reach the issuer

Start today with inventory, not a meeting. Export BIG-IP configs and mark every APM that issues OAuth tokens. If you can’t prove a box is out of that role, treat it as in-scope. Apply the engineering hotfixes. Pull management interfaces off the public internet. If the OAuth listener must face clients, restrict sources to the networks that actually redeem tokens. Repeat the same pass for Arista VCO: patch first, then prove the orchestrator is unreachable from guest Wi-Fi, contractor VPNs, and leftover public NAT. Repeat it for WordPress: 7.1.2 on production, staging, and the microsite nobody listed in the CMDB.

Security hardening after the hotfix is reachability and rebuild muscle. Treat token issuers, orchestrators, and CMS hosts as tier-0 identity systems. Give them the same patch SLA you give domain controllers. Defense in depth on these boxes is a dedicated management network, unique local admin credentials, config backups you can diff, and file-integrity coverage on WordPress trees outside the active theme. A WAF still helps. A patched appliance image still has to exist underneath it.

If you think the OAuth APM was hit, assume tokens from that window are hostile. Rotate client secrets. Revoke refresh tokens. Force re-authentication on relying parties. Snapshot the appliance if you need forensics, then rebuild from a known-good image. Hunt for new local accounts, unexpected listeners, and outbound connections originating from the box. The patient is the issuer. The blast radius is every app that trusted it.

Write the 2 a.m. version of this before you need it. Who can apply a hotfix. Who can revoke tokens. Who owns WordPress that is not in the app inventory. Unauthenticated RCE on a token mint does not wait for the change advisory board.

Sources

• F5 Patches Critical BIG-IP APM Zero-Day Exploited for Unauthenticated RCE on OAuth Servers
• Critical F5 BIG-IP Vulnerability Exploited as Zero-Day
• Arista Urges Immediate Patching of Exploited VCO Zero-Day
• WordPress 7.1.2 fixes critical unauthenticated path traversal vulnerability (CVE-2026-87902)