This week’s article is late. I try to keep a weekly rhythm (well, I try), but this one kept growing as I wrote it. The story is evolving faster than I can type.
10 days ago, over on foojay, I wrote a piece called “Did AI Just Break Software Security Forever?” and now I’m writing the follow-on. Since it's deep and complicated, it’s here on Substack and will probably run and run. This article has several links to HeroDevs because that's where part of the story lives. There are links to other sites, too. I believe this is all accurate, but if you have any counterarguments, opinions, or just plain errors, please let me know.
As developers, we’re living a scary story right now, and it’s a complex mix of open and commercial elements along with myths and misunderstandings.
It reminds me of what’s happening with the weather here in the UK right now. We’ve had a brutal stretch of heat, and suddenly everyone is talking about air conditioning. Not fans. Not opening a window or keeping them closed (depending on what you read on the internet). but actual, industrial-grade cooling. Because the occasional hot day you can manage with a fan. Weeks of it, relentlessly, require something built for sustained load.
Vulnerability discovery is going through the same shift. For years, it’s been a craft: a skilled researcher, a specific target, a patient hunt. What’s emerging now is something different. AI-assisted security research is turning a hand-crafted process into an industrialised one. The volume is changing. The pace is changing.
The infrastructure needed to respond is nowhere near keeping up.
The numbers from 2026 alone tell the story.
67 CVEs against Spring components in June: more than the entire Spring ecosystem produced in all of 2025, with March and April alone producing 30 CVEs, nearly double the previous full year.
21 Angular security advisories, 15 of them in a single two-week window between May 28 and June 10.
Ten Apache Tomcat vulnerabilities in a single coordinated April release.
In every case, EOL versions have no fix from the maintainer. In every case, most scanners are running behind the disclosure.
The scale is larger than any single month suggests. The 2026 Sonatype State of the Software Supply Chain report identified 81,000 EOL package versions with known CVEs and no patch. HeroDevs estimates the real number is closer to 400,000 when you account for registries with incomplete EOL tracking and vulnerabilities that were never formally disclosed at all.
This is what AI-assisted security research looks like at volume. And this week gave us a precise, small-scale example of exactly how it works.
Last week, seven security advisories were published against jackson-databind — one of the most widely deployed Java libraries in existence. All seven credited to the same finder. All fixed in the same upstream releases, on the same day. All were published as GitHub advisories on the same day. And as of right now, none of them is in the global GitHub Advisory Database, meaning most scanning tools have no idea they exist yet.
The seven advisories cover a range of severity and impact. Two are critical-level remote code execution, both bypassing the PolymorphicTypeValidator, the security mechanism Jackson introduced specifically to prevent this class of attack.
The HeroDevs blog has a detailed technical breakdown of those two, and individual CVE detail pages for each:
CVE-2026-54512 — RCE via generic type smuggling past
PolymorphicTypeValidatorCVE-2026-54513 — RCE via array component bypass in
BasicPolymorphicTypeValidatorCVE-2026-54514 — SSRF via eager DNS resolution in
InetSocketAddressdeserializationCVE-2026-54515 —
@JsonIgnorePropertiesbypass via case-insensitive deserializationCVE-2026-54516 —
@JsonIgnorebypass via renamed setter and private fieldCVE-2026-54517 —
@JsonViewbypass for setterless creator propertiesCVE-2026-54518 —
@JsonViewbypass for unwrapped creator parameters
Different subsystems. Different mechanisms. Different severity levels. All found at once, in a single research effort, against a single codebase.
That’s not usually how traditional security research works. You find one thing, report it, write it up, move on. Finding seven distinct issues across different parts of a library simultaneously is not unheard of, but it is very rare.
These findings are characteristic of something else. A systematic sweep rather than a targeted hunt. The kind of coverage you get when you step back and use tooling.
I’ve been talking to researchers about how this kind of work gets done now. The short version: capable AI models, with the restrictions that exist to prevent misuse removed for credentialed researchers only, applied to a codebase with a security focus. The model reasons about code the way any senior security engineer would, but it covers ground faster and more comprehensively, and it doesn’t get tired.
Both Anthropic and OpenAI run formal programmes that allow exactly this.
Anthropic’s Cyber Verification Program is a free application-based programme for credentialed security professionals, unlocking dual-use capabilities (including vulnerability exploitation and offensive security tooling) that are blocked by default.
OpenAI’s Trusted Access for Cyber has expanded to thousands of verified defenders, with a dedicated GPT-5.4-Cyber variant fine-tuned to lower the refusal boundary for legitimate security work.
Both programmes are documented, public, and actively expanding. The capability has existed for a while. What’s changing is that the formal infrastructure to use it responsibly is now in place and gaining traction. Seven findings in one library is what that looks like in practice. Expect more like it.
The fixes shipped on June 4th. The GitHub advisories were published on June 16th. As of today, a third party has filed an issue on the GitHub Advisory Database, specifically noting that none of the seven is in the global database yet, and asking: “Is there any special reason for this? Will they be added? Otherwise, many scanning tools will not find these issues.”
That issue is still open.
The CVE IDs do or will exist. The GHSAs exist. The fixes have been in the upstream releases for three weeks. The pipeline that’s supposed to carry this information to the people who need it has stalled somewhere between the project advisories page and the global database.
By default, GHSAs don’t become CVEs. If your scanner tracks GitHub advisories directly, you’re covered. If it relies on NVD (and most enterprise tooling does), you’re waiting on data enrichment that may take weeks or never arrive.
NVD has been running behind since early 2024. The backlog grew from 13,000 unprocessed vulnerabilities to more than 27,000 by the end of 2025, and CVE submissions have increased 263% between 2020 and 2025. A Commerce Department inspector general report published last month found the programme has no sustainable path to clearing it. (See also The Record and NIST.)
For EOL versions, the situation is compounded: CVEs for EOL streams aren’t automatically raised by anyone. Someone has to do that work specifically, and for most abandoned library versions, nobody does. CVEs exist for these particular findings because HeroDevs did both the heavy lifting and the filing work.
Your scanner may not know about any of this yet. So here’s what you actually need to do.
For teams on currently supported Jackson releases: 2.18.x, 2.21.x, 3.x, the answer is simple: upgrade to 2.18.8, 2.21.4, or 3.1.4. All seven issues are fixed. Do it now rather than waiting for your scanner to tell you to.
For teams on EOL Jackson versions: 2.13.x, 2.14.x, 2.15.x, the picture is different. Those streams closed between late 2023 and 2024. The community will not backport fixes.
There is no free patch for any of the seven.
HeroDevs has fixes for the critical-level RCEs in NES for Jackson. If you’re on EOL Spring Boot and can’t easily separate the jackson-databind version from the rest of the framework dependency tree, NES for Spring covers the full stack including jackson-databind.
The EOL situation is the reason this research matters as much as it does.
A researcher sweeping a codebase and finding seven issues simultaneously is good news when you’re on a supported version: you patch and move on.
When you’re on an EOL version, each finding is a vulnerability with no free remedy attached. Documented exposure, no documented fix. That’s the worst position to be in.
If you want the longer argument about what this means for the open source ecosystem and who should be paying for this work the next piece in this series goes into that directly.
If you want to know your EOL exposure, you're welcome to use HeroDevs EOL DataSet tooling to help - it’s the most comprehensive data available.
The libraries that haven’t been examined in years are not, by default, safe. Simply not looking isn’t a safety mechanism. They’re in the same position jackson-databind was in before someone decided to look systematically.
The absence of CVEs was never evidence of safety. It was evidence of silence.
That silence is ending across the entire ecosystem. The tooling exists. The methodology is gaining traction, and the incentives are there: both for good and bad actors.
Security researchers have always been able to find vulnerabilities; what’s changed is the speed and coverage enabled by AI-assisted analysis.
A fan was enough when the occasional hot weather turned up. What’s coming in the world of vulnerabilities requires something built for sustained load, because the approaching heat wave has the potential to irreparably damage the open-source ecosystem.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.