Contribute

vuln.fail is community-driven. If you've found or heard of a newly disclosed Linux kernel vulnerability, open a pull request on Codeberg.

What to add

• A clear, technical description: one or two sentences on what the bug is and what an attacker can do with it
• A complete timeline from first report to public disclosure, with every event sourced
• A [extra.fixed] section as soon as a patch lands, even if no release is out yet
• Mitigation steps if any exist, with commands that actually work

Not all fields are required. In fact, a title, description and disclosure date are enough.

Updating an existing issue

If you notice any outdated or outright wrong information, please don't hesitate to fix it and send a pull request.

You can keep track of these things for existing issues:

• Add stable releases to releases = [...] as they are backported
• Add mainline = "x.y" once the fix is tagged in a mainline release
• Update the timeline with disclosure and patch dates
• Add e.g. the mailing list as a source for these backports

Sources

Every claim should be backed up by a source. Use [[extra.sources]] with short keys and reference them from timeline events and mitigation steps with sources = ["key"]. Avoid linking to GitHub issues or articles as primary sources.

Commit messages

Use the format scope: action. The scope is the path relative to content/ without the extension, and the action is a short phrase:

issues/copy-fail: add
issues/ssh-keysign-pwn: add fixed stable versions
issues/dirty-frag: document mitigations

The change history of an issue is transparently shown at the bottom of the page.

For changes that aren't tied to a single issue, use a relevant short description without a scope prefix.

Adding a new vulnerability

Create a file at content/issues/vulnerability-name.md. This should preferably use the common name of the vulnerability (e.g. copy-fail), if one exists.

Required fields

+++
title = "Name of the vulnerability"
date = 2026-01-01 # public disclosure date
description = "1-2 sentence summary shown in listings, the feed and if the issue doesn't have a detailed description."
+++

Optional fields

[extra]
site = "https://..." # PoC repo or dedicated site

[[extra.cve]]
id = "CVE-YYYY-NNNNN"
score = 7.8 # CVSS base score, omit if not yet assigned

# repeat for each CVE
[[extra.cve]]
id = "CVE-YYYY-NNNNN"

[[extra.author]]
name = "John Doe"
url = "https://..." # optional

# repeat for each author
[[extra.author]]
name = "Jane Doe"

[extra.introduced]
commit = "72548b093ee38a6d4f2a19e6ef1948ae05c181f7" # full hash

[extra.fixed]
url = "https://lore.kernel.org/..." # link to patch, if not yet merged
label = "mailing list"              # required with url, display label for the link
commit = "abc123..."                # full patch commit hash
mainline = "6.19"                   # mainline release the fix landed in
releases = ["6.18.1", "6.12.5"]     # stable backport releases

# shell snippet to check if affected
[extra.check]
code = "uname -r"
note = "Optional explanation of the output"

[[extra.timeline]]
date = "2026-01-01"
text = "Event description, supports `inline markdown`"
sources = ["key"]

[[extra.mitigation]]
title = "Optional step title"
text = "Description of the step."
code = """
optional shell snippet
can be multiline
"""
sources = ["key"]

[extra.sources.fix]
url = "https://git.kernel.org/..."

[extra.sources.poc]
url = "https://example.com/..."