Fact-checked by Grok 2 weeks ago

Project Zero

Project Zero is a team of security researchers at Google, launched in July 2014, dedicated to proactively identifying zero-day vulnerabilities—previously unknown flaws exploitable by attackers—in hardware, software, and operating systems used by billions worldwide.^[1] The initiative targets flaws that enable targeted attacks, with the explicit goal of reducing their incidence and impact by fostering faster vendor responses, advancing mitigation techniques, and sharing technical insights to harden systems against exploitation.^[2] Central to Project Zero's approach is a rigorous disclosure policy: vulnerabilities are reported to affected vendors immediately upon discovery, with full public release of details, including proof-of-concept exploits, after a 90-day window for patching, extended by up to 30 days in exceptional cases like active in-the-wild exploitation.^[3] This framework prioritizes user protection over vendor convenience, pressuring companies to address defects swiftly, though it has sparked tensions with entities like Apple and Microsoft, who argue short timelines risk exposing users to unpatched risks before fixes deploy broadly.^[4] In July 2025, the team piloted a "reporting transparency" update, committing to anonymized early notices within seven days of notification for select issues, aiming to signal urgency and shrink patching delays without immediate full disclosure.^[5]^[6] The project's outputs include exhaustive root-cause analyses of real-world exploits, such as iMessage zero-click attacks and kernel privilege escalations, which have informed industry-wide defenses and highlighted persistent weaknesses in popular platforms.^[7] Notable achievements encompass documenting over 100 zero-days since inception, many affecting core infrastructure like browsers and mobile OSes, thereby catalyzing mitigations that demonstrably curb attack surfaces.^[2] By maintaining a public blog and issue tracker, Project Zero promotes empirical security research, emphasizing causal factors in bug origins over superficial attributions, though its Google affiliation raises questions about selective focus on non-proprietary software despite the firm's own ecosystem vulnerabilities.^[1]

History

Founding in 2014

Project Zero was publicly announced by Google on July 15, 2014, through a post on the Google Online Security Blog, establishing it as a dedicated team of security researchers tasked with identifying zero-day vulnerabilities in core software infrastructure to prevent their exploitation in targeted attacks.^[1] The initiative stemmed from Google's assessment that existing reactive measures, such as vendor notifications without enforcement, failed to sufficiently deter attackers who weaponized undisclosed flaws against high-value targets like activists and organizations.^[1] By proactively hunting these vulnerabilities, the project aimed to shrink the pool of exploitable zero-days available to adversaries, with an explicit goal of "making 0-days hard" through systematic eradication rather than mere detection.^[8] The founding team was drawn from Google's internal security experts, herded by researcher Chris Evans, and included specialists such as Tavis Ormandy and Ben Hawkes, who brought expertise in reverse engineering and vulnerability analysis.^[9]^[10] Initial efforts targeted flaws in third-party platforms ubiquitous across billions of devices, including web browsers, operating systems, and related components, prioritizing those enabling remote code execution or privilege escalation over Google-specific products.^[1] This focus reflected a first-principles approach: vulnerabilities in shared ecosystem software amplified attack surfaces far beyond individual vendors, necessitating broad scrutiny to disrupt causal chains of exploitation.^[10] Unlike conventional bug bounties that incentivize secretive reporting with rewards but delay public awareness until patches deploy, Project Zero adopted an aggressive disclosure stance from the outset, committing to notify vendors privately while publishing full details—including proof-of-concept exploits—in a public database after 90 days, patched or not.^[1] This policy was designed to impose accountability on slow-responding manufacturers, leveraging transparency to accelerate fixes and deter stockpiling of flaws by state actors or criminals, though it drew criticism from some vendors for potentially aiding attackers during the window.^[10]^[9]

Key Milestones and Expansion (2015–2023)

In February 2017, Project Zero researcher Tavis Ormandy identified a buffer overflow vulnerability in Cloudflare's HTML parser, dubbed Cloudbleed, which leaked uninitialized memory containing sensitive data such as authentication tokens and HTTP headers from customer sites; the flaw had been active since at least September 2016 and affected millions of requests before patches were deployed.^[11]^[12] This disclosure prompted immediate mitigations across Cloudflare's infrastructure and search engine cache purges, illustrating Project Zero's role in addressing large-scale web service risks without prior vendor awareness.^[11] In January 2018, Jann Horn of Project Zero disclosed Meltdown (CVE-2017-5754), a speculative execution vulnerability in Intel x86 processors that allowed user-level code to access kernel memory, with coordinated precursor research contributing to the broader Spectre family revelations.^[13] This work, involving analysis of CPU out-of-order execution flaws, accelerated industry-wide hardware and software patches from vendors including Intel, Microsoft, and Apple, emphasizing Project Zero's influence on systemic defenses against microarchitectural attacks.^[14]^[13] Project Zero began systematically tracking in-the-wild zero-day exploits in mid-2014, documenting 28 instances in 2015 as a baseline for empirical trends in active exploitation.^[15] By 2021, detections reached a record 58 such exploits—more than double the 2015 peak—spanning browsers, operating systems, and enterprise software, which underscored the team's growing capacity to monitor and quantify global threat patterns through aggregated reporting.^[15]^[16] These annual assessments, derived from public disclosures and intelligence sharing, informed vendor prioritization and highlighted persistent exploitation chains, without relying on unverified attributions.^[15] From 2015 onward, Project Zero enforced its 90-day disclosure policy rigorously, reporting over 376 vulnerabilities by 2021 with vendors fixing 93.4% within deadlines and achieving 95.8% compliance by 2019, including grace periods for complex issues.^[17]^[18] This track record reflected operational scaling, as evidenced by specialized analyses of kernel-level flaws in iOS XNU and Windows drivers, alongside Android exploit chains, fostering deeper ties to Google's ecosystem for cross-platform hardening.^[19]^[20]^[21]

Recent Developments (2024–2025)

In November 2024, Google Project Zero, in collaboration with Google DeepMind, released Big Sleep, an advanced AI agent leveraging large language models to automate the discovery of software vulnerabilities, evolving from the earlier Naptime prototype.^[22] Big Sleep identified its first real-world flaw shortly after launch: an exploitable stack buffer underflow in SQLite's fts5_tokenizer module, demonstrating the potential of machine learning to augment manual fuzzing and symbolic execution techniques in vulnerability hunting.^[23] By mid-2025, the agent had detected multiple undisclosed issues and even intervened to halt active exploitation attempts, underscoring Project Zero's integration of AI to address the growing scale of codebases and attack surfaces.^[24] In July 2025, Project Zero initiated a disclosure policy trial to enhance transparency and accelerate vendor accountability while preserving the core 90-day fix window followed by a 30-day grace period for patch details.^[5] Under the updated framework, the team began publicly announcing vulnerability discoveries within one week of reporting to vendors, enabling earlier ecosystem awareness of potential risks without immediate technical disclosure.^[6] This adjustment also includes proactive notifications to upstream projects and public tracking of remediation progress, aimed at mitigating delays in patching widely used components amid rising zero-day exploits in edge devices and enterprise software.^[25] On September 26, 2025, Project Zero researcher Jann Horn published findings on pointer leaks via pointer-keyed data structures, such as hash maps in kernel implementations, which can undermine Address Space Layout Randomization (ASLR) protections.^[26] The analysis highlighted how collisions in pointer-derived keys during remote interactions could leak address information, facilitating kernel exploits in scenarios with increasing remote code execution trends.^[26] This work reflects ongoing emphasis on low-level memory safety primitives as countermeasures evolve against sophisticated adversaries.^[26]

Organizational Structure

Team Composition and Notable Members

Project Zero consists of a small, elite cadre of security researchers selected for their proven expertise in vulnerability discovery and exploit development, drawn primarily from independent hackers, academic backgrounds, and prior industry roles in product security or consulting. The team emphasizes specialists in high-impact areas such as operating system kernels, web browsers, and firmware reverse engineering, enabling rigorous analysis of complex attack surfaces. This composition prioritizes depth in adversarial simulation over breadth, with researchers dedicating full time to proactive hunting of zero-day flaws rather than reactive patching or product-specific mandates.^[27]^[10] Notable current members include Jann Horn, whose work centers on kernel-level memory corruption and race conditions in Linux and related systems.^[28] Natalie Silvanovich focuses on browser engines, WebAssembly, and fuzzing techniques to uncover remote code execution paths.^[29] Tavis Ormandy contributes expertise in reverse engineering binaries and dissecting proprietary software protections.^[30] These researchers exemplify the team's recruitment of top independent talent, often identified through public exploit demonstrations or capture-the-flag competitions, fostering a culture of uncompromised technical depth unconstrained by short-term corporate priorities.^[27] Former members such as Maddie Stone, who specialized in reverse engineering firmware and tracking in-the-wild exploits, highlight moderate turnover as researchers transition to related Google roles like the Threat Analysis Group while retaining institutional knowledge.^[31] Ian Beer, known for probing iOS kernel and wireless protocol weaknesses, further illustrates the influx of autodidact hackers who bring external perspectives untainted by vendor incentives. The team's operational autonomy within Google—vendor-agnostic and mission-bound to preempt nation-state-grade threats—supports this model by allocating resources for long-horizon investigations, insulating pursuits from product release cycles or internal politics.^[32]^[33]

Recruitment and Operational Model

Project Zero recruits security researchers primarily through Google's standard hiring channels, with candidates applying for Information Security Engineer positions on the Google Careers site while explicitly noting interest in the team.^[27] The selection process emphasizes practical expertise, including strong programming abilities, vulnerability research, and exploit development, with a strong preference for applicants who have publicly reported vulnerabilities or produced high-quality, empirical security demonstrations such as proof-of-concept exploits.^[27] This focus on verifiable track records extends to achievements in competitive hacking events like Pwn2Own, where team members such as James Forshaw have demonstrated prowess by winning contests and bypassing mitigations.^[34] The operational model centers on full-time dedication from researchers to proactive, independent vulnerability hunting, allocating resources to long-term projects like hardware reverse-engineering to uncover systemic flaws empirically, rather than responding to vendor-directed audits.^[35]^[2] This approach prioritizes causal analysis of real-world exploit chains—verifiable, weaponizable vulnerabilities—over speculative or theoretical risks, enabling deeper insights into attack vectors across widely deployed software and hardware ecosystems.^[2] Collaboration occurs through public blog publications detailing techniques and findings, alongside selective open-source contributions of tools and mitigations, while active investigations remain under non-disclosure to prevent premature exploitation.^[27]^[2] Researchers maintain autonomy in target selection, focusing on high-impact areas like mobile operating systems, browsers, and foundational libraries to drive measurable security improvements.^[2]

Research Approach

Vulnerability Identification Techniques

Project Zero employs a combination of automated fuzzing, manual code audits, and reverse engineering to identify vulnerabilities, prioritizing techniques that uncover complex, exploitable flaws in high-value targets such as operating systems, browsers, and hardware interfaces.^[36] Fuzzing forms a cornerstone of their approach, particularly for parsing complex codebases where manual review proves inefficient, as demonstrated in analyses of multimedia codecs like Qmage.^[37] Researchers develop custom fuzzing harnesses to simulate real-world inputs and target specific components, such as CoreAudio via Mach messages or network syscalls in XNU, enabling coverage-guided mutation to trigger crashes and memory errors.^[38]^[39] Manual reverse engineering complements fuzzing by dissecting binaries and firmware, often using disassembly to map control flows and identify logic errors in undocumented code paths.^[36] This includes static analysis for attack surface reduction and dynamic instrumentation to observe runtime behaviors, as applied in kernel extension fuzzing with tools like Ghidra for basic block identification.^[23] Techniques such as these avoid superficial bugs, focusing instead on verifying causal chains from malformed inputs to code execution via exploit prototyping.^[38] The team emphasizes vulnerabilities with real-world impact, such as sandbox escapes and privilege escalations, which chain multiple flaws to bypass isolation mechanisms in environments like Chrome renderers or iOS kernels.^[40]^[41] Cross-platform analysis integrates custom harnesses for Windows, macOS, and Linux targets, sidelining low-severity issues in favor of zero-days requiring sophisticated exploitation, like those in audio drivers or syscall interfaces.^[42]^[39] This targeted methodology ensures discoveries address systemic weaknesses rather than isolated crashes.

Targeted Focus Areas

Project Zero prioritizes vulnerability research in core components of widely deployed operating systems and browsers, such as iOS Safari, Windows kernels, Linux kernels, and Android graphics processing units, due to their ubiquity and historical prevalence in exploited zero-days affecting billions of devices.^[43]^[44] This empirical focus derives from analysis of real-world exploit chains, where kernel-level and browser sandbox escapes enable broad compromise vectors, as evidenced by repeated in-the-wild targeting of these surfaces.^[45] Secondary emphasis extends to hardware interfaces, including CPU speculative execution flaws and GPU drivers, which amplify software vulnerabilities through side-channel leaks or mis-speculation, impacting multiple ecosystems beyond software alone.^[14]^[46] These targets are selected over peripheral or application-specific code, as data indicates that high-impact exploits cluster in foundational layers rather than niche modules, minimizing research on low-prevalence bugs that fail to disrupt attacker operations at scale.^[47] Recent efforts incorporate in-the-wild monitoring through systematic reverse-engineering of deployed exploits, emphasizing telemetry from observed chains to identify state-sponsored or criminal patterns without dependence on external reporting.^[48] This approach tracks attribution via technical indicators like reuse of primitives across campaigns, revealing persistence in kernel and browser primitives over bespoke tools. In 2024, tracking revealed 75 zero-day exploits in the wild, with 44% (33 vulnerabilities) directed at enterprise technologies—predominantly core OS and browser elements—highlighting the rationale for scoped prioritization amid rising sophistication.^[49]^[50]

Disclosure and Reporting Practices

Evolution of the 90-Day Policy

Project Zero established its 90-day disclosure policy upon its founding on July 15, 2014, granting vendors 90 days from notification to develop and release patches for reported vulnerabilities before details would be publicly disclosed.^[1] This framework included an additional 30 days for particularly complex issues requiring extensive verification, aiming to incentivize rapid remediation while ensuring users were informed of unpatched risks in a timely manner.^[3] The policy marked a departure from prior industry norms of indefinite non-disclosure, prioritizing coordinated vulnerability disclosure to exert causal pressure on vendors to prioritize security fixes.^[51] The policy's rationale stemmed from first-hand observations of exploit development timelines and vendor response patterns, recognizing that prolonged secrecy often benefited attackers more than users by allowing unaddressed flaws to persist.^[51] Empirical data from early reports indicated that most vendors could achieve fixes within the 90-day window, with analysis of 73 issues reported after October 1, 2014, showing 95% resolved in time, thereby minimizing the vulnerability-to-exploitation gap without unduly hindering patch verification.^[51] This approach sought to align incentives such that vendors faced accountability for delays, fostering a defensive posture against zero-day threats observed in real-world attack chains.^[1] Enforcement involved strict adherence to the deadline, with public advisories issued immediately upon expiration if patches were absent, as demonstrated in early cases involving Apple Safari rendering engine flaws reported in 2014-2015, where disclosure proceeded after the 90 days to highlight unmitigated risks.^[3] Similar application to Google Chrome components underscored internal accountability, though cross-vendor examples like Adobe Flash—where all 37 reported issues were fixed within 90 days—illustrated the policy's effectiveness in promoting compliance without exception for high-profile targets.^[51] These instances reinforced the policy's role in creating verifiable pressure for fixes, with deadlines adjusted only for non-working days to ensure fairness in counting.^[51]

Policy Adjustments and Exceptions

In July 2025, Project Zero launched a "Reporting Transparency" trial as a refinement to its disclosure practices, introducing early public notification within one week of reporting a vulnerability to the affected vendor.^[5] This step discloses limited details—such as the vendor, product, and CVE identifier if assigned—without proof-of-concept code or exploit information, aiming to accelerate patch development and deployment by signaling risks to the broader security community.^[6] The adjustment responds to observed delays in the "upstream patch gap," where vulnerabilities often remain unaddressed for extended periods post-notification, based on Project Zero's analysis of historical zero-day trends showing prolonged vendor response times.^[5]^[52] The core 90+30-day policy—90 days for initial patching plus 30 days for patch adoption—remains unchanged, with full technical disclosure occurring only after these timelines unless the vendor demonstrates verifiable progress, such as deploying fixes to affected users.^[5]^[4] Exceptions to disclosure deadlines, including any vendor or external requests for extensions (such as government holds), are evaluated individually, requiring concrete evidence of mitigation efforts or potential widespread harm rather than unsubstantiated claims of secrecy needs.^[53] This case-by-case scrutiny prioritizes empirical outcomes, like reduced exploit prevalence in tracked zero-days, over indefinite non-disclosure, drawing from Project Zero's longitudinal data indicating that extended secrecy correlates with higher in-the-wild exploitation risks absent patches.^[5] The trial includes public tracking of reports to enhance accountability, with initial implementation focusing on high-impact vulnerabilities to test efficacy in prompting faster, higher-quality fixes.^[54]

Notable Discoveries

High-Impact Hardware Vulnerabilities

Project Zero researcher Jann Horn identified key vulnerabilities in CPU speculative execution mechanisms in 2017, including what became known as Meltdown (a side-channel attack enabling user-level processes to read kernel memory) and Spectre Variant 1 (exploiting branch prediction to leak data across security boundaries).^[14] These flaws affected processors from Intel, AMD, and ARM architectures by abusing transient instructions executed speculatively for performance gains, allowing attackers to extract sensitive data via cache timing measurements at rates exceeding hundreds of bytes per second.^[55] Disclosure occurred on January 3, 2018, via coordinated public release, prompting emergency microcode updates, operating system kernel modifications (such as kernel page table isolation), and compiler changes like retpoline to insert return instructions that avoid vulnerable indirect branches.^[14] Subsequent Project Zero analysis extended to Spectre Variant 2, which poisons branch target buffers to redirect speculative execution toward attacker-controlled gadgets, further demonstrating how performance optimizations in out-of-order execution pipelines create exploitable information leaks across virtual machine boundaries and sandboxes.^[14] These discoveries highlighted systemic design trade-offs in modern CPUs, where aggressive speculation for throughput sacrifices strict isolation, enabling flaws that persist despite software mitigations due to underlying hardware behaviors. Empirical testing by Project Zero confirmed practical exploitability, with proof-of-concept code extracting encryption keys from co-resident processes on affected systems.^[55] Project Zero's continued CPU research uncovered additional transient execution vulnerabilities, including seven new variants in late 2018 that exploited microarchitectural elements like load ports and store buffers to disclose data from speculative paths, empirically tying these to potential in-the-wild chains when combined with software flaws.^[56] Such findings compelled hardware vendors to implement ongoing redesigns, such as enhanced barrier instructions and speculative barrier insertions, revealing underemphasized risks in pre-disclosure vendor audits of optimization techniques. These processor-level issues underscore causal links between speculative hardware features and broad attack surfaces, independent of firmware or OS configurations.^[55]

Software and Browser Exploits

Project Zero's early investigations into browser security yielded multiple remote code execution (RCE) vulnerabilities in Apple's Safari browser, primarily through flaws in the WebKit rendering engine, reported between 2014 and 2015. These defects enabled attackers to inject and execute malicious code within the browser's rendering process, often serving as the initial vector in multi-stage exploit chains. Accompanying these RCE primitives were sandbox escape techniques that elevated privileges beyond WebKit's isolation, such as logic errors in Mach task port handling and insufficient validation of inter-process communication on macOS and iOS, allowing full system compromise when chained. These findings, derived from manual source code audits and binary reverse engineering, underscored persistent weaknesses in Apple's sandboxing model despite prior mitigations like XNU kernel enhancements.^[57] Expanding to other platforms, Project Zero uncovered zero-day vulnerabilities in Microsoft Windows, including use-after-free errors and integer overflows in core components like the Win32k graphics subsystem, which bypassed address space layout randomization (ASLR) and data execution prevention (DEP) in exploit chains targeting kernel elevation from user-mode RCE. In Chromium-based browsers like Google Chrome, researchers identified renderer RCE flaws, such as type confusion bugs in the V8 JavaScript engine and heap buffer overflows in layout processing, totaling 14 zero-days disclosed in 2021 alone, many involving sandbox escapes via Mojo IPC mishandling to reach the renderer utility process. These browser exploits typically combined memory corruption for code execution with privilege escalation to utility processes, demonstrating recurring patterns in cross-origin renderer compromises.^[15] A notable 2021 case involved a heap overflow in Mozilla's Network Security Services (NSS) library during DSA and RSA-PSS signature verification (CVE-2021-43527), reported by Project Zero's Tavis Ormandy, which could enable code execution in applications like email clients or PDF viewers relying on NSS for cryptographic operations. The postmortem revealed patching failures due to rushed fixes that overlooked edge cases in DER-encoded signatures, allowing incomplete resolutions despite initial mitigations like bounds checks; this highlighted systemic issues in vendor response timelines under pressure, where partial patches prolonged exposure without comprehensive testing.^[58]^[59] On iOS, Project Zero dissected kernel-level mitigations like pointer authentication codes (PAC), identifying bypasses through speculative execution attacks and key leakage via pointer-keyed data structures, verified with proof-of-concept code that forged authenticated pointers to hijack control flow. A 2019 analysis of PAC on the A12 processor in iPhone XS exposed implementation gaps, such as modifiable authentication modifiers in XNU kernel signing, enabling chainable exploits from user-space RCE to kernel read/write primitives. Follow-up work in 2020 detailed persistent PAC weaknesses post-iOS 13 deployment, including branch predictor manipulations for key recovery, which evaded hardware-enforced pointer integrity in real-world privilege escalation scenarios.^[60]^[26]

In-the-Wild Zero-Day Tracking

Project Zero has tracked zero-day vulnerabilities exploited in active attacks, known as "in-the-wild" exploits, since mid-2014 through a publicly available spreadsheet that logs detected cases based on telemetry, vendor reports, and researcher disclosures.^[61]^[62] This effort focuses on empirical evidence of real-world exploitation chains, often involving memory corruption flaws, rather than theoretical vulnerabilities.^[15] Detection peaked in 2021 with 58 in-the-wild zero-days disclosed, surpassing prior records and highlighting intensified adversary activity amid supply chain compromises and targeted intrusions.^[15] Numbers declined to 41 in 2022, attributed to enhanced browser mitigations like site isolation and improved sandboxing that disrupted common exploit paths, though exploitation persisted in chained attacks.^[63]^[64] By 2024, tracking under Google Threat Analysis Group—following the program's transition from Project Zero—recorded 75 cases, with a notable shift toward enterprise technologies such as network appliances and collaboration tools, reflecting attackers' adaptation to hardened consumer endpoints.^[49]^[63] Attribution in these tracks relies on exploit telemetry, such as unique code patterns or delivery vectors, linking many Chrome-based exploits to nation-state actors or commercial spyware operators without relying on unverified intelligence claims.^[65] For instance, 2021 campaigns exploited Chrome vulnerabilities to achieve remote code execution on Android and Windows devices, enabling persistent access in targeted operations against high-value individuals.^[66] Project Zero's root cause analyses of these chains, including intent-handling flaws and renderer escapes, exposed operational details like multi-stage payloads, aiding broader defenses without overgeneralizing actor motives.^[67]^[15]

Impact and Reception

Contributions to Global Security

Project Zero's disclosures have prompted vendors to issue patches for thousands of vulnerabilities, thereby limiting the window for exploitation in widely used software ecosystems. Between its inception in 2014 and 2019, the team contributed to the identification and remediation of over 1,500 security flaws across major platforms, reducing the availability of unpatched zero-days for malicious actors.^[68] In a single year reviewed in 2022, Project Zero reported 376 vulnerabilities under its disclosure policy, with 93.4% resulting in fixes from vendors, demonstrating a high rate of causal impact on patch deployment.^[18] These efforts have notably enhanced security in third-party systems, such as Apple's iOS, where multiple high-severity issues discovered by Project Zero researchers were addressed through subsequent updates. For instance, vulnerabilities in iOS kernel components and memory handling, credited to Project Zero findings, were patched in releases like iOS 10.3.3, iOS 12.1.3, and iOS 14.3, incorporating improved validation and state management to prevent corruption and disclosure risks.^[69]^[70] This pattern of preemptive fixes has contributed to broader iOS hardening, including mechanisms like BlastDoor in iOS 14, which mitigate exploit chains observed in the wild.^[71] On an industry scale, Project Zero's proactive vulnerability hunting correlates with observable declines in successful zero-day exploits targeting certain vectors, prioritizing empirical detection over dependence on regulatory measures. Exploitation rates for browsers and mobile devices dropped by approximately one-third and one-half, respectively, in 2024 compared to prior peaks, amid increased patching velocity driven by such research.^[49] By publicly documenting techniques via detailed blog posts and tools, Project Zero has enabled independent researchers to replicate and extend findings, fostering a decentralized, market-oriented approach to security enhancement without relying on centralized mandates.^[1]

Criticisms from Vendors and Industry

Vendors such as Microsoft have criticized Project Zero's 90-day disclosure policy as overly rigid and akin to a "gotcha" tactic, arguing that it fails to account for the technical complexities of developing and deploying patches across diverse systems. In January 2015, Microsoft publicly rebuked Google for disclosing details of an unpatched privilege escalation vulnerability in Windows 8.1 exactly 90 days after notification, despite Microsoft's request for a brief two-day extension to align with its monthly Patch Tuesday cycle, claiming the premature release endangered users by providing attackers with exploit information before mitigations were available. Similar complaints arose from subsequent disclosures of Windows flaws in the same period, where Microsoft highlighted the policy's inflexibility in accommodating vendor-specific release processes.^[72]^[73]^[74] Apple has echoed concerns about the policy's aggressiveness, particularly in cases involving macOS and iOS, where disclosures have been portrayed as incomplete or timed to overlook vendor efforts. In 2015, Project Zero revealed three unpatched vulnerabilities in OS X shortly after the 90-day window, prompting Apple to argue that such actions prioritized publicity over collaborative security improvements. More recently, in a 2021 postmortem on a critical use-after-free vulnerability (CVE-2021-43527) in the Network Security Services (NSS) library—used by multiple vendors including those integrating with Apple products—Project Zero itself noted systemic patching delays and insufficient testing rigor, which indirectly strained resources for affected parties reliant on third-party components. Apple has further contended that Project Zero's reports, such as those on iOS exploit chains, sometimes present skewed narratives that downplay the rarity and targeted nature of threats while amplifying unpatched issues.^[75]^[76]^[58] Industry observers and some vendors have raised accusations of bias favoring Google's Android ecosystem, suggesting Project Zero disproportionately targets competitors; however, empirical data from disclosures between 2019 and 2021 indicate equitable scrutiny, with 376 vulnerabilities reported across diverse vendors, including 93% fixed within timelines, encompassing Windows, iOS, and others without evident favoritism toward Google products. Smaller vendors have voiced economic pressures from the policy's demands, claiming the short window exacerbates resource limitations for comprehensive testing and deployment, potentially diverting funds from innovation to reactive security fixes, though quantitative analyses of such stifling effects remain limited.^[77]

Controversies and Internal Debates

In March 2021, Project Zero and Google's Threat Analysis Group publicly disclosed a series of 11 zero-day vulnerabilities exploited in a nine-month counterterrorism operation conducted by a Western government ally, primarily targeting iOS, Android, and Windows devices through watering-hole attacks on infected websites starting in early 2020.^[78] The disclosure, announced without attributing the operators, effectively neutralized the operation by alerting vendors and users, prompting patches that rendered the exploits obsolete.^[79] This decision sparked internal friction within Google's security teams, where some researchers advocated for exemptions from standard disclosure policies for operations deemed beneficial, such as those disrupting terrorist networks, arguing that such targeted use minimized broader risks compared to adversarial exploitation.^[78] Opponents within the teams countered that vulnerabilities inevitably proliferate beyond initial users, with empirical evidence from prior cases showing rapid re-exploitation by non-state actors if left unpatched, prioritizing widespread user protection over geopolitical considerations.^[78] The debate highlighted tensions in Project Zero's 90-day disclosure framework, which lacks formal exceptions for government-sponsored in-the-wild exploits, leading to discussions on whether temporary holds should weigh verifiable end-user harm—such as civilian compromise rates—from unpatched flaws against claims of operational value in counterterrorism.^[80] Critics, including former intelligence officials, noted hallmarks of Western operations in the code, suggesting the shutdown risked endangering agents and soldiers by exposing sources and methods, as seen in analogous cases like the U.S. Joint Special Operations Command's Slingshot campaign.^[81] Broader critiques have questioned Project Zero's role in enforcing disclosure timelines that function as de facto industry standards, given Google's market dominance in search and Android ecosystems, potentially bypassing democratic processes for vulnerability management.^[78] These concerns underscore ongoing debates about private entities unilaterally influencing global security norms, though proponents maintain the approach's transparency has empirically accelerated patching, with no verified instances of heightened user risk from the 2021 disclosures.^[82]

References

[1]
Announcing Project Zero - Google Online Security Blog
Jul 15, 2014 · Project Zero is our contribution, to start the ball rolling. Our objective is to significantly reduce the number of people harmed by targeted ...
[2]
About Project Zero
- **Description**: Project Zero is a team of security researchers at Google formed in 2014, focusing on zero-day vulnerabilities in hardware and software systems used globally.
[3]
Vulnerability Disclosure Policy - Google Project Zero
Project Zero follows a 90+30 disclosure deadline policy, which means that a vendor has 90 days after Project Zero notifies them about a security vulnerability ...
[4]
Google Project Zero Changes Its Disclosure Policy
Aug 8, 2025 · Google's Project Zero team will retain its existing 90+30 policy regarding vulnerability disclosures, in which it provides vendors with 90 days ...
[5]
Policy and Disclosure: 2025 Edition - Google Project Zero
Jul 29, 2025 · The primary goal of this trial is to shrink the upstream patch gap by increasing transparency. By providing an early signal that a vulnerability ...
[6]
Project Zero disclosure policy change puts vendors on early notice
Jul 30, 2025 · Google wants to shorten delays in the vulnerability lifecycle by sharing limited details about newly discovered defects within a week of ...
[7]
Project Zero
News and updates from the Project Zero team at Google. Pages. (Move to ...) About Project Zero, 0day "In the Wild" · 0day Exploit Root Cause Analyses ...
[8]
Project Zero: Ten Years of 'Make 0-Day Hard' - YouTube
Oct 9, 2024 · In 2014, Google announced Project Zero, a security research team with the mission to 'make 0-day hard'. A lot has happened since then!
[9]
Google “Project Zero” hopes to find zero-day vulnerabilities before ...
Jul 15, 2014 · Evans is still building the Project Zero team. Some members are being recruited from within Google. For example, Tavis Ormandy, who has ...Missing: initial | Show results with:initial
[10]
Meet 'Project Zero,' Google's Secret Team of Bug-Hunting Hackers
Jul 15, 2014 · A group of top Google security researchers who will be given the sole mission of finding and neutering the most insidious security flaws in the world's ...Missing: great | Show results with:great
[11]
Incident report on memory leak caused by Cloudflare parser bug
Feb 23, 2017 · The bug was serious because the leaked memory could contain private information and because it had been cached by search engines.
[12]
Major Cloudflare bug leaked sensitive data from customers' websites
Feb 23, 2017 · The leak may have been active as early as Sept. 22, 2016, almost five months before a security researcher at Google's Project Zero discovered it ...
[13]
Meltdown and Spectre
Who reported Meltdown? Meltdown was independently discovered and reported by three teams: Jann Horn (Google Project Zero),; Werner Haas, Thomas Prescher ( ...
[14]
Reading privileged memory with a side-channel - Google Project Zero
Jan 3, 2018 · From reading GPZ, Spectre, Meltdown and Fogh, it appears that the side-execution attacks are possible on all modern CPUs, but have only been ...Missing: involvement | Show results with:involvement
[15]
Tuesday, April 19, 2022 - Google Project Zero
Apr 19, 2022 · 2021 included the detection and disclosure of 58 in-the-wild 0-days, the most ever recorded since Project Zero began tracking in mid-2014.Missing: 2015-2023 | Show results with:2015-2023
[16]
Google Project Zero Detects a Record Number of Zero-Day Exploits ...
Apr 20, 2022 · Google Project Zero called 2021 a record year for in-the-wild 0-days, as 58 security vulnerabilities were detected and disclosed during the course of the year.Missing: 2015-2023 | Show results with:2015-2023
[17]
Google Project Zero: 95.8% of all bug reports are fixed ... - ZDNET
Aug 2, 2019 · However, starting with February 13, 2015, Google added an additional 14-day grace period that could extend the deadline under certain conditions ...
[18]
A walk through Project Zero metrics
Feb 10, 2022 · Project Zero reported 376 issues to vendors under our standard 90-day deadline. 351 (93.4%) of these bugs have been fixed, while 14 (3.7%) have been marked as ...
[19]
A survey of recent iOS kernel exploits - Google Project Zero
Jun 11, 2020 · This post summarizes original iOS kernel exploits from local app context targeting iOS 10 through iOS 13, focusing on the high-level exploit flow.Missing: Windows | Show results with:Windows
[20]
Analyzing a Modern In-the-wild Android Exploit - Google Project Zero
Sep 19, 2023 · In December 2022, Google's Threat Analysis Group (TAG) discovered an in-the-wild exploit chain targeting Samsung Android devices.Missing: integration | Show results with:integration
[21]
Google shares details of a Windows Kernel Cryptography Driver ...
Oct 30, 2020 · A post on the Project Zero page explains: "The Windows Kernel Cryptography Driver (cng.sys) exposes a \Device\CNG device to user-mode programs ...
[22]
From Naptime to Big Sleep: Using Large Language Models To ...
Nov 1, 2024 · Friday, November 1, 2024 ... Since then, Naptime has evolved into Big Sleep, a collaboration between Google Project Zero and Google DeepMind.
[23]
November 2024 - Project Zero
Nov 1, 2024 · Today, we're excited to share the first real-world vulnerability discovered by the Big Sleep agent: an exploitable stack buffer underflow in ...
[24]
Cloud CISO Perspectives: Our Big Sleep agent makes a big leap
Jul 17, 2025 · Our Big Sleep AI agent, first introduced in November 2024 by Google DeepMind and Project Zero, has taken a very significant step for defenders.
[25]
Google Project Zero Tackles Upstream Patch Gap With New Policy
Jul 31, 2025 · Google Project Zero now publicly shares the discovery of a vulnerability and when its 90-day disclosure deadline expires.
[26]
Pointer leaks through pointer-keyed data structures - Project Zero
Sep 26, 2025 · Friday, September 26, 2025. Pointer leaks through pointer-keyed data structures. Posted by Jann Horn, Google Project Zero. Introduction. Some ...
[27]
Working at Project Zero
Feb 20, 2019 · Natalie Silvanovich, Security Engineer, Project Zero: Project Zero members spend most of their time doing vulnerability research and exploit ...Missing: notable | Show results with:notable
[28]
How a simple Linux kernel memory corruption bug can lead to ...
Oct 19, 2021 · Posted by Jann Horn, Project Zero. Introduction. This blog post describes a straightforward Linux kernel locking bug and how I exploited it ...
[29]
The Problems and Promise of WebAssembly - Google Project Zero
Aug 16, 2018 · Posted by Natalie Silvanovich, Project Zero WebAssembly is a format that allows code written in assembly-like instructions to be run from ...
[30]
Down the Rabbit-Hole... - Google Project Zero
Aug 13, 2019 · Posted by Tavis Ormandy, Security Research Over-Engineer. “Sometimes, hacking is just someone spending more time on something than anyone ...
[31]
The Unsinkable Maddie Stone, Google's Bug-Hunting Badass
Oct 25, 2020 · Stone is a prominent researcher on Google's Project Zero bug-hunting team, which finds critical software flaws and vulnerabilities—mostly in ...
[32]
New initiatives to reduce the risk of vulnerabilities and protect ...
Apr 13, 2023 · It's why Project Zero, a vendor agnostic security research team that sits within Google and studies zero-day vulnerabilities in hardware and ...Missing: operational independence<|control11|><|separator|>
[33]
#BHUSA: Five Years of Google Project Zero Should Influence ...
Aug 8, 2019 · “We are all bound by a mission and principles, and the key innovation is researchers have individual freedom to pursue their own independent ...Missing: culture operational
[34]
James Forshaw - NULLCON
James is a security researcher in Google's Project Zero. He has been ... Pwn2Own and Microsoft Mitigation Bypass bounty winner. He has spoken at a ...<|separator|>
[35]
Announcing Project Zero
Jul 15, 2014 · Project Zero is our contribution, to start the ball rolling. Our objective is to significantly reduce the number of people harmed by targeted attacks.Missing: initial | Show results with:initial
[36]
Project Naptime: Evaluating Offensive Security Capabilities of Large ...
Jun 20, 2024 · Though much of our work still relies on traditional methods like manual source code audits and reverse engineering, we're always looking for new ...
[37]
MMS Exploit Part 2: Effective Fuzzing of the Qmage Codec
Jul 23, 2020 · The next logical step was to thoroughly fuzz it – the code was definitely too extensive and complex to approach with a manual audit, especially ...Implementing A Qemu Fork... · Results · CrashesMissing: symbolic | Show results with:symbolic
[38]
Breaking the Sound Barrier Part I: Fuzzing CoreAudio with Mach ...
May 9, 2025 · I'll detail how I used a custom fuzzing harness, dynamic instrumentation, and plenty of debugging/static analysis to identify a high-risk type ...Missing: ClusterFuzz | Show results with:ClusterFuzz
[39]
Designing sockfuzzer, a network syscall fuzzer for XNU - Project Zero
Apr 22, 2021 · In this project, I pursued a somewhat unusual approach to fuzz XNU networking in userland by converting it into a library, “booting” it in userspace and using ...Missing: disassembly | Show results with:disassembly
[40]
In-the-Wild Series: Windows Exploits - Google Project Zero
Jan 12, 2021 · In this post we'll discuss the exploits for vulnerabilities in Windows that have been used by the attacker to escape the Chrome renderer sandbox.
[41]
A very deep dive into iOS Exploit chains found in the wild - Project Zero
Aug 29, 2019 · Working with TAG, we discovered exploits for a total of fourteen vulnerabilities across the five exploit chains: seven for the iPhone's web ...Missing: Windows | Show results with:Windows
[42]
googleprojectzero/winafl: A fork of AFL for fuzzing Windows binaries
This project is a fork of AFL that uses different instrumentation approach which works on Windows even for black box binary fuzzing.
[43]
Attacking the Qualcomm Adreno GPU - Google Project Zero
Sep 8, 2020 · This blog post focuses on an interesting attack surface that is accessible from the Android application sandbox: the graphics processing unit (GPU) hardware.
[44]
Google fixes Android kernel zero-day exploited in attacks
Feb 3, 2025 · The February 2025 Android security updates patch 48 vulnerabilities, including a zero-day kernel vulnerability that has been exploited in ...
[45]
[PDF] Project Zero - Black Hat
Aug 7, 2019 · Ensures that the security impact of the bug is well understood. 2. Establishes an equivalence class of similarly exploitable vulnerabilities.
[46]
VU#584653 - CPU hardware vulnerable to side-channel attacks
Jan 4, 2018 · CPU hardware implementations are vulnerable to cache side-channel attacks. These vulnerabilities are referred to as Meltdown and Spectre.<|separator|>
[47]
Root Cause Analyses | 0-days In-the-Wild - GitHub Pages
Project Zero began a program to systematically study 0-day exploits that are used in the wild. It's another way we're trying to make 0-day hard.Missing: annual reports 2014-2023
[48]
In-the-Wild Series: Android Exploits - Google Project Zero
Jan 12, 2021 · This is part 4 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild.
[49]
Hello 0-Days, My Old Friend: A 2024 Zero-Day Exploitation Analysis
Apr 29, 2025 · Google Threat Intelligence Group tracked 75 zero-day vulnerabilities exploited in the wild in 2024, noting a shift towards targeting enterprise technologies.Missing: size | Show results with:size
[50]
44% of the zero-days exploited in 2024 were in enterprise solutions
Apr 29, 2025 · 33 vulnerabilities (44%) affected enterprise solutions, which is up from 37% in 2023, according to Google Threat Intelligence Group researchers.Missing: statistics | Show results with:statistics
[51]
Feedback and data-driven updates to Google's disclosure policy
Feb 13, 2015 · Project Zero has adhered to a 90-day disclosure deadline. Now we are applying this approach for the rest of Google as well.Missing: rationale | Show results with:rationale
[52]
Google's Project Zero to make faster vulnerability announcements
Aug 1, 2025 · Google's elite bug hunters in the Project Zero team will from now on publicly share if they have discovered vulnerabilities within a week ...
[53]
Vulnerability Disclosure FAQ - Google Project Zero
Jul 31, 2019 · The primary argument against releasing proof-of-concept exploit code is that malicious parties can quickly repurpose our research into an attack ...
[54]
Reporting Transparency - Google Project Zero
As part of our 2025 Policy Trial, Project Zero will use this page to publicly track our Reporting Transparency effort. The trial commenced on July 29, 2025 ...
[55]
Today's CPU vulnerability: what you need to know
Jan 3, 2018 · Google's Project Zero team discovered serious security flaws caused by “speculative execution,” a technique used by most modern processors (CPUs) to optimize ...
[56]
Spectre and Meltdown vulnerabilities that affect Intel, AMD - SecPod
Dec 28, 2018 · These are seven new transient execution attacks that discovered by the same team of Google Project Zero researchers, who discovered previous CPU ...
[57]
More Mac OS X and iPhone sandbox escapes and kernel bugs
Oct 1, 2014 · All-bar-one of these bugs were found via manual source code auditing where there was source and binary analysis where there wasn't. As always, ...Missing: 2015 | Show results with:2015
[58]
This shouldn't have happened: A vulnerability postmortem
Dec 1, 2021 · Posted by Tavis Ormandy, Project Zero. Introduction. This is an unusual blog post. I normally write posts to highlight some hidden attack ...
[59]
nss: memory corruption validating dsa/rsa-pss signatures - Monorail
Program received signal SIGSEGV, Segmentation fault. ... I haven't checked yet if macOS's fork of NSS also contains this flaw.
[60]
Examining Pointer Authentication on the iPhone XS - Project Zero
Feb 1, 2019 · In this post I examine Apple's implementation of Pointer Authentication on the A12 SoC used in the iPhone XS, with a focus on how Apple has improved over the ...
[61]
0-days In-the-Wild - GitHub Pages
This site aims to be a central repository for information about 0-days exploited in-the-wild! It's maintained by Google Project Zero.Missing: mission make great again
[62]
Root Cause Analyses for 0-day In-the-Wild Exploits - Project Zero
Jul 29, 2020 · We've added a new column to the “0day In the Wild” tracking spreadsheet that will link to any RCAs that we publish. We will also continue to ...
[63]
A Year in Review of 0-days Exploited In-the-Wild in 2022
Jul 27, 2023 · 41 in-the-wild 0-days were detected and disclosed in 2022, the second-most ever recorded since we began tracking in mid-2014, but down from the 69 detected in ...Missing: mission | Show results with:mission
[64]
Google: 41 zero-day vulnerabilities exploited in 2022 - TechTarget
Jul 27, 2023 · New browser mitigations contributed to a decrease in zero-day vulnerabilities affecting browsers. Google also observed that many attackers ...<|control11|><|separator|>
[65]
Spyware vendors use 0-days and n-days against popular platforms
Mar 29, 2023 · In this blog, we're sharing details about two distinct campaigns we've recently discovered which used various 0-day exploits against Android, iOS and Chrome.
[66]
Hackers Used Zero-Days to Infect Windows and Android Devices
Jan 15, 2021 · The attackers obtained remote code execution by exploiting the Chrome zero-day and several recently patched Chrome vulnerabilities. All of the ...
[67]
CVE-2021-38000: Chrome Intents Logic Flaw | 0-days In-the-Wild
The vulnerability is that the intent to an external app should only occur when driven by a user. (This includes when the user has selected "Always" on the ...
[68]
How Google Changed the Secretive Market for the Most Dangerous ...
Sep 23, 2019 · A Project Zero researcher was also part of the group who found the infamous Spectre and Meltdown flaws in Intel chips. These numbers show ...
[69]
About the security content of iOS 12.1.3 - Apple Support
Description: A memory corruption issue was addressed with improved lock state checking. CVE-2019-6205: Ian Beer of Google Project Zero. Kernel. Available for: ...
[70]
About the security content of iOS 14.3 and iPadOS 14.3
Description: An information disclosure issue was addressed with improved state management. CVE-2020-27946: Mateusz Jurczyk of Google Project Zero. FontParser.
[71]
A Look at iMessage in iOS 14 - Google Project Zero
Jan 28, 2021 · This blog post discussed three improvements in iOS 14 affecting iMessage security: the BlastDoor service, resliding of the shared cache, and ...
[72]
Microsoft criticizes Google for 'gotcha' approach to bug disclosure
Jan 12, 2015 · "On balance, Project Zero believes that disclosure deadlines are currently the optimal approach for user security," Google told Engadget.
[73]
Microsoft blasts Google for vulnerability disclosure policy - CSO Online
Google's Project Zero, for the second time in less than a month, disclosed an unpatched privilege escalation flaw in Windows 8.1. The disclosure came 90-days ...
[74]
Microsoft chastises Google for disclosing Windows 8.1 security hole ...
Jan 11, 2015 · Microsoft is publicly criticizing Google for releasing details about a security vulnerability in Windows 8.1 two days before the Redmond ...
[75]
Google updates disclosure policy after Windows, OS X zero-day ...
Feb 13, 2015 · Google updates disclosure policy after Windows, OS X zero-day controversy. A little give has been added to Project Zero's 90-day action deadline ...Missing: criticism | Show results with:criticism<|separator|>
[76]
Google reveals trio of security vulnerabilities in OS X - WeLiveSecurity
Jan 26, 2015 · Google's Project Zero has released information on three as yet unpatched vulnerabilities in Apple's OS X operating system, reports Ars Technica ...
[77]
Google: Vendors took an average of 52 days to fix reported security ...
Feb 11, 2022 · Between 2019 and 2021, Project Zero researchers reported 376 issues to vendors under their 90-day deadline. Of those 376 issues, more than ...<|separator|>
[78]
Google's unusual move to shut down an active counterterrorism ...
Mar 26, 2021 · A decision to shut down exploits being used by "friendly" hackers has caused controversy inside the company's security teams.
[79]
https://googleprojectzero.blogspot.com/2021/03/in-wild-series-october-2020-0-day.html
[80]
Policy and Disclosure: 2020 Edition - Google Project Zero
Jan 7, 2020 · For example, around the time Project Zero started in 2014, some issues were taking upwards of six months to fix.
[81]
Google: Stop Burning Counterterrorism Operations - Michael Coppola
Jun 24, 2024 · This piece refers to an incident involving Google TAG and Project Zero dating back to 2020 and 2021. At the time, these events stirred a ...
[82]
https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html