Google’s Project Zero, the security team that finds and reports flaws in other companies’ software, argues that the riskiest part of an emergency fix is the fix itself. In a post published 6 October, the team writes for vendors who have not yet asked how they would ship a repair in a crisis. Its advice is mostly about one trade: speed against the chance of breaking something else.
The normal release process is a stack of safeguards. Fixes go through formal testing, limited beta groups, and gradual rollouts, because any change to software can alter behaviour nobody planned for. Project Zero says the early stages speed up on their own when a vendor knows the problem is urgent, and agreements with partners such as mobile carriers usually carry exceptions for emergencies. Testing and delivery are what remain.
A bad patch costs different amounts depending on the product. A phone app that crashes on launch can be replaced through the app store, and its data usually lives on a server, so the bill is mostly support calls. A phone that stops working after an update may have to go back to the maker or the shop. Updates that wipe data or remove features also leave a quieter cost: people grow wary of installing the next one.
So the practical question is which safeguards can safely be skipped. The post’s answer is to do the testing early, before any emergency exists. Feature flags are the clearest case. A flag is a switch inside the software that a remote server can flip, and flipping it sends a tiny message rather than a new build. Project Zero points to Apple switching off Group FaceTime this way after a serious 2019 flaw. Because each position of the switch was tested in advance, the emergency update ships no untested code.
Meta’s version of the idea puts two copies of its video-calling library inside one app and lets a flag choose between them. If the newer copy misbehaves, users move back. Project Zero suggests a vendor could also keep two different libraries that do the same job and switch away from whichever one holds the bug.
Flags have a ceiling: someone has to guess in advance what they will want to turn off. Filtering removes that limit. A filter is a rule list that blocks the specific malicious input a bug needs, and Android’s Intent Firewall works this way. It can stop attacks nobody anticipated. But the testing problem returns, because a rule cannot be tested before the bug is known, and a badly written one can block something the system needs. Filters can also slow software down.
The post is blunter about methods that skip the most checking. Delivering a replacement library outside normal updates, or patching code directly in a running program’s memory (hotpatching), fixes the delivery delay but does nothing for testing. Both open new holes if the receiving device fails to confirm where the code came from, and hotpatching needs memory permissions that can weaken exploit defences. A fast lane for fixes is also a fast lane for attackers.
This is not an AI story, though the post gives one reason for urgency. Project Zero says language models are improving both attackers’ and defenders’ ability to find and exploit flaws, so more people can mount novel attacks quickly. That is the team’s own assertion, and the post offers no figures to support it.
For any team that ships software to customers, the cheap work happens before the incident. If you cannot name which feature you would switch off tonight, and show it was tested switched off, you do not yet have an emergency plan.
Google Project Zero, “How to fix a bug in a fix,” published 6 October 2026.
