Project Zero on emergency patching: fixing exploited bugs faster than a normal release

When a vulnerability is being exploited, the usual advice is to patch quickly. A Project Zero post by Natalie Silvanovich, published on 6 October 2026, looks at why that is hard and what vendors can build in advance. Some vendors told Project Zero they worry about vulnerabilities that cause immediate user harm but that they can't fix because of limits in their patch delivery systems.

Where the time goes

The post splits patching into six stages: triage, patch development, testing, partner review, delivery and activation, such as a restart. Stages can repeat. A failed test, for example, can force the fix to be rewritten.

When a vendor already knows an issue is urgent, triage and development are usually quick. Testing and delivery are the bottlenecks. A bad update can brick devices, corrupt or lose user data, and make users less willing to install later updates. How costly that is depends on the product: a broken mobile app is mostly a support cost, while a bricked device may need to be physically returned and repaired. Delivery is also slowed by polling-based update designs, user reluctance to install or restart, network and data costs, and the strain of updating many users at once.

Four emergency mechanisms

Feature flags

A server-controlled conditional lets a vendor switch off a feature during an emergency. The post's main example is Apple's temporary disabling of Group FaceTime in 2019. Because the flagged code path can be tested ahead of time, flipping the flag doesn't ship untested code, and the payload is small. The post also describes Meta's "dual stack" WebRTC approach, which compiles two library versions into one binary so users can be moved back if problems arise.

Filtering

A dynamically updatable ruleset, such as a regular expression, blocks the specific untrusted input needed to reach a vulnerability. Examples in the post include the Android Intent Firewall, which uses an updatable XML rule file, plus Microsoft Defender on Windows and Google Play Protect on Android. Filtering can block inputs nobody anticipated, which makes it more flexible than a flag. The costs are performance overhead, the need for testing, and the risk of breaking functions the system needs.

Alternate channels

Some components ship through a faster route than the full system update. Android Pony Express (APEX) is the post's example for high-risk Android components. Some apps also check a flag over the network, then download and load a library. The post warns that such mechanisms must verify the code really comes from the vendor. Otherwise the emergency channel becomes a serious attack vector.

Hotpatching

Hotpatching applies small binary units directly to a running process's memory. Linux Livepatch does this for kernel functions, and Windows hotpatch delivers function-level security updates to running processes. Users aren't disrupted, but not every change fits, such as changes to structure definitions. Hotpatching also needs write-execute page permissions, which could weaken exploit mitigations, and it doesn't remove the testing problem.

What this means for security teams

The post's central argument is that these mechanisms need not be perfect or preserve full functionality. They only need to handle the most likely and severe bugs in the short term. The author recommends that vendors inventory the update mechanisms they already have and fill the gaps before a widespread exploitation event. The post notes that LLMs are making discovery and exploitation faster for both attackers and defenders, which raises the stakes.

For defenders, the useful questions are about your own estate. Which of your vendors can disable a feature remotely? Which can push a filter, and how quickly do those changes reach you? If you build software, do you have a tested kill-switch for your riskiest parsers and codecs? Any out-of-band channel you add also needs code-signing and provenance checks, as the post warns.