CVE Content and Disclosure Policy

The CVE Learning Center publishes analysis of real vulnerabilities, quickly, while they still matter. That is useful and it is also the point at which an education platform can do harm, so the boundaries are written down and are the same for every breakdown.

What we publish

• What the vulnerability is, at code level, including the root cause.
• Which versions are affected and which release fixes it.
• Whether it is being exploited, with the evidence and the date of that evidence.
• A detection artifact: a Sigma rule, a Nuclei template, or a concrete log query, written against the behaviour rather than a single payload.
• Remediation, including any workaround that genuinely works, and a note when a suggested workaround does not.
• A named analyst assessment of real exploitability, including where it disagrees with the CVSS base score and why.

What we withhold

• A weaponised exploit for an unpatched vulnerability. No exceptions.
• A working proof of concept before the vendor has published a patch, except where the vendor has demonstrably abandoned the issue and users need to know they are on their own.
• Anything that names or performs reconnaissance on a specific real-world organisation as a target. Statistics about affected populations are fine; a list of vulnerable hosts is not.
• Credentials, keys or data obtained from any incident, in any form, including redacted.

Why the detection rule comes before the exploit

A detection rule helps a defender on the day it is published and helps an attacker not at all. An exploit helps both, and helps the attacker sooner. Where we have to choose which to publish first, we publish detection first, every time. Where a reproduction is genuinely necessary to teach the class, it goes into a sandboxed lab rather than onto a public page.

Reproduction happens in a sandbox

A lab that reproduces a real vulnerability runs on isolated infrastructure with no route to anything real. That is what makes it acceptable to teach a live technique at all, and it is why the lab is the place a reproduction lives rather than a copyable public write-up.

Corrections

Vulnerability analysis published within hours of disclosure is occasionally wrong. When it is, the page carries a dated correction note describing what changed and why, and the correction is not silently edited into the body. The editorial policy sets out the full correction process, which applies here without modification.

If we got something wrong

Vendors, researchers and readers can all reach the analysis team directly. If you are a vendor and a breakdown of your product contains an error or discloses more than this policy allows, tell us and we will correct or withdraw it the same day.