google/security-research: advisories, PoCs and the CTF targets behind them

What google/security-research actually publishes

The README states the scope in one line: the project hosts security advisories and their accompanying proof-of-concepts for research conducted at Google that affects non-Google owned code. That last clause matters. This is not a place where Google documents bugs in Google products. It is where Google documents bugs it found in software other people maintain, which is why the advisory text is written for the vendor and the defensive community rather than for a product team.

The repository layout reflects that split. There is a pocs/ directory for proof-of-concept code, an analysis/ directory for write-ups, and three competition directories: kernelctf/, kvmctf/ and v8ctf/. The advisories themselves are not markdown files in the tree. The README points readers to the Security Advisories page on GitHub, where published advisories are browsed as GitHub security advisories. So the repository is two things at once: a code archive and a pointer to a separate advisory feed.

Who it is for follows from that. Kernel and hypervisor engineers who need to understand a specific class of memory-safety bug, exploit developers working the CTF targets, and anyone who wants to read a PoC rather than a summary. It is not written for someone who wants a tool to run against their own codebase.

The 90-day clock and how disclosure is sequenced

The README describes the policy plainly: Google notifies vendors of vulnerabilities immediately, with details shared publicly with the defensive community after 90 days, or sooner if the vendor releases a fix. The full policy lives at the App Security page linked from the README, and the repository does not restate it.

That single sentence explains the shape of everything published here. An advisory can appear before a patch exists, because the deadline is a ceiling rather than a condition. A reader who finds a PoC in pocs/ and assumes a fix is available is making an assumption the documentation does not support. The README does not document rollback, does not describe how to check patch status per advisory, and does not list which advisories shipped with a vendor fix and which did not. That information has to come from the advisory entry itself.

The trade-off is deliberate and worth naming. A fixed 90-day window gives defenders predictable timing and gives vendors a hard boundary, but it also means publication is a calendar event, not a quality gate. If you are the person deciding whether to deploy a mitigation, the date an advisory appears tells you when Google stopped waiting, not when the bug stopped being exploitable.

kernelctf, kvmctf and v8ctf: the reward targets in the tree

Three of the top-level directories are competition infrastructure rather than one-off research. kernelctf targets the Linux kernel, kvmctf targets KVM, and v8ctf targets V8. They sit alongside pocs/ and analysis/, which suggests the shared machinery is the same: a target definition, the exploit that defeats it, and a write-up.

The presence of these directories changes who the repository is useful to. A CTF participant needs the target build and the rules that define a valid submission.

What the README does not do is explain any of this. There is no section describing how a submission is judged, what the reward is, or how the three CTFs differ in rules. The README covers the disclosure policy and the licence and stops there. Anyone arriving for the competitions has to read the directories themselves, and the repository gives no entry point for that. This is the thinnest part of the documentation and the most likely place for a newcomer to get stuck.

Cloning the repository and reading a PoC

There is no package to install and no release artifact. The README gives no install steps, so the only way in is to clone the repository and read it. The .gitmodules file at the top level indicates submodules, so a plain clone may leave directory contents empty until submodules are initialised.

git clone https://github.com/google/security-research.git
cd security-research
git submodule update --init --recursive

After that, the top-level directories are present: analysis/, kernelctf/, kvmctf/, pocs/ and v8ctf/. Expect the proof-of-concept code to be C, which matches the repository's primary language. Building any individual PoC is a per-directory task and the README does not describe a shared build system, so read the files in the directory you care about before assuming a single command compiles everything.

The advisory text is not in the tree. Browse it on the Security Advisories page linked from the README, where published advisories are listed.

Where this repository is the wrong tool

The most common mistake is treating it as a vulnerability feed for your own dependencies. It is not. The advisories cover issues Google researched in non-Google code, and the README describes no mechanism for subscribing to a specific vendor or package. If you need to know whether your kernel build is affected, the advisory entry is the starting point, not the answer.

A second mismatch is expecting maintained code. The PoCs exist to demonstrate a bug. Nothing in the README claims they are updated, portable or safe to run outside a controlled environment. Running exploit code from a research archive on a production host is not what it is for, and the repository offers no guidance on sandboxing it.

Third, the licence is permissive but that says nothing about the code's fitness. Apache-2.0 covers the advisories and patches, and the README notes that the material posted here is free and open source. A permissive licence on an exploit is not a statement that the exploit is correct on your kernel version, your hypervisor build or your V8 revision. The repository gives no compatibility matrix, and the README is silent on which upstream versions each PoC was validated against.

How it compares with a CVE feed or a vendor security page

The obvious alternative is a CVE database or a distribution's security tracker. Those are built around identifiers and affected-version ranges, and their job is to tell you whether a given package version is vulnerable. google/security-research is built around research artifacts: the advisory plus the code that demonstrates it. The difference in approach is that a CVE entry tells you a bug exists and a tracker tells you whether you have it, while this repository shows you how the bug works. Neither replaces the other, and for patch triage the tracker is the tool you want.

A second comparison is a vendor's own security advisories. Those are written by the party that shipped the fix and usually link the patch. Here the publisher is the researcher, and the README makes clear that publication can precede a fix by design. If your workflow requires a patch link before you act, a vendor advisory page is the safer primary source and this repository is the corroborating detail.

What this repository has that neither alternative offers is the CTF directories. kernelctf, kvmctf and v8ctf are not mirrored in a CVE feed.

Licence, contribution and what it costs to keep up

The repository is Apache-2.0. The README says the advisories and patches posted here are free and open source and points to the LICENSE file for details, and it also mentions patents in the same heading, though the README body does not expand on patent terms. If you plan to reuse PoC code inside a product, read LICENSE and, where relevant, the patent grant rather than assuming the permissive label covers everything. That is a reading task, not a legal conclusion.

Maintenance cost is low if you are a consumer. The last push to the default branch was on 2026-10-30, so the repository is current, and the README describes no upgrade path because there is nothing to upgrade. You pull the branch and read it. There is no versioning scheme, no changelog and no published releases, which means you cannot pin a revision by release tag and should record the commit hash you read if you cite a PoC.

Contributing is narrow. The README says the easiest way to contribute is to correct patches when you see mistakes, and it points to CONTRIBUTING.md for the policy. It does not invite advisory submissions or new research from outside, so treat this as a place to send fixes to existing artifacts rather than a venue for your own findings.

Editorial conclusion

Adopt this repository as a reading and reference source if you triage Linux kernel, KVM or V8 bugs, or if you are preparing a kernelctf, kvmctf or v8ctf submission and need the target definitions and the disclosure timeline Google works to. Do not adopt it if you want a scanner, a patched library or a supported API: there is no package to install, the repository has no published releases, and the code exists to demonstrate a bug rather than to be depended on. Before relying on any single advisory, open its entry on the Security Advisories page and check whether a vendor fix is linked, because the 90-day deadline can publish details before a patch ships.

Frequently asked questions

Official sources

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