What AI Search Cited When the *sshole SSH Bug Broke — and What It Snubbed
The *sshole Scramble
A newly disclosed SSH vulnerability in Linux, now going by the nickname sshole, broke across security circles on a Tuesday morning, and by Tuesday afternoon, AI answer engines already had their citation list locked in. Ask ChatGPT, Perplexity, or Gemini what sshole is and how to patch it, and you'll get a tidy answer pointing back to the same small handful of sources — usually the original security researcher's disclosure, a major outlet's writeup, and maybe one vendor advisory.
Meanwhile, the open-source blogging world did what it always does when a vulnerability drops: everyone wrote the recap. Dev blogs, agency newsletters, freelance security writers, company Medium pages — all publishing some version of "what you need to know about *sshole" within hours of each other. Most of that content said roughly the same thing. Most of it also never showed up in a single AI-generated answer.
That gap is the interesting part. It's not that AI tools are lazy or biased toward big names by default. It's that recap content, by its nature, doesn't give an AI model a reason to pick it over the dozen other recaps saying the exact same thing in the exact same order. Something in that stack of sources got treated as authoritative. Everything else got treated as noise.
How Citation Actually Works
What decides which source gets picked isn't a mystery, even if most writers treat it like one. AI answer engines aren't scanning for keyword density the way Google did in 2012. They're looking for specificity — a CVE number, a patch version, a line of config you can copy and run. The original researcher's disclosure had that. It named the exact daemon, the exact vulnerable version range, the exact command to check if you were exposed. A recap blog summarizing "here's what you need to know" in friendly prose has none of that texture, and the model has no reason to treat it as a primary fact.
Structured data matters here too. Pages with clear headers, defined terms, and content that maps cleanly to a specific question get pulled more easily than a wall of narrative text saying the same five facts in different words.
Freshness carries weight, but not the way most people assume. Publishing first doesn't win. Publishing with a visible, verifiable timestamp that shows the information was updated as the story developed does. A post that said "patched version released Wednesday" and updated its own page to reflect that signals something a static recap frozen in Tuesday's panic can't.
Why Most Recaps Vanish
Run the dead recaps side by side and the pattern gets obvious fast. Every single one opens with some version of "a new vulnerability has been discovered," restates what sshole stands for, then walks through the same three bullet points everyone else already walked through. None of them say anything an AI model couldn't already construct from the primary disclosure itself. Why would a citation engine point to the summary when it has the source the summary was summarizing?
The vague-claims problem compounds it. A lot of these posts hedge with lines like "experts recommend patching as soon as possible" without naming the expert, linking the advisory, or specifying which patch. That phrasing might read fine to a human skimming on a Tuesday afternoon, but it gives an answer engine nothing to anchor to. No named source, no version number, no command. Just a confident-sounding sentence with no weight behind it.
Then there's structure. Most recap posts are written as flowing narrative — paragraph, paragraph, paragraph, conclusion — because that's how blog posts have always been written. But an AI model answering "how do I check if I'm vulnerable to sshole" isn't looking to extract meaning from narrative prose. It's looking for the thing that answers that exact question, formatted so it can be lifted cleanly. A recap with no distinct structure and no distinct information is, from the model's perspective, interchangeable with every other recap saying the same thing.
Turning a News Post Into a Source
Turn your own recap into something an answer engine would actually pull, and the fix isn't a rewrite. It's addition.
Name the exact detail. Don't write "the vulnerable SSH daemon." Write which daemon, which version range, and link the researcher's original disclosure directly rather than paraphrasing it from a news outlet that paraphrased it from someone else. If you're citing the patch, name the patched version number and the date it shipped.
Add an FAQ block with direct, isolated answers. "Am I affected by sshole?" gets its own line with its own answer — the command to run, what output means you're exposed, what output means you're clear. Not buried in paragraph four. Structured as its own question-answer unit.
Date your updates visibly, on the page itself, not just in a CMS timestamp nobody sees. "Updated Wednesday: patch released, version X.X" tells a model your page tracked the story instead of freezing it.
Cite your source by name — the researcher, the CVE number, the vendor advisory — instead of "experts say." A named source with a link is something a model can verify and point back to. An unnamed one is just a sentence floating with no anchor underneath it.