The seven completed days from September 19 through September 25, 2026 produced a clear defender queue: four newly cataloged exploited edge and identity vulnerabilities, a large Chrome release, and a coordinated Apache Tomcat security disclosure. The highest-risk systems are not ordinary endpoints. They are VPN gateways, SD-WAN orchestrators, OAuth authorization servers, and security-management platforms—systems whose compromise can expose credentials, policies, traffic, and downstream devices. The operating order is therefore fix the confirmed exploitation paths now, verify whether attackers arrived first, then plan durable control-plane isolation and logging.
Fix now
1. Close the four September 22 KEV items
On September 22, CISA added four vulnerabilities to the Known Exploited Vulnerabilities catalog: Check Point CVE-2026-85102 and CVE-2026-93616, Arista VeloCloud Orchestrator CVE-2026-93952, and F5 BIG-IP APM CVE-2026-94127. Evidence of exploitation, external reachability, and control-plane impact make these the first Monday actions. Use AboutInfoSec’s complete KEV prioritization workflow for ownership, patch evidence, exception handling, and investigation; this digest focuses only on the week’s decision points.
2. Patch BIG-IP APM systems acting as OAuth authorization servers
F5 disclosed CVE-2026-94127 on September 22 and updated the advisory on September 23. A BIG-IP APM virtual server is exposed when it has both an access policy and an OAuth profile and operates as an OAuth Authorization Server. Malicious traffic can lead to unauthenticated remote code execution. Deployments used only as OAuth clients or resource servers, without authorization-server profiles, are not affected by this issue.
Inventory the configuration, not merely the installed module. Apply the engineering hotfix or fixed release specified for the exact BIG-IP branch. If no affected profile is required, remove or disable it while the maintenance proceeds. Management-interface restrictions alone do not close a data-plane vulnerability delivered to the virtual server.
3. Treat VeloCloud Orchestrator as a possible incident
Arista rates CVE-2026-93952 at CVSS 10.0 and confirms active exploitation. The affected product is on-premises VeloCloud Orchestrator when certificate-based Edge-to-Orchestrator authentication is configured and the attacker can reach the VCO web interface. No tenant or operator credential is required. Hosted VCO deployments were affected but have already been patched by the provider.
At publication, affected trains included 5.2.3.15 and earlier, 6.1.3.7 and earlier, 6.4.2.7 and earlier, and 7.0.0.2 and earlier. Arista listed 5.2.3.16 and 6.4.2.8 as fixed, while fixes for other supported trains were still being added. Confirm the current table before changing production. Restrict web-interface access to trusted administrative networks and contact TAC for trains without a published remediation path.
4. Apply Check Point fixes and validate LivePatch state
CVE-2026-85102 is an improper certificate-validation issue in Remote Access and Site-to-Site VPN that can permit unauthenticated remote code execution on a Security Gateway. Check Point says the vulnerability has been actively exploited on Spark Firewalls since September 12. Systems that use or allow certificate-based VPN authentication need the vendor’s current LivePatch, Jumbo Hotfix, or fixed firmware; pre-shared-key-only Site-to-Site communities are not vulnerable to this specific flaw.
CVE-2026-93616 affects Security Management, Multi-Domain Management, Log, Multi-Domain Log, and SmartEvent servers. Check Point reports attacks against a handful of customers: unauthenticated directory traversal and file upload can lead to arbitrary script execution. Smart-1 Cloud is already protected, while affected self-managed systems require the prescribed fix. Do not assume that LivePatch Take 28 or 29 addresses this particular issue; Check Point explicitly says it does not.
5. Move Chrome 154 and Tomcat into the active rollout
Google promoted Chrome 154 on September 22: 154.0.8037.57 on Linux and .57/.58 on Windows and macOS, with 108 security fixes. The list includes multiple critical memory-safety defects in ANGLE, GPU, ServiceWorker, Fullscreen, WebGL, and other components. Push the stable release and record the running browser version after restart. The complete operational sequence is in AboutInfoSec’s browser fleet rollout guide.
Apache made a broad Tomcat disclosure public on September 23. The set includes CVE-2026-86350, an HTTP/2 request-header mix-up introduced by an earlier fix; CVE-2026-76183, a WebSocket endpoint security-constraint bypass; and several denial-of-service and certificate-validation issues. Upgrade supported branches to 9.0.122, 10.1.60, or 11.0.26. Teams still on Tomcat 10.0.x must migrate because that branch is end-of-life and does not receive these fixes.
Verify
For BIG-IP, identify every virtual server combining APM and an OAuth authorization-server profile. Review APM, LTM, audit, and system telemetry around unusual OAuth traffic and service instability. F5 notes that a TMM core file should be investigated but is not, by itself, proof of exploitation. Preserve logs before hotfix installation and investigate unexpected outbound connections, configuration changes, new files, or processes.
Arista published concrete VCO hunting leads: unexpected URL-like paths or encoded characters in web access logs, unusual outbound HTTP or HTTPS, unapproved configuration changes, privileged maintenance actions, new archives or database exports, the files /usr/local/sbin/.vcnode.js and /etc/systemd/system/vc-sysmon.service, the x-vc-opt nginx header, and two listed source addresses. Preserve web, backend, database, system, and file-system timestamps before rebuilding. Because VCO controls Edge devices, validate managed-device state and rotate affected credentials, certificates, and keys.
For Check Point, use the vendor’s log queries and indicators rather than relying on patch inventory alone. Review certificate-based Mobile Access logins, unexpected internal scanning, very long management usernames, core dumps, uploaded scripts, and changes to Trusted Clients. Validate the installed LivePatch with the vendor commands after rollout. Where stolen sessions or administrative tokens may survive the patch, follow AboutInfoSec’s full session invalidation and evidence guide.
For Tomcat, verify the executing JVM has restarted on the fixed build and check reverse-proxy, HTTP/2, AJP, and WebSocket exposure. Review anomalous request routing, authentication boundaries, cross-user header effects, thread exhaustion, and unexpected certificate-validation behavior. A package update without a restarted application container is not closure.
Plan
The week’s common weakness is excessive trust in security control planes. Add every VPN gateway, SD-WAN orchestrator, OAuth authorization server, management server, and application gateway to an owned inventory with software train, active role, exposure, logging destination, and tested recovery path. Require off-device logs so an attacker controlling the appliance cannot erase the only evidence. AboutInfoSec’s network-edge hardening guide supplies the broader operating checklist.
September 25 was also the closing date for comments on NIST’s draft SP 800-239, AI Data Center Security Analysis. It is not a final standard, but it is useful planning input for teams building AI infrastructure: inventory the distinct hardware, orchestration, data, model, storage, and workload layers; map trust boundaries; and ensure HPC-style controls cover AI-specific workflows and supply chains. Convert that analysis into an owned gap register rather than waiting for the final publication.
Monday handoff
- Fix now: the four September 22 KEVs, Chrome 154, and supported Tomcat branches.
- Verify: VCO and BIG-IP evidence, Check Point authentication and file activity, executing browser versions, and restarted Tomcat instances.
- Plan: isolate control planes, centralize immutable logging, document emergency upgrade paths, and apply the NIST AI data-center threat model to current projects.
The closure test for every item is evidence from the running system: the vulnerable configuration is gone or fixed, the post-change version is active, relevant telemetry has been reviewed, and any suspected control-plane compromise has been handled as an incident rather than a patch ticket.

