When a software patch is released, a race begins.
On one side, attackers rush to reverse-engineer the patch, understand the vulnerability it fixes, weaponize it, and start attacking systems that are still vulnerable. On the other side, system administrators rush to deploy the patch before the inevitable attacks start hitting.
Roughly 19 hours separated the release of WordPress 7.1.2 fixing CVE-2026-87902, and the first exploitation attempt we observed against one of the WordPress instances we administer. That instance was not a high-value target in any way.
The average time-to-exploit for this CVE is actually much smaller.
Patch Automation and Observability Are Essential
There was a time when patching could be treated as routine maintenance. Something to schedule, test, and roll out when convenient.
If the patching process still depends on someone noticing a security advisory, logging into a server, applying an update manually, checking that nothing broke, and then repeating the same procedure across multiple systems, it is not really a patching process. That is a race against the clock that depends on a human being being awake, available, paying attention, and making no mistakes.
Sadly, vulnerabilities do not wait for business hours. Attackers do not care whether it is 3:00 AM, Christmas morning, or the middle of a holiday.
And the operational window, between patch release and attacks, the time-to-exploit, is getting smaller on average.
Attackers have spent years optimizing the period between disclosure and exploitation. Vulnerability monitoring, patch diffing, reverse engineering, exploit development, scanning, target discovery, and attack delivery can all be automated. There are entire criminal ecosystems built around moving faster than defenders can patch.
AI is now accelerating that pipeline even further.
AI is being used to analyze patches, explain code changes, identify likely vulnerable paths, exploit development, generate variations of payloads, and automate reconnaissance and attacks. Tasks that once required significant time and specialist knowledge can increasingly be compressed into automated workflows.
The following plot depicts the mean time-to-exploit averaged over ~3500 CVE patch-exploit pairs (black line). The plot shows that the time-to-exploit is decreasing and it reached 1.6 day.
Defenders cannot respond to machine-speed attacks with ticket queues and manual SSH sessions by system admins who may or might not be available at every crucial moment.
Patch deployment has to be automated, repeatable, observable, and boring.
Of course automated patching carries operational risk. Updates can break things. Compatibility problems happen. Occasionally, a patch itself introduces a regression.
That is why the answer is not to avoid automation. The answer is to build better automation: backups, health checks, staged deployment where appropriate, rollback mechanisms, testing, and monitoring, which also bring us to observability.
Deploying an update quickly is useful. Knowing whether it was deployed quickly enough is much more useful. One needs observability for that, and also to answer questions such as:
- Which systems are still vulnerable?
- What software version is each system currently running?
- When was it updated?
- Were exploitation attempts observed before and after the update?
How we dealt with CVE-2026-87902
At Simula, we have been investing in bringing WordPress security information into the same observability stack we use to monitor the rest of our infrastructure.
One of our Grafana panels now shows the WordPress version running on each monitored instance and when that version changed. This builds on the approach we described in Bringing WordPress Security into the Observability Stack, where WordPress security telemetry is integrated with Prometheus, Grafana, and Loki.
In this case, that visibility allowed us to reconstruct the sequence clearly:
- Security patch released (September 22, 2026, at 14:16 UTC)
- Systems updated (September 22, 2026, ~ 17:16 UTC)
- Malicious exploitation attempt observed roughly few hours later (September 23, 2026, at 9:09 UTC)
More importantly, we did not have to reconstruct that timeline from memory, tickets, or assumptions. We had the data.
We could see which WordPress versions were running, when they changed, and when requests attempting to exploit the vulnerability reached our infrastructure.
By correlating software-version telemetry with web-server and security logs, we could determine that the systems had already been patched before the exploitation attempt arrived.
That is where automation and observability complement each other.
Final Thoughts
One day, AI starts shipping perfectly secure code, software vulnerabilities will become a thing of the past. Until then, we have to survive in a world where the time between vulnerability disclosure and exploitation continues to shrink.
In this environment, a lack of automation or observability is not just an operational inconvenience. It is a security risk that eventually becomes expensive.