Security advisories

How we choose what to publish

There were more than 40,000 CVEs published last year. Almost none of them matter to someone running a Linux server, and a feed that repeats all of them is noise. We publish a vulnerability only when it clears a gate that runs on every ingest:

• Confirmed exploitation. Listed in CISA’s Known Exploited Vulnerabilities catalogue, or carrying an EPSS score high enough to expect opportunistic scanning. EPSS models the probability of exploitation in the next 30 days, and it predicts real-world attack far better than severity alone does.
• Reachable and unauthenticated. We read the CVSS vector rather than the headline: network attack vector, no privileges, no user interaction. That combination is what automated botnet scanning sweeps up within days of a public exploit.
• Server-relevant. Software people actually run on a VPS. A flaw in a desktop application is not our readers’ problem, however severe it scores.

Where the fix versions come from

Every version number on this site is looked up from OSV.dev and the GitHub Advisory Database, then rendered from that record — never written as prose. A wrong upgrade command in a security advisory is worse than no advisory at all, so the remediation table and the article text come from different places by design. Where no fixed version has been published yet, we say so rather than guessing.

What we deliberately leave out

No exploit code, no proof-of-concept, and no detail sufficient to reproduce an attack. We describe where a flaw lives, because that is what lets you judge your own exposure, and we stop there. Our readers are the people patching these systems, not the people scanning for them.