- itscybernews
- Posts
- One AI found bugs no one saw in 25 years. Another used the identical trick to hit 200 companies.
One AI found bugs no one saw in 25 years. Another used the identical trick to hit 200 companies.
Two software projects had very different mornings this year.
One got a stack of pull requests fixing bugs that had been sitting untouched in its code since before some of its own maintainers were born. The patches came from an AI. The project’s leadership thanked it, by name, in an official release note.
The other watched its bug bounty program — running since 2019, a genuine trust exercise between a small open-source team and the security community — collapse under the weight of a different kind of AI output: reports that read like real vulnerabilities and were, for the most part, completely made up.
Both things happened because of the same underlying capability: an AI agent that can read unfamiliar code, spot a real flaw in it, and write a working proof-of-concept, entirely on its own. One story is what that looks like pointed at a defender’s problem. The other, a few months later, is what it looks like pointed at everyone else’s.
🐜 The AI that went 12 for 12
In late January 2026, OpenSSL — the cryptography library that quietly underpins a large share of the encrypted internet — shipped a release crediting all twelve of its fixed security issues to one source: an AI-driven research system built by a company called AISLE.
That’s not “found some bugs a human missed.” That’s the entire release. Every disclosed issue, one source.
The headline numbers, confirmed by OpenSSL’s own release notes and AISLE’s account of the work:
What happened | The number |
|---|---|
Security issues in the January 2026 release | 12 of 12 credited to AISLE |
Findings caught and fixed before they ever shipped in a release | 6 more, on top of the 12 |
AISLE-proposed patches merged as-is into the official fix | 5 of the 12 |
Highest-severity find | CVE-2025-15467, a stack buffer overflow OpenSSL rated High (CVSS 9.8) |
How long the oldest bugs had survived | Three since 1998–2000 — one predates OpenSSL itself, inherited from the original 1990s SSLeay code |
That last line is the one worth sitting with. This is a codebase that has been fuzzed for literal millions of CPU-hours and formally audited, repeatedly, by teams that include Google’s own security engineers. And a quarter-century-old bug was still in there, waiting.
OpenSSL’s CTO, Tomáš Mráz, put it plainly in the release notes:
“This release is fixing 12 security issues, all disclosed to us by AISLE. We appreciate the high quality of the reports and their constructive collaboration.”
Executive director Matt Caswell echoed it, thanking AISLE for “responsible disclosures and the quality of their engagement.”
That word — quality — turns out to be the whole story, because a few weeks earlier, a much smaller open-source project had run face-first into the opposite problem.
One quick word from today’s sponsor
For product teams moving at AI speed.

AI makes it easier to ship anything, even bad ideas. The hard part is knowing which ideas are worth building.
Jira Product Discovery brings your ideas, customer insights, and priorities into one place, so your team can decide what to ship and move forward with confidence.
Capture ideas, prioritize with evidence, and build living roadmaps your team can rally around—all while staying connected to delivery in Jira, so everyone can see what’s being built and why.
Better product decisions in the AI era.
🌀 The same trick, aimed the other way
AISLE’s AI reads code, forms a hypothesis about where it might break, tests that hypothesis, and writes up what it finds — the same four steps a skilled human researcher runs through, just faster and tirelessly. Anthropic’s own threat intelligence team, in a report published this month covering AI misuse between December 2025 and August 2026, described the criminal side of that same capability in granular, uncomfortable detail.
The clearest example: a criminal group Anthropic tracked as GTG-50014, built from affiliates of the ShinyHunters extortion network. Their operators didn’t need to be skilled hackers themselves — they directed an AI agent toward a goal and let it handle the specifics of each target’s environment, a pattern Anthropic’s researchers now just call “vibe hacking.” The AI scanned 1.8 million downloaded Android app packages for hardcoded credentials, then used what it found to work through technology vendors, airlines, energy companies and SaaS platforms. In one documented case, a single stolen access token was escalated into full cloud administrator control in roughly three hours — entirely agent-driven. The campaign reached 200 downstream customer organizations through vendor supply chains, and pulled in over a terabyte of data from a single victim alone, including tens of millions of airline passenger records.
A second group, GTG-10007, pushed the same capability a layer further: instead of just executing an attack, they set AI agents loose to find the vulnerabilities themselves. Anthropic describes an “autonomous exploit foundry” — parallel swarms of agents doing reconnaissance and multi-day binary-reversing loops against roughly 50 organizations, discovering previously unknown flaws and building working exploits against network and security appliances, largely unsupervised, with campaign memory persisting across sessions so the operation didn’t have to restart from scratch each day.
Read those two paragraphs next to the OpenSSL numbers above. It’s the identical skill: read the code, find the flaw, build something that proves it. AISLE pointed it at a cryptography library with the maintainers’ blessing. GTG-50014 and GTG-10007 pointed it at whoever was reachable. Anthropic’s blunt conclusion: “security through obscurity” — the old assumption that your systems are too obscure or too varied for an attacker to bother learning — doesn’t survive contact with an AI that can learn any environment in minutes.
🚨 The other casualty: bug bounty programs are drowning
Here’s the part that doesn’t fit neatly into “AI good” or “AI bad,” and it’s arguably the more immediate problem for anyone running a disclosure program.
On 26 January 2026, curl maintainer Daniel Stenberg ended curl’s bug bounty program outright. It had run since 2019 and paid out $90,000 for 81 genuine vulnerabilities — a program that worked, for years. What killed it wasn’t a lack of interest. It was volume: by Stenberg’s own accounting, roughly 20% of 2025’s submissions were AI-generated “slop” — confident-sounding reports for bugs that didn’t exist — and only about 5% were genuine. Every submission still has to be triaged by an exhausted human before it can be dismissed, and that math stopped working.
The irony is that AISLE’s own reports to curl were part of the small genuine minority: they found 5 real curl CVEs, including 3 of the 6 in the curl 8.18.0 release, and separately reported more than 30 additional issues directly to the maintainers outside the formal bounty. The tooling that quietly saved OpenSSL is the same category of tooling that helped bury curl’s program in noise — the difference wasn’t the AI, it was who was operating it and whether a human reviewed the output before it landed in someone’s inbox.
The Cloud Security Alliance’s research arm has been tracking this exact tension and published a reform proposal worth knowing about even if you never run a bug bounty program yourself: it recommends that any organization submitting AI-found vulnerabilities designate a named human as the “responsible disclosing party,” that bounty platforms require human review before submission (HackerOne already does — the CSA calls it “a reasonable baseline” that most platforms haven’t adopted), and that defenders stop drowning in raw CVE counts and instead triage using tools like EPSS scores and CISA’s Known Exploited Vulnerabilities list, because the actual number of bugs worth urgently patching has stayed roughly flat even as the number of reported bugs has exploded.
🛡️ What actually helps
None of the above is a reason to panic, and none of it is a reason to unplug your AI coding tools either — the OpenSSL story is proof the same capability is a genuine net positive when it’s aimed deliberately and reviewed properly. A few concrete things, straight out of the threat intel and the disclosure-reform research, actually move the needle:
Treat AI API keys like production database credentials, because attackers already do. Anthropic’s report notes criminal groups explicitly targeting AI vendors’ own sandboxes to steal keys — treat any exposed key in a repo, container, or config file as an active incident, not a cleanup task.
Move detection from signatures to behavior. Content-based phishing filters and static malware signatures are built for attacks a human wrote by hand. An AI-driven attack doesn’t repeat itself the same way twice; anomalous behavior — a login from a new pattern, a vendor account suddenly acting differently — catches what content filters miss.
If you ship AI-assisted vulnerability research, put a named human’s name on it before it goes anywhere. One accountable person reviewing output before submission is the single biggest difference between AISLE’s reputation and curl’s inbox problem.
Triage by exploitability, not by report count. A CVE count that’s tripled since 2020 doesn’t mean triple the urgent work — EPSS scoring and CISA’s KEV catalog tell you which of the pile is actually being exploited right now.
The bigger pattern underneath all of it: the gap between “skilled attacker” and “anyone with an agent and bad intentions” is closing fast, and so is the gap between “skilled defender” and “anyone willing to run the same tooling responsibly.” Which side of that gets faster in your organization is mostly a matter of who’s actually reviewing the output — human or otherwise.
Reply and tell me if your team has run an AI agent against your own codebase yet — genuinely curious how many of you have already had your own AISLE moment, good or bad.
📚 Sources — every figure above, checked at source
Claim | Source |
|---|---|
AISLE credited with all 12 OpenSSL security issues in the January 2026 release, plus 6 pre-release catches, 5 merged patches, CVE-2025-15467 detail, the three 25+ year-old bugs, the Mráz and Caswell quotes | AISLE — “AISLE Discovered 12 out of 12 OpenSSL Vulnerabilities” and Security Boulevard — “AI Found Twelve New Vulnerabilities in OpenSSL” |
curl bug bounty ended 26 January 2026 after running since 2019, $90,000 paid for 81 genuine vulnerabilities, ~20% AI-slop submissions in 2025 with ~5% genuine, AISLE’s 5 genuine curl CVEs (3 of 6 in curl 8.18.0) and 30+ additional reports | LessWrong — “AI found 12 of 12 OpenSSL zero-days (while curl cancelled its bug bounty)” |
GTG-50014 (“vibe hacking,” ShinyHunters-affiliated): 1.8 million Android APKs scanned for credentials, 200 downstream organizations reached, one token-to-cloud-admin escalation in ~3 hours, 1+ terabyte exfiltrated from one victim, tens of millions of airline records | |
GTG-10007 (“autonomous exploit foundry”): ~50 organizations targeted, parallel agent swarms, previously-unknown vulnerabilities found and exploited against network/security appliances, persistent cross-session memory | |
CSA reform proposal: named human as “responsible disclosing party,” HackerOne’s human-review baseline, EPSS/CISA KEV-based triage over raw CVE counts |
Not printed, because it couldn’t be confirmed at a primary source: a bug-bounty-platform pseudonym reportedly used for some of AISLE’s submissions, mentioned in one secondary summary but not in AISLE’s own or OpenSSL’s published material — left out rather than repeated as fact.
