Finding Critical Infrastructure Bugs with Off-the-Shelf AI

1. Executive Summary

News about AI models finding thousands of vulnerabilities are now commonplace. One of the biggest examples of AI-discovered vulnerabilities this year was PHP2Shell, which made many security teams hurry to patch vulnerable websites comprising large chunks of the internet.

Most of these findings are based on access to three items that are not always available to attackers or to some defenders:

• Cooperative frontier models, such as the latest models from OpenAI or Anthropic without guardrails refusing to perform certain tasks. Since access to these models and guardrail levels are controlled by the AI labs, attackers cannot count on using the latest and greatest, while defenders need to be approved first.
• A sizeable budget to run those models. The costs of AI analysis to find security vulnerabilities can quickly escalate out of the reach of what many cybercriminals would be willing to pay. Defenders do not have unlimited security budgets. At the same time, attackers are usually not interested in finding every possible security weakness on a target but rather finding at least one that is exploitable – possibly with the lowest reasonable cost.
• The source code of targets. AI-assisted vulnerability research works very well on source code, but this is not always available for attackers, especially if they would target embedded equipment, such as network edge devices or those used in critical infrastructure. As we showed previously, exploiting low-level embedded software without having source code is still more difficult for AI.

So, in this research, we set out to answer whether security researchers – and attackers alike – could use generally available models with a limited budget to find vulnerabilities both in open-source targets and binaries that are relevant to critical infrastructure.

To do so, we built our own AI harness specialized for embedded software – including reverse engineering, security analysis and dynamic emulation – and found 66 new vulnerabilities affecting software we had analyzed in the past as part of Project Memoria and some new similar ones. Fifty-four (54) of these findings were reported to vendors and project maintainers: 20 affecting open-source TCP/IP stacks , and 34 affecting proprietary stacks (only five have been fixed to date).

Project Memoria was large-scale vulnerability research against embedded TCP/IP stacks – the foundational software components connecting every device to a network. That project started in 2020, took 18 months and uncovered almost 100 CVEs in 14 stacks used by embedded devices of dozens of vendors. At that time, vulnerability research was largely a manual task performed by seasoned security researchers, sometimes with the help of static analysis or fuzzing tools.

Now, we repeated the project using the new capabilities provided by AI and compared the results with the manual effort of six years ago. These results are summarized in the table below.

It’s easy to see the speed difference: AI cut the analysis time from 9 months to 90 hours. But the cost difference is even more striking: the $1,200 to $2,300 of model spend for this study is likely 100x less than the cost of a senior vulnerability researcher working on manual code analysis.

This comparison does not include the effort to design the AI harness, develop, and refine static analysis rules, build the emulation infrastructure, and refine prompts until the agents behaved consistently. The reported cost is the marginal cost of applying the completed harness to new targets.

This means that once someone has access to a system that can find this type of vulnerability – whether it’s a frontier model or a harness developed for that purpose – they can do so quickly and cheaply. That goes for both attackers and defenders, and it has several implications for device manufacturers and asset owners alike, which we explore at the end of this report. But the main lesson from the study is summarized below.

This research uncovered 99 vulnerabilities in 90 hours including automated analysis and human validation. As model capability improves, both the time and human effort required are likely to fall. Defensive operations that depend on human approval for every action may struggle to keep pace if offensive systems become able to run similar workflows across many targets in parallel.

Forescout’s Assume Autonomy framework addresses this directly: organizations should define now, before the threat matures, which defensive responses they are prepared to delegate, under what operational constraints, and with what ability to reverse automated actions. The challenge is not simply whether to trust autonomous defense, but how to make that trust constrained, observable, and verifiable.

2. Methodology

2.1. Why We Built a Harness

In the past year, the cybersecurity community developed several open AI security harnesses that combine LLM agents, traditional tools, specialized prompts, and reusable skills for vulnerability discovery.

We first tried to apply these existing harnesses to our TCP/IP stack targets, but that yielded few meaningful results, since these harnesses had three limitations:

• Some are fully AI-driven rather than AI-assisted. While it’s tempting to let an AI agent decide what to do and which tools to use autonomously, that can quickly escalate costs and lead to entirely non-deterministic results or dead ends. We needed more control over the analysis. Static analysis tools produce deterministic findings but are usually tuned to flag most mistakes as potential vulnerabilities, making them prone to false positive findings. This is exactly where AI can help, by reasoning over the initial findings of static analysis. Harnesses like RAPTOR, OpenAnt, VVAH, ai-deep-sast, and deepsec use static analysis to discover an initial set of candidate vulnerabilities via third-party tools, simple regular expressions, or their own lightweight data- and control-flow analysis.
• Most only support scanning source code. To analyze embedded software, we need to examine binary artifacts. Several of the open harnesses do not support that, in some cases even focusing on source code analysis only for web applications. Supporting binary analysis is challenging for several reasons:
  • It may be impossible to break down monolithic firmware images into individual binaries or functional components, thus increasing the search space.
  • Binaries are often stripped of function and variable names, making it much harder to find relevant functionality and reason about its implementation.
  • Binaries for different CPU architectures produce different disassembly code. Static analysis rules that work against source code or one architecture may not be suitable for another one. We need an intermediate representation to support both source code and binary analysis.
• Most lack dynamic analysis. Only RAPTOR, Defending Code Harness, and OpenAnt support dynamic analysis to generate proof-of-concept exploits and eliminate false positives. However, dynamic analysis for binary targets is also much more difficult since the harness needs to run on a virtual machine a software image designed for embedded hardware. This means that CPU support and third-party drivers may be missing.

Therefore, we decided to build a harness suitable for our research domains – embedded devices, firmware, and network protocols – encoding the knowledge accumulated over years of research within these domains.

2.2. Building the Harness

Inspired by RAPTOR, OpenAnt, and Defending Code Harness, we built the harness depicted and described below, mixing deterministic and AI-driven steps.

Stage 0: AI-driven target examination

An AI agent examines binary targets to prepare them for analysis. The agent performs several preparatory actions:

• Determines the kind of artifact being analyzed, such as firmware with filesystem and individual binaries or monolithic binary blobs.
• Collects architecture markers, pointer patterns, entropy, and strings to identify the target architecture, endianness, and load address.
• For stripped code – binaries without debug symbols – it identifies the boundaries of the functionality we wish to analyze (such as TCP/IP stacks) and generates function and variable names using various common heuristics, such as analyzing the original names of functions logged when an assertion is hit.
• Identifies libc functions or equivalents such as memcpy(), memmove(), malloc(), and string handling functions.
• Uses Ghidra to convert binaries to a common intermediate representation understood by the different static analysis tools.

Stage 1: deterministic vulnerability discovery

Deterministic static analysis tools find specific categories of vulnerabilities, which enables stable coverage and makes the process measurable and repeatable. We used Semgrep for lightweight source code analysis and Joern for more complex data- and control-flow analyses. Joern uses a code property graph (CPG) as its own intermediate representation and supports translating bytecode disassembly produced by Ghidra into a CPG. This enables us to use the same static analysis ruleset for source code and binaries.

Stage 2: reachability analysis

Multiple agents examine groups of findings to statically determine whether the potential vulnerable code fragments can be reached with attacker input. This stage enables initial pruning of false positives, while the remaining findings undergo a deeper – and more expensive – AI reasoning.

Stage 3: vulnerability checker

AI agents statically determine whether the remaining findings are exploitable vulnerabilities. Using static analysis rules that favor recall combined with AI-driven reasoning significantly increases the precision of the static analysis, while keeping the LLM-related costs relatively low.

Stage 4: dynamic verification

While the previous stages are fully automated, this stage is implemented as skills that allow the researcher to intervene and guide the dynamic analysis as needed. Here, AI determines how to build (or emulate) the target software or firmware and then runs it. After the target is live, for each potential finding, an AI agent attempts to generate a proof-of-concept script that triggers the statically found vulnerability. If the issue can be triggered, a vulnerability is confirmed and a report is generated. Otherwise, it is discarded. This stage can also find new vulnerabilities, not present initially among the results of the static analysis.

2.3. AI Models and Static Analysis Rules

With the architecture of the harness in place, we had to work on two main components to make it functional: AI models and a set of static analysis rules.

For the AI models, we used the Claude family due to their superior performance in our earlier evaluations and its not-too-restrictive guardrails. For the first three stages, we used faster and cheaper models, such as Sonnet 4.6 with high and max reasoning. For dynamic verification, we used Opus versions between 4.6 and 5 because of their extended reasoning and exploitation capabilities. When using older models, we rarely faced the guardrail restrictions we saw on more recent ones.

For static analysis, we implemented 32 Joern rules to identify memory corruption and protocol parsing issues commonly found in embedded TCP/IP stacks. The rules were designed based on implementation anti-patterns that we previously identified in Project Memoria, such as RFC violations, inconsistent message parsing, unsafe handling of protocol fields, and subtle logical errors. The implemented rules are the following:

These rules were implemented with the help of AI. We gave Claude all artifacts produced during our earlier research – including vulnerability reports, proof-of-concept exploits, static analysis rules, protocol specifications, and technical write-ups – and asked it to generate rules that were then manually reviewed. The generated rules are implementation-agnostic, using standard integer types and CPG operators, rather than vendor function names. This process required several iterations. Indeed, a robust rule set is paramount to obtaining reliable results because the first stage is the main bottleneck in this harness: a missing or ineffective rule could result in false negatives.

3. Main Findings

We selected ten TCP/IP stack targets to run our harness against: seven from Project Memoria and a separate similar study from other researchers – a collection we call ‘Project Memoria+’ – and three new stacks.

The table below details these stacks and analyzed versions. The vulnerable versions of open-source implementations were readily available. To obtain closed-source implementations we downloaded suitable third-party firmware or demo binaries. The responsible disclosure process is still ongoing for three stacks, so we call them S1, S2, and S3 in the table and the remainder of this report.

 

Across these stacks, we evaluated the following success criteria:

• The harness can find the vulnerabilities we previously found manually.
• The harness can find new vulnerabilities, including variants of the previous ones.
• The harness is cost-effective, ensuring we do not spend an unrealistic number of tokens (and money).

3.1. Old and New Vulnerabilities

Out of the 82 vulnerabilities in Project Memoria+, the harness rediscovered 33 (40%). It also found 66 new vulnerabilities either missed in the original analysis or affecting the previously unanalyzed stacks. The figure below shows the distribution of all 99 bugs discovered by the harness per category.

This shows how the harness is good at finding memory safety bugs in protocol parsing code but misses logic and design bugs, such as Initial Sequence Number (ISN) predictability, bad Pseudo-Random Number Generation (PRNG), DNS cache poisoning, and TCP state machine issues. This is expected because we used static analysis rules focused on generic code patterns rather than specific implementations. Memory safety issues are more amenable to these static analysis rules, while logic bugs are implementation-specific and much harder to capture with a reasonable tradeoff between false positives and false negatives. The logic bugs that were found were byproducts of the analysis. These byproducts happened when the AI model was statically reasoning about the reachability of a finding or dynamically validating another one and it discovered new bugs adjacent to what was being analyzed.

Out of the 66 new findings, we reported 54 to the respective stack vendors or project maintainers because we believed they still affected latest versions of their products. These findings are broken down per stack and fix status below.

 

Most of these new vulnerabilities are either high or critical severity and affect core components of the TCP/IP stacks instead of application level or other protocols, as shown below.

3.2. Time, Cost, and Precision

The table below shows the time and cost incurred when running the static analysis stages of the harness.

Some results are clear from the table:

• Across ten TCP/IP stacks, the pipeline processed 362 candidate findings for roughly $935, an average of $2.58 per finding.
• Cost per finding was between $0.95 and $4.16, roughly scaling with the number of static findings. The number of sinks and groups in stage 1 is a fair predictor of the total analysis cost.
• Stages 1 through 3 took around ten hours of wall-clock time in total for all ten targets.
• Source-code targets averaged less than 40 minutes each, and binary targets took around 90 minutes (2.3 times longer).
• The stage 1 scanner finished every source-code target in under two minutes, while binary targets averaged 30 minutes.

Because dynamic analysis is interactive, we do not have precise measurements of time and costs for stages 0 and 4, but we estimated costs between $15-30 for open-source targets and between $50-300 for binaries.

In general, source code targets are faster and less expensive to analyze. Static analyzers work better on source code, and AI agents can understand the intent of the code based on comments and documentation files to draw conclusions faster. The dynamic analysis stage can easily compile source code with the right flags, modules, and libraries to test all the findings. It is the ideal environment for vulnerability research.

Binary targets were much more complex. Static analysis of binary stacks was on average six times more expensive and took twice as long for the following reasons:

• Decompiled targets produced 2-3x more sinks during static analysis than open-source stacks and 5-10x more sinks survived the reachability filtering stage.
• The Ghidra disassembler and decompiler may produce inaccuracies that result into more false positives. Every false positive missed during early analysis stages generates more analysis costs later – this can be a 3-7x increase in the costs per finding.
• Static analysis queries run much longer on binaries because bytecode gets decompiled and converted into the CPG representation used by Joern.
• Raw firmware images need LLM-assisted preprocessing (stage 0) that can significantly influence the total wall-clock time. The S1 analysis took around 67 minutes for Stage 0 (22 minutes for function renaming alone) while only additional 13 minutes were spent on Stage 1 (SAST scan).

Dynamic analysis is also considerably more complex for binary targets (stage 4 in particular). With no source code to build, the only way to obtain a running target is to emulate the binary, which presents an entirely new set of challenges. This is reflected in the estimated costs of $50–300 for running stage 4 on our binary targets compared with $15–30 per source-code targets.

Across the ten stacks, 362 static analysis findings became 312 unique candidates after deduplication and then 99 confirmed issues. Per-stack precision – the rate of true positive findings – ranged from 11% to 70%. In the best case, roughly one finding in three was wrong; in the worst, nine in 10. This shows how much the addition of AI reasoning improves on the findings of traditional static analysis.

As with time and cost, precision was better for source code than binaries. Source-code targets averaged 47% precision compared with 34% for binaries. The average precision for binaries decreases to 22% if we remove the outlier S2. That stack was an outlier because the binary demo application retained symbols and ELF headers, which is rare for proprietary code, but makes disassembly, decompilation, and rule-based vulnerability scanning much easier.

3.3. Legacy Software and the Supply Chain

When we concluded Project Memoria at the end of 2021 and looked back at its results in 2022, we listed several lessons learned beyond the vulnerabilities we disclosed. Six years later and with AI enabling faster and cheaper discovery of vulnerabilities, some of those same lessons are more relevant than ever:

• Legacy software enables the connected world. At the start of Project Memoria, the average age of the analyzed TCP/IP stacks was almost 20 years. Now, some are no longer supported. . Similarly, one of the stacks for which disclosure is still ongoing had the end of general support in December 2025 and will see the end of extended support in September 2027. As software ages, the likelihood of patches ever becoming available decreases.
• Hundreds of products across several industries are impacted because of the supply chain. These TCP/IP stacks are embedded in several products used in operational technology, medical devices, network equipment, IoT, and others. At the end of Project Memoria we identified more than 100 products from dozens of vendors that were affected. In this new round of vulnerabilities, Siemens was the first to identify vulnerable devices: several building automation controllers in the APOGEE, Desigo and TALON product lines run Nucleus NET and are susceptible to the newly discovered issues. Other vendors are still investigating, but one case in particular made us think again about the supply chain. The version of the S1 stack we analyzed was embedded in the firmware of a discontinued wireless access point, as part of a third-party operating system. Not only that access point is now discontinued but the company that produced it is defunct. Yet, in the process of analyzing S1, our harness identified seven vulnerabilities specific to these devices, including buffer overflow via firmware upload and hardcoded administrator credentials that cannot be changed for web and shell management. Unsupported legacy products such as this access point abound and AI-enhanced research can now quickly and inexpensively uncover dangerous vulnerabilities for which no vendor will be able to provide a patch.
• Supply chain vulnerabilities are here to stay. It was quite surprising to find that many foundational vulnerabilities on core networking protocol implementations survived for years in the re-analyzed targets even after Project Memoria. They were missed by us, other researchers, and the software vendors themselves. Hopefully, the advent of AI-enabled research will make deeper analysis of critical software more feasible and eradicate this type of flaw, but for now many supply chain vulnerabilities are here to stay.

4. Conclusion and Mitigation Recommendations

This research shows that even with generally available models and a limited budget, humans with AI assistance can find vulnerabilities on open source and binary targets that are relevant to critical infrastructure for a fraction of the time and cost incurred until very recently.

The accelerated pace of vulnerability finding and exploitation with AI means that vendors must address a growing number of patches and that end users can no longer rely on patching alone as a viable security strategy.

We recommend asset owners and end users to:

• Assess and prioritize risk based on reachability, exploitability and operational impact. Treat vulnerabilities differently based on contextual information, including a device’s role, network exposure, compensating controls, and potential operational consequences. When vulnerabilities cannot be patched, it’s crucial to know what risk they really bring to the business, in order to make informed decisions about security controls.
• Reduce unnecessary exposure of devices. Disable or restrict high-risk services, such as FTP, Telnet, IPv6 and web administration interfaces wherever possible. Point devices at internal DNS servers instead of external resolvers. Implement secure remote access to replace flat VPN access and shared credentials with brokered, least-privilege access to reduce the paths available to an attacker seeking to reach vulnerable controllers.
• Isolate devices that cannot be patched. Put end-of-life devices and other unsupported products in tightly restricted network segments. Allow only the traffic they need, and plan to replace them. AI makes it cheap to find new flaws in these devices, but no one will ever fix them.

• Shorten the time to patch when fixes exist. After patches are published, the risk depends on how quickly end users apply them. Patching embedded devices is notoriously difficult, but organizations need to re-evaluate and accelerate patching processes to keep up with a faster rate of disclosures.
• Make security part of procurement. Require suppliers to state support lifetimes, publish a vulnerability disclosure policy, provide software bills of materials (SBOMs) and show evidence of ongoing security testing, including AI-assisted testing.

Software vendors and maintainers should:

• Use AI to find bugs before attackers do. Add AI-assisted static analysis to development and release pipelines, and rerun variant analysis on code that was already audited. Our harness rediscovered 40% of past bugs and found 66 new ones, which shows that one round of research and analysis does not make a product secure.
• Expand capacity to handle more reports. Expect more AI-generated vulnerability reports, many of them low quality, and invest in triage and coordinated disclosure processes so real issues don’t get buried.

Appendix: Vulnerability Details

The table below shows the details of the vulnerabilities that have already been fixed. Vulnerabilities affecting S1, S2 and S3 are not shown because they are still ongoing responsible disclosure. We have requested CVE IDs for the vulnerabilities affecting open-source software to MITRE and are still waiting for their assignment. The table will be updated once those IDs become available.