Using AI to Discover Silently Patched Vulnerabilities in Open Source

Using AI to Discover Silently Patched Vulnerabilities in Open Source

Speaker: Mackenzie Jackson

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~8 minutes

TL;DR

Mackenzie Jackson of Aikido Security described research that used LLMs to monitor open-source changelogs at scale, discovering 550 undisclosed vulnerabilities in 2024 — 67% of which never received a CVE. The same AI-powered approach has since been extended to malware detection, where it identified 611 malicious npm packages in March alone and caught a backdoor in the official Ripple XRP SDK within minutes of its introduction.

Introduction

Approximately 85% of the code running in any modern application was not written by the team shipping it. It comes from open-source dependencies, and those dependencies have dependencies, which have their own dependencies, cascading down as many as thirty layers. At some point in that graph there is almost certainly a component that nobody on the development team has thought about since they ran npm install two years ago.

Security teams have built their supply chain risk programs around the assumption that when a vulnerability exists in one of those components, it will be publicly reported — assigned a CVE number, added to the National Vulnerability Database, and picked up by the SCA tools that scan dependency trees. Jackson's research at Aikido Security tested that assumption directly. The results were unsettling.

His talk — billed under the title "Shadow Patching" (his preferred rebranding of the more common term "silent patching") — described how LLMs can be used to find the vulnerabilities that maintainers know about, quietly fix, and never report.

The Open-Source Supply Chain Problem

▶ Watch: Log4j, the Nebraska Problem, and how supply chain dependencies work (03:30)

Jackson opened with the canonical examples most practitioners know: Log4j's catastrophic 2021 disclosure, the XZ Utils backdoor that came within a commit of compromising SSH access across a large portion of the internet's infrastructure, and the ua-parser-js npm package that was sold for $20,000 on a Russian dark web forum and injected with cryptocurrency mining and credential-stealing code.

These cases share a structural feature: the existence of a vulnerability in a widely-used dependency that cascades through every application using that dependency, often invisibly. The meme about a critical internet component maintained by a single volunteer in Nebraska — "we are so close," as Jackson put it — describes something that is more documentation of reality than hyperbole. Veracode's 2023 study found that two years after the Log4j disclosure, 30% of applications were still running the vulnerable version.

The current detection model relies entirely on public reporting: vulnerability found, CVE assigned, NVD updated, SCA tool flags affected versions. It only works when vulnerabilities are disclosed. Jackson's central question: how many are not?

The Shadow Patching Research: Architecture and Results

▶ Watch: The Intel threat feed — LLM architecture for changelog monitoring (14:00)

Aikido built a system called Intel — an open-source threat feed on GitHub — that monitors the changelogs of the five million most popular open-source packages. The pipeline works in layers:

1. Collection: Scrapers gather changelog data from across the web. Changelogs have no standard format and are not in any standard location — some live on GitHub, some on project websites, some elsewhere entirely. Three different changelogs for popular projects shown in the talk used three entirely different formats and locations.

1. Standardization: A first LLM reformats all collected changelogs into a standardized representation so that downstream scanning can operate consistently.

1. Vulnerability detection: A second LLM model identifies language in the standardized changelogs that suggests a security vulnerability was fixed, even when the language is deliberately ambiguous.

1. Cross-checking: Identified candidates are automatically cross-referenced against multiple vulnerability databases including the NVD, GitHub Advisory, and others to determine whether a CVE has been assigned.

1. Human verification: A security engineer reviews flagged items. This step was especially important in the early stages because its outputs fed back into model training, progressively improving precision over time.

The decision to use OpenAI's commercial models rather than a custom-built model was deliberate. Jackson noted that building and maintaining a custom model means the moment it is complete, a newer commercial model has already outperformed it on most tasks. Commercial models deliver ongoing performance improvements for free; a custom model requires continuous investment to keep pace.

▶ Watch: 2024 research findings — 550 vulnerabilities, 67% never disclosed (21:45)

The 2024 results: 550 undisclosed vulnerabilities found across the monitored package set. Of those, 61 were rated critical severity and 113 were rated high. In just the first two months of 2025, the system found 126 — partly reflecting improved model performance and partly reflecting a world that is, as Jackson put it, "kind of chaotic."

The most alarming finding: 67% of the discovered vulnerabilities were never disclosed — never received a CVE. That figure held even at the critical end of the severity range, where 56% of critical vulnerabilities were never reported. Among specific examples: Axios, the promise-based HTTP client with 56 million weekly downloads, had a 77/100 high-severity vulnerability discovered and patched by maintainers in January 2024 — with no CVE assigned as of the talk. Apache ECharts had a cross-site scripting vulnerability (nearly high severity) in a package with nearly a million weekly downloads, discovered in March 2024, still without a CVE. A critical path traversal vulnerability in the Concrete CMS composer package, with millions of downloads, also lacked a CVE.

Why LLMs Are Necessary for This Problem

▶ Watch: Why traditional rules fail — ambiguous security language in changelogs (27:30)

Jackson addressed the natural question directly: if the data being analyzed is public, why not use traditional pattern-matching rules instead of LLMs?

The answer is the ambiguity of the language used to describe security fixes, especially when maintainers are not trying to announce that they have a vulnerability. At one end of the spectrum, a changelog might say "escape select text to avoid cross-site scripting exploit" — unambiguous, detectable with a rule. At the other end, a changelog might say something like "increased default work factor to N iterations to improve resistance to brute-force attacks" — technically describing a security improvement, but requiring both security domain knowledge and contextual reasoning to recognize as a vulnerability disclosure. Writing rules to catch every variation of ambiguous security language across five million packages in multiple natural languages, with no standard format, is not tractable. LLMs handle the ambiguity naturally.

Malware Detection: The Extended System

▶ Watch: Malware detection launch — LLM-as-orchestrator and North Korean APT findings (33:00)

The same architectural philosophy has been applied to malware detection. Here, the LLM's role is different: rather than identifying vulnerabilities from changelog language, it acts as a triage orchestrator. Traditional scanning tools evaluate npm packages against 30-plus indicators for malicious behavior; the LLM reviews indicator combinations and makes a determination about whether to escalate to a human reviewer. False positive rate: under 5%.

In March 2025, the system found 611 malicious npm packages. Average time to detection: 5 minutes. By comparison, the OpenSSF Foundation's benchmark for this class of detection is 10 days.

Two specific cases Jackson described in detail:

Lazarus Group's React HTML to PDF package. A malicious npm package was reported to Aikido, but initial inspection of the visible code showed nothing suspicious. The tell: the horizontal scroll bar. Code had been horizontally indented far enough that the malicious portion was hidden off-screen. Unscrolling revealed a function that made a call to an external domain, received a payload, and then executed a suite of actions: searching for browser cryptocurrency wallet extensions, stealing credentials, and establishing persistence through a backdoor installer. Jackson's team noticed three successive versions of the package being published ten minutes apart during their investigation — they were watching the Lazarus Group debug their malware in real time.

The Ripple XRP SDK. In the week before the talk, Aikido detected a backdoor in XRPPL — the official Ripple XRP Foundation SDK used by developers to communicate with the Ripple ledger. Exchanges including Coinbase and Binance were among the potential users. The attack vector: a developer's npm token had been compromised, bypassing the project's GitHub CI/CD pipeline by publishing directly to npm. The payload extracted private keys — not just for Ripple but for all private keys accessible on the compromised system. Aikido's detection came within minutes of the malicious version being published. The reporting went viral. Jackson's recommendation: sign releases so that publishing requires passing through the official pipeline, preventing token-compromise attacks from being sufficient on their own.

Notable Quotes

"67% of vulnerabilities we found were never disclosed. That applies even to critical vulnerabilities — 56% of the critical ones were never reported." — Mackenzie Jackson (▶ 23:10)

"We now have to assume that all of these projects have also been found by the bad guys. They can use this exact same approach." — Mackenzie Jackson (▶ 29:45)

"Be careful making the decision to use your own model. From our experience, by the time you build it and update it, it's already outdated." — Mackenzie Jackson (▶ 20:30)

Key Takeaways

• The CVE system has a recall problem. 67% of vulnerabilities found by Aikido's LLM-based monitoring were never reported to any public database — meaning SCA tools scanning for known CVEs would have missed them entirely.
• Ambiguity is what makes LLMs necessary. Maintainers who fix a vulnerability without announcing it use language that evades rule-based detection. LLMs handle this ambiguity in a way that traditional pattern matching cannot.
• Commercial models outperform custom models for this use case. The free performance improvements delivered by OpenAI's ongoing model development exceed what most teams can achieve maintaining a custom model.
• AI-powered malware detection at scale is real and fast. 611 malicious npm packages found in a single month, with a 5-minute average detection time — roughly 3,000× faster than the OpenSSF Foundation benchmark of 10 days.
• Sign your releases. The Ripple XRP SDK compromise succeeded because a compromised npm token was sufficient to publish a new package version without passing through the CI/CD pipeline. Signed releases eliminate this attack path.