google/security-research: Google's Vulnerability Advisories, PoC Exploits, and CTF Programs

What google/security-research Contains and Who Should Use It

The repository publishes security advisories and their accompanying proof-of-concept code for vulnerabilities that Google researchers found in software they do not own. The README is explicit about the scope: 'this project hosts security advisories and their accompanying proof-of-concepts related to research conducted at Google which impact non-Google owned code.'

The audience falls into two categories. Security researchers can use the PoC code and analysis to understand how a vulnerability works and to develop detection methods or defensive measures. Engineers who maintain the affected software can use the advisory text and patches to understand what needs to be fixed. The repository does not serve as a channel for reporting new vulnerabilities to Google or for requesting that Google investigate something specific.

The advisories in this repository are distinct from Google's own product security reports. If a vulnerability affects Chrome, Android, or any other Google product, it is disclosed through Google's own product security channels. This repository is for vulnerabilities in external software that Google researchers encountered during the course of their work.

The 90-Day Disclosure Policy and How It Works

Google adheres to a 90-day disclosure deadline, described in the README and detailed at google.com/about/appsecurity/. When a researcher discovers a vulnerability, the affected vendor receives notification immediately, with full technical details. The 90-day clock starts at the time of notification.

After 90 days, the technical details become public regardless of whether the vendor has released a fix. The policy has a single exception: if the vendor releases a fix before 90 days, the details can be shared sooner. The README states the policy as: 'details shared in public with the defensive community after 90 days, or sooner if the vendor releases a fix.'

This policy reflects a position that vulnerability disclosure is a two-way responsibility. The 90-day window gives vendors a defined period to act, while the guaranteed publication date creates an incentive to prioritize the fix. Advisories that land in this repository have already passed through that process: the vendor has had at least 90 days, and the details are now public.

The practical consequence for engineers is that this repository is a retrospective record, not an early warning system. When an advisory appears here, the vendor has known about the issue for at least 90 days, and a fix may already be available.

Repository Layout: PoCs, CTF Challenges, and Analysis

The top-level directories in the repository organize the content by type and program:

The `pocs/` directory holds proof-of-concept exploit code for published vulnerabilities. Each PoC demonstrates that a vulnerability is exploitable, which helps both researchers verify the issue and defenders test their detection capabilities.

The `analysis/` directory holds analytical work that accompanies some advisories. This may include notes on the vulnerability class, observations about the code pattern that caused the issue, or comparisons with related vulnerabilities.

The `kernelctf/` directory is specific to the kernelCTF program, which focuses on Linux kernel security. The `kvmctf/` directory covers the kvmCTF program, focused on KVM hypervisor security. The `v8ctf/` directory covers the V8CTF program, focused on the V8 JavaScript engine used in Chrome and Node.js.

The CTF directories contain the challenge materials, write-ups, and exploits submitted by participants in these programs. These programs invite external security researchers to find vulnerabilities in the specified targets in exchange for rewards, and the submitted findings are published here after the disclosure process completes.

How to Navigate the Security Advisories

The primary access point for the advisory content is the GitHub Security Advisories interface. The README links directly to the published advisories page at github.com/google/security-research/security/advisories?state=published. This page lists each advisory with its CVE identifier, severity rating, and affected package.

The advisories follow the GitHub Security Advisory format, which includes a description of the vulnerability, affected versions, the patch, and references. Users who want to track new advisories from this repository can watch the repository on GitHub and filter for security advisory events.

The PoC code in `pocs/` is organized alongside its corresponding advisory. The naming convention in the directory structure connects each PoC to the specific CVE or vulnerability it demonstrates. Researchers who want to reproduce a finding should read both the advisory text and the PoC code together, because the advisory describes the vulnerability class and impact while the PoC shows the specific code path that triggers it.

For the CTF-related content in `kernelctf/`, `kvmctf/`, and `v8ctf/`, the directory structure includes information about the program rules, submitted exploits, and awarded rewards. This material is useful for kernel and browser security researchers who want to understand the current state of exploit development for these targets.

The kernelCTF, kvmCTF, and V8CTF Programs

Three subdirectories correspond to active CTF programs that Google runs for specific security-critical targets. These programs are different from the main advisory track: instead of Google researchers finding vulnerabilities and disclosing them to vendors, the CTF programs invite external researchers to find vulnerabilities and submit them to Google in exchange for rewards.

kernelCTF focuses on the Linux kernel. Participants who find an exploitable Linux kernel vulnerability and submit an exploit to the program have their finding included in the `kernelctf/` directory after the disclosure process completes.

kvmCTF focuses on KVM, the Linux kernel-based virtual machine hypervisor. Vulnerabilities that allow a guest to escape the hypervisor or compromise the host are in scope for this program.

V8CTF focuses on the V8 JavaScript engine. V8 runs inside Chrome and Node.js, and vulnerabilities that allow code execution from within a V8 context are in scope. The V8CTF material in this repository includes the exploits submitted by participants.

The existence of these directories alongside the standard vulnerability advisory track means the repository serves two distinct security communities: researchers who work on vulnerability discovery and disclosure, and researchers who participate in structured CTF-style programs with defined targets and reward structures.

What This Repository Does Not Cover

The repository explicitly covers only vulnerabilities in software that Google does not own. Vulnerabilities in Chrome, Android, Gmail, Google Cloud, or any other Google product are not published here. Those follow separate disclosure processes through Google's own product security pages.

The repository is also not a general-purpose CVE database or vulnerability feed. It does not track vulnerabilities discovered by other organizations, even for the same software. A CVE for a Linux kernel vulnerability that was found by a non-Google researcher will not appear here, even if Google has also found related issues.

Contributing new vulnerability research to this repository requires being a Google employee or contractor whose work is covered by Google's research program. The CONTRIBUTING.md states that the easiest way to contribute is to correct patches when you see mistakes, not to add new advisories independently. The channel for external vulnerability reports to Google is the Vulnerability Rewards Program, not this repository.

License, Patch Reuse, and the Role of the Repository

The advisories and patches in this repository are licensed under the Apache License, version 2.0. The Apache 2.0 license permits anyone to use, reproduce, modify, and distribute the advisory text and patches, including in commercial products, provided the license notice is preserved. The `notices.md` file does not exist based on the README, but the LICENSE file at the root applies.

This means that vendors and third-party security tools can incorporate the patches from this repository into their own code or detection tools without a separate license negotiation with Google. A vendor who receives a patch through the advisory process can also find the same patch here and reference it directly.

The repository does not contain vulnerability data in a machine-readable format designed for automated ingestion into security scanners or dependency tools. For automated vulnerability tracking, organizations typically use the National Vulnerability Database (NVD) or GitHub's advisory database, both of which aggregate data from sources including this repository after it is published. The value of this repository for security engineers is the PoC code and analysis, which those aggregated databases do not carry.

Editorial conclusion

google/security-research is the authoritative source for vulnerability disclosures and exploit code that Google's security teams produce for third-party software. Security researchers and engineers responsible for affected software should follow the repository's GitHub Security Advisories page rather than expecting email notification. The repository does not publish vulnerabilities in Google's own software, and it does not serve as a general-purpose vulnerability database. The last push was on 2026-09-25. The Apache-2.0 license applies to the advisories and patches, and the CONTRIBUTING.md describes how to submit corrections to existing entries.

Frequently asked questions

Official sources

1. google/security-research on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README