A Forescout research team says an AI-assisted workflow examined 10 embedded TCP/IP stacks and validated 99 vulnerabilities in 90 hours, including 66 previously unknown flaws. The headline comparison with nine months of prior manual code analysis is striking, but it needs context: the 90 hours included substantial human validation, while the reported AI analysis itself took about 10 hours. The result is best read as evidence that a mature, purpose-built workflow can compress one kind of vulnerability-hunting effort—not as proof that AI independently replaces security researchers or can find every class of flaw.

The work matters because TCP/IP software is reused inside connected products, including equipment deployed in operational technology (OT), internet-of-things (IoT), medical and network environments. A flaw in a shared component can therefore have consequences beyond the code repository where it was found. But the distance between a newly identified stack flaw and a real-world risk depends on product implementation, exposure, patch availability and operational context. Forescout’s report illustrates both the promise of faster discovery and the enduring difficulty of translating findings into safer deployed systems.

Table of Contents

What the researchers tested

Forescout Research – Vedere Labs built a specialized harness combining generally available AI models with conventional security-analysis techniques, then applied it to 10 TCP/IP stacks. Seven had been examined in the firm’s earlier Project Memoria work; three were new to this study. TCP/IP stacks implement the protocols that let devices communicate across networks. They are often embedded in products whose users may never know which underlying implementation they contain.

The team’s stated research question was practical: could researchers use accessible models and a limited budget to analyze open-source code and proprietary binaries relevant to critical infrastructure? The report covers both source-code analysis and binary analysis, the latter intended to address cases where firmware is available but source code is not. This is a narrower and more useful framing than a claim that a general chatbot can independently discover vulnerabilities across arbitrary infrastructure.

Cybersecurity Dive’s independent account describes the use of Claude models and identifies examples among the stacks, including Contiki, Ethernut, lwIP and wolfIP. It also reports that many results were memory-corruption issues, while logic and design flaws proved harder for the method to capture systematically. That distinction helps explain why the authors emphasize a specialized harness: model output was organized around static-analysis rules and reviewed with additional methods rather than treated as self-authenticating vulnerability evidence.

What the headline numbers mean

The 90-hour figure includes people

Forescout reports 99 validated vulnerabilities: 33 previously known issues rediscovered and 66 new findings. The time comparison is approximately nine months of code analysis in the earlier Project Memoria effort versus 90 hours in the newer study. Crucially, the 90 hours are not 90 hours of unattended model operation. The breakdown is roughly 10 hours of independent AI analysis plus approximately 80 hours of dynamic validation. Human expertise remained integral to deciding whether candidate findings held up.

The earlier comparison also has boundaries. Project Memoria involved a different research program, analyzed 14 stacks across five phases, and took 18 months in total, of which about nine months were code analysis. The 2026 study covered 10 stacks in a single phase. The new workflow benefited from an already-built harness, rules, emulation infrastructure and lessons from prior work. The report explicitly excludes the effort to design and refine that system from the marginal run-cost comparison. So the nine-month-to-90-hour contrast is a company benchmark between research efforts, not a controlled, equal-scope trial of identical teams with and without AI.

Costs depend on what is counted

The press release gives $935 as the total cost of automated static analysis, or $2.58 per finding. The technical report separately estimates total model spending at roughly $1,200 to $2,300 when dynamic-analysis costs are included, and compares that spend with the salary cost of a senior researcher doing manual analysis. It estimates dynamic analysis at $290 to $1,380, depending on the accounting. These figures are not contradictory so much as differently scoped: $935 describes static analysis, while the larger range reflects additional model use. Neither is a full economic cost of reproducing the capability, because infrastructure, harness engineering, rule development and researcher time are not all priced into the run total.

The authors say binary analysis averaged about six times the cost and twice the time of source-code analysis. That is an important qualification: the approach may extend to proprietary firmware, but the most difficult targets were also more expensive to analyze. Forescout’s reported costs describe this particular workflow and sample; they should not be treated as a universal price per vulnerability for organizations starting from scratch.

Where the method has limits

One of the study’s useful findings is also a caveat. Forescout says its harness rediscovered 40% of vulnerabilities previously disclosed in the re-analyzed stacks. This suggests earlier manual research missed flaws that later analysis surfaced, but it does not establish that the system comprehensively detects vulnerabilities. The fact that most prior findings were not rediscovered, and that new findings were concentrated in patterns amenable to the chosen rules, cautions against interpreting the result as a general-purpose security score.

Cybersecurity Dive reports that roughly half of the new issues involved memory corruption, with others involving integer problems, input validation, control-flow or logic flaws. The report’s authors say the harness was better suited to memory-safety patterns because static rules can identify generic code patterns, while logic flaws are implementation-specific and harder to encode without an impractical false-positive/false-negative tradeoff. Some logic issues were found incidentally. In other words, the system’s successes reflect a human-designed workflow and target classes, while its blind spots matter just as much to defenders deciding how much confidence to place in a clean scan.

Nor does finding a weakness establish that it is exploitable in every product using a stack. Exploitability can depend on reachable code paths, compile-time options, device configuration, network exposure and surrounding safeguards. Forescout rates 52% of the 66 new findings as high or critical, but those severity ratings do not by themselves quantify likelihood of exploitation or operational impact in a particular installation. Asset owners need product-level and environment-level context.

Disclosure, fixes and downstream exposure

Forescout says it reported 54 of the 66 new findings to maintainers and vendors; disclosure remains ongoing for some. The independent Cybersecurity Dive report adds a time-sensitive status snapshot: 24 of those reported issues had been fixed, 29 were under investigation, and one concerned the Ethernut project, whose developer had not responded. These counts describe the situation at the time of that report, not a guarantee of current remediation status. Forescout’s press release does not claim that every finding has been fixed or that all affected products are known.

The 12 findings not reported were, according to Cybersecurity Dive’s summary of the report, considered absent from the latest versions of the affected products. That distinction underscores how disclosure decisions can depend on version and maintenance status. The study’s aggregate counts should not be mistaken for 66 newly exploitable devices currently exposed on the internet.

Supply-chain reach is plausible but difficult to enumerate. Shared TCP/IP components may appear in products from many manufacturers, and Forescout draws on earlier research to say the affected stacks may reach hundreds of downstream products. That is a potential exposure footprint, not a verified inventory of vulnerable deployed equipment. Developers need to map component versions into products; manufacturers then need to assess and distribute fixes; operators need to identify whether they run affected versions and whether mitigation is practical.

This chain is particularly consequential in OT and other cyber-physical settings, where downtime may disrupt essential services, and where devices can remain in use after vendor support ends. A software maintainer’s fix is only one stage: an equipment manufacturer may need to integrate it into firmware, test it, and provide it to customers. Unsupported devices may have no patch path at all. Those realities make disclosure coordination and asset visibility part of the security outcome, not administrative details after the research is over.

Implications for operators

For defenders, the report’s most immediate message is not that all systems should be scanned by an AI agent, but that vulnerability discovery may arrive faster and in greater volume. Security teams can prepare by knowing what devices they operate, what software components and versions those devices contain, which are reachable, and what compensating controls are available. A vulnerability’s severity label is only one input alongside exposure, exploitability, device role and consequences of disruption.

Forescout recommends reducing unnecessary network exposure, isolating devices that cannot be patched, and accelerating patching where fixes exist. Those are the company’s recommendations, not findings tested by this study. In practice, changes in industrial networks require careful engineering: disabling a service or segmenting a device without understanding dependencies can interrupt operations. Operators should evaluate controls in the context of safety, availability and approved change processes.

Procurement and product-security practices also matter. Buyers can ask suppliers about support lifetimes, vulnerability-disclosure procedures, software bills of materials and security testing. An SBOM can help connect a component disclosure to a product inventory, though it cannot guarantee that the listed component is vulnerable or that the product is exploitable. Vendors, meanwhile, may need triage workflows able to assess more reports without allowing machine-generated volume to overwhelm maintainers.

The broader security lesson

Forescout’s experiment offers credible evidence that AI can reduce the marginal time required to scrutinize embedded networking software when combined with static-analysis rules, specialized tooling and expert validation. Its 99 validated findings across 10 stacks—and 66 new findings—are consequential within that sample. The study also shows why simple claims of autonomous discovery would be misleading: people validated results, the harness was purpose-built, binary analysis carried extra cost, and the method was stronger on some bug patterns than others.

For critical-infrastructure organizations, the strategic concern is asymmetry of tempo. Researchers and potential attackers can reuse tooling and focus on widely deployed software; operators must still determine which assets are affected, coordinate patches and manage operational risk. Faster discovery raises the value of timely inventory, supplier response and layered controls. It does not eliminate the need to verify findings, assess real-world exposure or make careful decisions about changes to systems that keep essential processes running.

The clearest takeaway is therefore conditional: once an effective analysis harness exists, a carefully scoped run may be much faster and cheaper than comparable manual code review. Whether that translates into safer infrastructure depends on the human work around the model—validating findings, disclosing responsibly, linking components to products, and mitigating risk where patching is possible.

Frequently asked questions

Did AI find all 99 vulnerabilities on its own?

No. Forescout describes an AI-assisted harness. About 10 hours were spent on independent AI analysis and roughly 80 hours on dynamic validation, including human work. The total 90-hour figure includes validation, not just model runtime.

How many findings were new?

Forescout reports 99 validated vulnerabilities across 10 stacks, comprising 33 previously known findings rediscovered and 66 new vulnerabilities. It says 54 of the new findings were reported to vendors and maintainers.

Does the research prove that hundreds of products are vulnerable?

No. The report says the software components may affect hundreds of downstream products, based on earlier research. Actual product exposure requires mapping component versions and configurations to specific products and deployed assets.

Were the reported vulnerabilities all fixed?

No. Cybersecurity Dive reported that 24 of the 54 disclosed findings had been fixed at the time of its coverage, 29 were under investigation and one maintainer had not responded. Status can change, and the disclosure process was ongoing.

References