Zero-Day Watch: Recent Active Exploits and What to Patch First

Patch Tuesday is a schedule. Attackers do not have to follow it. Recent exploitation reports put access gateways, network-management systems, browsers, and public websites on the same urgent review list. The useful question is not which headline sounds worst. It is which affected system your organization actually runs, who can reach it, and whether you can prove the fix is active.

This briefing is a September 27, 2026 snapshot, not a live threat feed or an exhaustive list. It separates exploitation evidence from speculation and avoids exploit payloads. Check the linked advisories again before making changes: supported fixes, workarounds, and investigation guidance can evolve.

Zero-day does not mean every newly listed vulnerability

For this article, zero-day exploitation means exploitation before a vendor fix was available. A known-exploited vulnerability may instead be an older, already patched flaw that attackers continue to use. A public proof of concept alone does not establish attacks against real victims. Likewise, a catalog-addition date is not the date the first attack occurred.

The CISA Known Exploited Vulnerabilities catalog is our exploitation-evidence baseline for the entries below. Where the checked sources do not establish pre-patch timing, we call the flaw known exploited rather than claiming a confirmed zero-day. 'Unknown' ransomware involvement is not evidence that ransomware cannot use it.

F5 BIG-IP APM: CVE-2026-94127

CISA added this flaw on September 22. Its entry describes unauthenticated remote code execution when an access policy and OAuth profile are configured on a virtual server. Confirm those conditions; do not assume every BIG-IP installation has identical exposure.

CISA's notes identify a vendor iRule as temporary mitigation for forensic triage, followed by the final patch. Obtain the current instructions from F5 advisory K000162605. We verified the catalog entry; the vendor page did not render in our source check, so we are not reproducing an unverified build matrix or iRule.

Check Point: separate management and VPN exposure

CISA added CVE-2026-93616 and CVE-2026-85102 on September 22. The first concerns script upload and execution in management, logging, and SmartEvent products. The second concerns certificate validation in Security Gateway and Spark Firewall deployments using site-to-site or remote-access VPN.

Use the separate management advisory and gateway advisory. A gateway update is not proof its management server is fixed. These vendor pages require interactive access; confirm the applicable release and remediation with the vendor rather than using a guessed universal version.

Arista VeloCloud Orchestrator: CVE-2026-93952

Arista's September 22 advisory explicitly confirms active exploitation. It describes access to privileged internal functionality in VeloCloud Orchestrator and potential compromise of its host and managed data. This is not a blanket advisory for every Arista switch or VeloCloud component.

The advisory identifies certificate-based Edge-to-Orchestrator authentication, access to the public certificate portion, and network access to the VCO web interface as relevant conditions. Tenant or operator credentials are not required. Hosted deployments, including Dedicated, were affected and are reported patched by the provider.

For on-premises deployments, the checked advisory lists fixes in 5.2.3.16 and 6.4.2.8 within their respective release trains. Other affected trains need current vendor guidance; do not assume an arbitrary numerically higher version is fixed. Restrict management access while arranging remediation. Arista recommends preserving relevant logs when compromise is suspected and warns there is no single definitive indicator.

Chrome: CVE-2026-87491 remains a reason to verify browser updates

Google's September Chrome release notice confirms an exploit exists in the wild. The release details identify an out-of-bounds write in V8. The listed Chrome 153 fixes began at 153.0.8010.36 on Linux and 153.0.8010.36/.37 on Windows and Mac.

Those are historical fix baselines, not a recommendation to install an older release today. Deploy the latest supported stable build for each platform and verify the running version after relaunch. Include shared workstations, administrator desktops, and browser-automation hosts. Installing an update package is not the same as replacing a process that is still running old code.

WordPress and SharePoint: do not overlook public applications

CISA added WordPress CVE-2026-87902 and SharePoint CVE-2026-65660 on September 25. SharePoint's entry describes code execution by an authorized attacker; do not relabel it as unauthenticated access. Use the Microsoft advisory for affected products and updates.

The WordPress project advisory explains that CVE-2026-87902 can lead to code execution only when relevant theme and server preconditions are met. It lists WordPress 7.1.2 and branch-specific backports as patched. An affected version does not establish that every installation meets every exploitation condition, but uncertainty is not a reason to leave a confirmed affected deployment unpatched.

For site owners, verify updates with the hosting provider and check staging, disaster-recovery copies, and forgotten subdomains. A managed-hosting contract is not itself evidence that your specific instance has received the fix.

A practical response plan: scope, contain, preserve, patch, verify

The following is HackWednesday's recommended workflow, not a claim that we tested your environment or that every entry above has compromised your systems.

1. Establish actual exposure

For each relevant CVE, record the product, running version, enabled features, reachable interfaces, owner, and business dependency. Check reality against inventory: an old gateway, standby node, or contractor-managed appliance can be missing from the dashboard. Prioritize confirmed exploitation together with exposure and impact, rather than sorting only by severity score.

2. Reduce reachable attack surface safely

Apply vendor-supported temporary controls where available. Restrict administrative interfaces to approved networks and validate legitimate access afterward. Coordinate with service owners before changing authentication or traffic policy. A rushed mitigation that disables critical access can become an additional incident.

3. Preserve evidence without leaving an attack running

Bring incident responders into the decision if exploitation is suspected. Capture relevant access, authentication, configuration-change, and system records where operationally safe. Contain active harm promptly; evidence collection must not become an excuse to keep an attacker connected. Avoid uploading sensitive logs or appliance backups to public analysis tools.

4. Patch the deployment, not just the ticket

Use authenticated vendor distribution channels and follow supported upgrade paths. Check clustered nodes, standby systems, and required restarts. Preserve a tested recovery route. A completed change request should include evidence of the version actually serving traffic, not only a successful installer message.

5. Investigate separately from patching

A patch closes a vulnerability; it does not establish that previously stolen credentials, sessions, or persistence are gone. If evidence indicates compromise, scope the incident, review connected systems, and follow vendor and responder guidance for recovery and credential replacement. Rotate sensitive access from a trusted environment rather than an appliance still suspected to be controlled.

Where AI helps, and where authority must stay outside the model

An AI assistant can help compare advisory versions, summarize evidence, and draft remediation tickets. Require source links and have the asset owner verify applicability. Do not give a browsing agent unrestricted production credentials or let an external advisory page authorize its next command. Use a bounded workflow with an independent approval step for consequential changes.

Our Agent Permission Diff helps review changes to MCP configurations and skill instructions. It does not scan appliances or determine whether a CVE affects your network. The AI Incident Tracker also keeps service outages separate from security disclosures; an operational status page is not proof that a system is uncompromised.

What should you do before next Wednesday?

Pick the relevant exposed system with the greatest business impact. Assign an owner, verify the advisory against its configuration, apply the supported response, and collect evidence that the running system is fixed. Record investigation work separately from patch completion. Then repeat for the next asset.

Patch Tuesday. Verify before Hack Wednesday. Follow the Wednesday Brief for practical defensive analysis. Sources checked September 27, 2026; this AI-assisted article has not been marked as human reviewed.