Three Critical Bugs in One Week Show Monthly Patching Was Losing

One week, three very different problems

The week around October 16, 2026 makes a useful case study because the headline vulnerabilities had almost nothing in common except timing. At Hexacon in Paris, the security firm Calif showed an untethered jailbreak of an iPhone 18 Pro running iOS 27.0.1, with root access coming back after a reboot. No tool and no technical details were released.

Days later, an out-of-bounds write in Google's Brotli decoder, tracked as CVE-2026-111497 and rated CVSS v4.0 9.2, went from a Node.js problem to a much wider one. It was first called Node2Shell after Node.js patched it on October 21, then renamed HTTP2Shell once Python packages, Bun and other HTTP libraries were found to be affected.

In the same stretch, two unauthenticated remote code execution flaws in PHP, known as PHP2Shell, leaked on October 20 ahead of the planned patch, and VulnCheck's honeypots recorded scanning and exploit attempts the next day. Patchstack heard from hosting partners about multiple active exploitation incidents before PHP's security release, and Wiz demonstrated unauthenticated RCE against WordPress, Drupal and Joomla.

So: a phone fleet, a JavaScript and Python dependency, and the runtime underneath WordPress, Drupal and Joomla. If your team handled all three inside one week using its normal process, that process is in good shape. My guess is that plenty of teams dealt with one, queued the second, and only found out about the third when someone outside the team asked.

Is this actually new, or does it just feel that way?

The essay Is this the new cyber normal? ties the week to AI, and it helps to separate what is documented from what is argued. The documented part is on the discovery side: OpenAI found the Brotli flaw back in February, the essay notes that Calif found the PHP bugs as part of OpenAI's 'Patch the Planet' program, and Apple's iOS 27 notes credit Calif.io working with Claude and Anthropic Research for two unrelated bugs. The essay also claims that any public patch notice now leads people to point LLMs at the codebase, read the diffs and work back to an exploitable bug. That is plausible, but none of the sources here document a specific attacker doing it.

The broader numbers are uncomfortable either way. Figures compiled from industry reports put Mandiant's mean time to exploit for 2025 at about negative seven days relative to patch release, meaning exploitation began on average a week before the patch was public. The same compilation cites the Verizon 2026 DBIR finding that vulnerability exploitation was the most common initial access vector at 31%, up from 20% in the previous edition, and counts 48,185 CVEs in 2025.

There is a nuance worth keeping. VulnCheck tracked 884 vulnerabilities first exploited in 2025, found that 28.96% were exploited on or before the day their CVE was published, and described time-to-exploitation patterns as highly consistent with 2024. By that dataset, exploitation did not suddenly speed up last year. It was already fast.

My reading: one clustered week is not proof of a weekly trend, but the monthly patch cycle was losing before this week, and the week simply made it visible. Whether AI pushes timelines further is still open in the data. Waiting for that answer before changing how you work is the wrong call, because the current numbers already justify the change.

Replace the patch window with patch lanes

A single monthly window treats every fix as equal. An exploited, internet-facing RCE ends up in the same queue as a low-risk desktop update, and if exploitation often starts around or before the patch, a fix that waits for next month's slot sits exposed for weeks. A better model is a small number of lanes, sorted by exposure and by whether exploitation has been seen.

HTTP2Shell shows why inventory matters more than raw speed. Node.js shipped fixes in versions 22.23.4, 24.22.1 and 26.12.1, the GitHub advisory lists the PyPI brotli package as vulnerable from 1.0.3 up to 1.2.1 and also covers brotlicffi, and Bun is fixed in 1.4.4. If your team could not say within an hour where those components run, the gap is knowledge, not patching discipline.

The Brotli history adds another wrinkle. According to Aikido, the root cause was fixed in the Brotli source in February but was not recognized as a security issue, and no release carried the fix, so every project that bundles Brotli now has to ship its own update. Your fix therefore arrives through many channels: the runtime, container base images, Python wheels, vendor appliances. Each channel needs an owner, or the lane system becomes theater.

• Emergency lane: internet-facing systems with reported exploitation or pre-auth remote code execution. Decide the same day, then patch or apply a mitigation as soon as anything is available. PHP2Shell belonged here.
• Fast lane: critical-rated flaws in components you expose, with no exploitation reported yet. HTTP2Shell sat here at first. Target this week, not next month.
• Routine lane: everything else, handled in the scheduled maintenance window.
• Freeze override: write down in advance who may break a change freeze for the emergency lane, so nobody has to find that person at 11 p.m.

Phones are the fleet nobody patches on purpose

The iPhone story is worth laying out as a timeline, because the order of events is the lesson. As of the demo date, Apple had not commented publicly, which matches its practice of not confirming security issues until patches are available.

Be honest about what this means. For a period, a fully updated phone was still exposed, and no mobile device management policy changes that. What MDM can do is shrink the gap after Apple ships: enforce a minimum OS version for access to company email and apps, shorten update deferral periods, and keep a list of devices that cannot move to the current release. In my experience, the time between a release and its installation is the part companies can actually control, and it is usually the part nobody measures.

It is also worth dropping the assumption that encrypted messaging makes a phone safe. One analysis of the jailbreak is titled bluntly, 'Encryption Won't Save a Hacked Phone.' Given the videos labeled as one-click exploits through messaging apps, the phones of executives, finance staff and anyone handling contracts deserve the same attention as servers.

Full MDM is not right for everyone. A ten-person company on personal phones may get more from a written rule and a monthly check of OS versions than from software nobody configures. What does not work at any size is leaving the timing entirely to each employee's 'Later' button.

• October 16: Calif demonstrates the untethered iOS 27.0.1 jailbreak at Hexacon, alongside videos labeled as one-click exploits through Signal and iMessage. No vulnerabilities are named, and the team says only that everything will be released in due time.
• October 19: Apple updates its iOS 27 advisory, crediting Calif for a kernel out-of-bounds write (CVE-2026-28968) and a TCC path traversal (CVE-2026-86886). These are two unrelated bugs, not fixes for the demonstrated chain.
• iOS 27.1: installs only on the new iPhone Duo, so it brings no security fixes for existing iPhones. Calif also reportedly jailbroke the iPhone Duo within hours of launch.
• iOS 27.2: Calif says the beta already fixes most of the exploit chain, and researcher Stefan Esser said the vulnerabilities will be patched in 27.2.

Put patch timelines into vendor contracts

In my experience, software and hosting contracts are detailed about uptime and vague about security fixes. PHP2Shell shows why that matters: it was exploited before PHP's own security release, so if a provider runs PHP for you, their reaction time is your exposure window. You should know in writing what they commit to, rather than discovering it during the incident.

The Brotli case is the strongest argument for asking vendors what they bundle. If a product ships its own copy of a compression library, a public advisory tells you nothing until the vendor confirms whether they are affected. A short list of clauses closes most of that gap.

• Notification: the vendor tells you within a defined period when a critical vulnerability affects their product, even before a fix exists.
• Remediation targets by severity, plus written mitigation guidance when no patch is available yet.
• Escalation when exploitation in the wild is reported, with a named security contact rather than the general support queue.
• Component transparency: a list of bundled third-party libraries (an SBOM or equivalent), so you can check an advisory against it yourself.
• Advance notice of end-of-support dates for versions you run.

Staff habits are where the patch rhythm actually lives

Policies set the target, but habits decide the outcome. If restarting a laptop or phone feels like an interruption to be postponed, every patch lane slows to the speed of the most reluctant user. Make restarts routine, and when an emergency update goes out, send a two-line note saying what it fixes and why today matters. In my experience, that short explanation does more than a third reminder email.

Developers need the same shift. Dependency updates belong in normal sprint work, not in a quarterly cleanup. My view is that lockfiles, automated dependency alerts and the ability to rebuild and redeploy a container quickly are what turn an advisory like HTTP2Shell into a short task rather than an investigation, because they answer 'where do we run this?' in minutes instead of days.

Managers have the hardest change to make. 'We'll update next month' is not a neutral default. It is a decision to carry a known risk for weeks, and it should be made explicitly by someone who owns that risk, not by an empty calendar slot. Small disruptions from faster patching are the price, and leadership needs to say out loud that it accepts them.

What patching cannot fix, and where not to overreact

Speed has limits. PHP2Shell was exploited before PHP's release, Mandiant's mean time to exploit was about negative seven days relative to patch release, and VulnCheck found that about 29% of 2025's first-exploited CVEs were hit on or before CVE publication. For that slice of risk, no patch cadence helps. What helps is less exposure: admin panels off the public internet, features you can switch off quickly, network segmentation, logging that would actually show an intrusion, and backups you have restored at least once.

The opposite mistake is treating every CVE as a fire. With 48,185 CVEs published in 2025, a team that runs all-hands weekends for each serious-sounding one will burn out and start ignoring alerts. HTTP2Shell is a fair example: as of October 22, no exploitation in the wild had been reported, and researchers' code execution on Node.js 24.22.0 did not work on every attempt. That justified fast patching of exposed services, not panic.

The new normal, if that is what this is, rewards teams that know what they run, sort risk quickly and keep a calm rhythm. A weekly thirty-minute review of advisories against an accurate inventory will likely beat a heroic monthly marathon.