Project Zero releases emergency patching guidance for large vendors

Project Zero advises large vendors to build emergency patching pipelines using feature flags, filtering, alternate channels, and hotpatching, according to its guidance published Oct. 6, 2026.

The guidance aims to help vendors understand and implement faster vulnerability response capabilities for exceptional exploitation scenarios. Project Zero notes that vendor patch speed is often limited by the testing and delivery stages of the update process. In emergency situations, vendors can expedite triage and patch development, but testing and delivery remain the primary bottlenecks.

Project Zero advises vendors to think about how to fix an urgent vulnerability ahead of receiving one, treating emergency patching as a design choice made in advance. It notes that emergency tools do not have to be heavy or fix every flaw; they ought to address the most likely and serious issues while preserving device usability. The potential cost of shipping poorly tested updates varies: a bricked mobile device incurs substantial vendor and user costs, whereas users can reinstall a corrupted app via an app store with data stored remotely.

Feature flags let vendors turn a feature off or on via a remote server without shipping new code, allowing testing in advance and delivery of only a small amount of data.

An example cited is Apple’s 2019 FaceTime vulnerability, where Group FaceTime was disabled using a feature flag. Meta’s dual‑stack library approach compiles two versions of a library (e.g., WebRTC) into one binary, selectable by a feature flag, enabling rapid updates with the option to revert if problems arise.

Filtering uses a dynamically updatable ruleset to block the specific input needed to reach a vulnerability, such as Android’s Intent Firewall disabling risky intents. Filtering can block inputs that were not anticipated but may degrade performance and requires testing that vendors cannot perform before vendors know the vulnerability. Alternate channels deliver smaller updates more quickly than regular update channels. Android Pony Express (APEX) ships updates to high‑risk components without a full system update.

Hotpatching delivers units of binary code smaller than a library directly into the memory of a running process, exemplified by Linux Livepatch and Windows hotpatch, allowing patches without a restart. Hotpatching has limits on the kinds of changes it can apply (e.g., it may not support modifications to shared structure definitions) and can create ways to bypass exploit mitigations because it requires write‑execute memory permissions.

Some applications can update individual libraries outside the normal cycle by checking a network flag and loading the library with dlopen, but this risks introducing vulnerabilities if the library is not verified to come from the vendor. Updates are often rolled out slowly to detect serious problems before they affect many users, creating a trade‑off between speed of patching and avoidance of buggy patches. User behavior—such as reluctance to restart systems—and network speed can further delay patch propagation, especially for updates requiring a restart.

Chrome and Microsoft have written about the challenges of updates that require a restart to install. Project Zero advises vendors to think about how to fix an urgent vulnerability ahead of receiving one, treating emergency patching as a design choice made in advance. Project Zero notes that emergency tools do not have to be heavy or fix every flaw; they ought to address the most likely and serious issues while preserving device usability.

The potential cost of shipping poorly tested updates varies: a bricked mobile device incurs substantial vendor and user costs, whereas users can reinstall a corrupted app via an app store with data stored remotely. Apple’s 2019 FaceTime vulnerability showed how a feature flag can disable Group FaceTime remotely, providing a rapid response without a code update. Meta’s dual‑stack library approach compiles two versions of a library such as WebRTC into one binary, selectable by a feature flag, enabling rapid updates with the option to revert if problems arise.

Android’s Intent Firewall can be updated with new rules to block the specific intent needed to reach a vulnerability. Android’s Intent Firewall is an example that disables risky intents via such a ruleset. Alternate channels deliver smaller updates more quickly than regular update channels. Android Pony Express (APEX) ships updates to high‑risk components without a full system update.

Hotpatching delivers units of binary code smaller than a library directly into the memory of a running process. Linux Livepatch and Windows hotpatch are examples that allow patches without a restart. Hotpatching has limits on the kinds of changes it can apply; for example, modifications to shared structure definitions may not be supported. Because it requires write‑execute memory permissions, hotpatching can create ways to bypass exploit mitigations.

Some applications can update individual libraries outside the normal cycle by checking a network flag and loading the library with dlopen. This approach risks introducing vulnerabilities if the library is not verified to come from the vendor.

By incorporating feature flags, filtering, alternate channels, and hotpatching into their update processes, large vendors can create emergency patching pipelines that aim to outpace zero‑day exploitation. Designing these mechanisms ahead of time, weighing performance trade‑offs, and considering the costs of poorly tested updates help vendors prepare for urgent vulnerabilities while preserving usability.