When this AI security researcher confirmed an unauthenticated remote code execution vulnerability in OpenMed, the finding was not just another security bug. It showed how AI can help vulnerability researchers move from scattered code signals to a real, reproducible attack path.
Software teams already use AI to write code, generate tests and summarize pull requests. The next step is to use it more deliberately in secure software development, especially to help identify risky execution boundaries that ordinary code review can miss.
OpenMed was not an isolated case. It became the first of four remote code execution vulnerabilities I found through an AI-assisted workflow. Together, the affected open-source projects account for more than 105 million downloads:
- CVE-2026-47117 – OpenMed – CVSS 9.8 Critical
- CVE-2026-47103 – Python StateMachine – CVSS 9.8 Critical
- CVE-2026-9147 – uproot – CVSS 7.8 High
- CVE-2026-10036 – SpeechBrain – CVSS 8.8 High
Finding the attack path
At first glance, the four vulnerabilities looked unrelated. The vulnerabilities came from different weaknesses: unsafe remote-model loading, unsafe expression evaluation, generated-code injection and unsafe YAML deserialization. But the underlying lesson was the same: serious bugs often appear when external data crosses a boundary and becomes executable behavior.
That is why AI-assisted vulnerability discovery should become part of secure software development. Not as a replacement for static analysis, human review or penetration testing, but as a layer that helps developers and security teams ask better questions earlier.
Static analysis is good at finding signals. It can identify risky functions, suspicious data flows and patterns associated with known weakness classes. But scanners do not always explain whether a real attacker can reach the code, control the input and produce meaningful impact.
A dangerous function may be unreachable. A suspicious data flow may be blocked by validation. At the same time, a harmless-looking metadata field may become dangerous if it is later used in code generation, model loading or deserialization.
Where AI helped
The value of AI in this process was not that it produced final answers. It helped connect signals into testable theories.
In my workflow, specialized local language models were used to examine findings from static analysis, reason about surrounding source code and propose possible exploit paths. A second model was then used to challenge those theories, question assumptions and look for missing preconditions.
The models did not decide whether a vulnerability was real. They helped form and test hypotheses. Human validation remained the gate.
That distinction matters. AI can produce convincing explanations that are wrong. It can misunderstand framework behavior, overlook version-specific safeguards or assume attacker control where none exists. For that reason, every candidate had to be manually reproduced in a controlled environment before it became a disclosure.
Four bugs, one pattern
The pattern became clearer when the findings were viewed side by side.
In OpenMed, a user-controlled model name could influence a model-loading path that trusted remote code. In Python StateMachine, attacker-controlled SCXML expressions could reach unsafe evaluation behavior. In uproot, metadata from a crafted ROOT file could be interpolated into dynamically generated Python source. In SpeechBrain, checkpoint metadata could trigger unsafe YAML parsing during checkpoint discovery, even when the malicious checkpoint was not selected for recovery.
Different projects. Different code paths. Same security question: can external data become executable?
What developers can learn
The lesson is practical: review the places where software turns data into behavior. Developers should look closely at features that evaluate expressions, load remote models, parse complex files, generate source code, or deserialize metadata. These features are powerful, but they also create places where trust can be lost.
AI-assisted review can help teams inspect those areas more systematically. A practical process is simple: use static analysis to find risky primitives, use AI to reason about exploitability, use an opposing review to challenge the theory, and rely on human testing to confirm or reject the issue.
As software increasingly depends on AI models, generated code, configuration-driven workflows, and complex data formats, secure development needs a broader definition of input. A model name can become a code-loading decision. A file can become generated source. Metadata can become execution.
My findings demonstrate why this matters. Four separate open-source projects, used at large scale, exposed remote code execution paths through these kinds of trust-boundary failures. Because these projects are widely used across scientific computing, machine learning, healthcare, and data workflows, the fixes reduced exposure across a broad open-source user base.
The common lesson is not that AI alone finds vulnerabilities. It is that AI-assisted investigation, combined with static analysis and human validation, can help researchers identify the boundaries where deeper security judgment is needed. Used responsibly, AI does not replace human expertise. It makes that expertise more focused.
SD Times Q&A
What is the difference between AI-assisted vulnerability discovery and traditional static analysis?
Static analysis identifies risky functions, suspicious data flows, and known weakness patterns, but cannot reliably determine whether an attacker can actually reach and control that code path. AI-assisted review adds a reasoning layer that evaluates exploitability — assessing reachability, attacker control, and real-world impact — before a human validates the finding manually.
What types of code patterns are most likely to introduce remote code execution vulnerabilities?
Remote code execution vulnerabilities frequently appear at trust boundaries where external data becomes executable behavior. High-risk patterns include unsafe remote model loading, dynamic expression evaluation, deserialization of untrusted metadata (e.g., YAML), and interpolation of user-controlled data into dynamically generated source code.
How do I integrate AI-assisted security review into a secure software development workflow?
A practical four-step approach is: (1) use static analysis to surface risky primitives, (2) use an AI model to reason about exploitability for each finding, (3) use an opposing AI review to challenge assumptions and identify missing preconditions, and (4) rely on manual testing in a controlled environment to confirm or reject the vulnerability before any disclosure.
What open-source Python packages have had critical remote code execution CVEs related to unsafe deserialization or model loading?
Recent examples include OpenMed (CVE-2026-47117, CVSS 9.8), Python StateMachine (CVE-2026-47103, CVSS 9.8), uproot (CVE-2026-9147, CVSS 7.8), and SpeechBrain (CVE-2026-10036, CVSS 8.8). Each vulnerability involved external data crossing a trust boundary and becoming executable — through model loading, expression evaluation, code generation, or YAML deserialization.
How can AI be used to find security vulnerabilities in code?
AI can assist vulnerability discovery by connecting signals from static analysis into testable exploit hypotheses. In practice, a language model examines risky code patterns, reasons about surrounding source, and proposes possible attack paths, while a second model challenges those theories. Human validation is still required to confirm any real vulnerability before disclosure.
