VEXAIoT Uses AI Agents to Automate IoT Vulnerability Discovery and Exploitation

Security researchers have developed VEXAIoT, a multi-agent AI system that can scan IoT environments, identify known vulnerabilities, plan attacks, and execute exploits with limited human involvement.

The research prototype combines two large language model agents with established penetration-testing tools. One agent handles reconnaissance and attack planning, while the other generates commands, runs tools, and checks whether each attack succeeded.

Researchers tested VEXAIoT only in isolated environments designed for security training. The system achieved a 95% success rate across 260 attack executions, but the results do not prove that it would perform equally well against production IoT devices.

VEXAIoT separates vulnerability discovery from attack execution

The VEXAIoT research paper describes a dependency-aware framework built around two coordinated AI agents.

The vulnerability detection agent begins by examining the target network. It identifies open ports, active protocols, exposed services, and software versions that may contain known security weaknesses.

The attack execution agent receives the resulting plan and determines which offensive security tools or scripts it needs. It then generates commands, runs them against the test system, and returns the output for validation.

VEXAIoT component	Main responsibilities
Vulnerability detection agent	Scans targets, identifies services, searches for known vulnerabilities, and creates an attack plan
Attack execution agent	Selects tools, generates commands, runs attacks, and reports the results
Orchestration workflow	Tracks dependencies, validates outcomes, and decides whether to continue or retry
Human oversight layer	Displays generated commands and outputs so an operator can review or interrupt execution

The system starts with Nmap reconnaissance

VEXAIoT uses Nmap to discover reachable systems and identify services listening on open ports. The collected information can include protocol names, service banners, and estimated software versions.

The official Nmap network scanning documentation describes how the tool can support host discovery, port scanning, service detection, and operating system identification.

After completing the scan, VEXAIoT passes the results to SearchSploit. That tool compares detected software and versions with the local Exploit Database archive.

1. Identify the target device and reachable network address.
2. Use Nmap to find open ports and exposed services.
3. Extract software names and version information.
4. Search for related CVEs and public exploit code.
5. Pass the findings to the vulnerability detection agent.
6. Generate an ordered attack plan.

SearchSploit connects services to public exploits

SearchSploit provides a command-line interface for searching the Exploit Database. Penetration testers can use it to find public proof-of-concept code associated with specific products and vulnerabilities.

VEXAIoT uses SearchSploit vulnerability data to map exposed services to known CVEs and available exploit scripts.

The AI agent then evaluates the available information and determines which attacks appear relevant. It also considers whether one attack must succeed before another can begin.

For example, an action that requires valid credentials may depend on an earlier password recovery or traffic interception attempt. The system schedules the credential-gathering step first rather than immediately running an attack that cannot yet work.

VEXAIoT can adjust commands after failures

The attack execution agent does not stop automatically after every failed command. It receives the error message and can generate a revised command or select another approach.

The vulnerability detection agent then reviews the output and classifies the attempt as successful, unsuccessful, or suitable for a retry.

This feedback loop allows VEXAIoT to adapt to minor execution problems, such as incorrect command syntax, missing arguments, or tool output that differs from what the model expected.

Execution result	Framework response
Confirmed success	Records the result and continues to the next planned attack
Command error	Sends the error to the execution agent and requests another approach
Missing prerequisite	Runs the required credential or information-gathering step first
Model refusal	Records the attempt as a failure unless another valid path remains
Unclear result	Uses command output and validation checks to determine whether the attack worked

Researchers tested the framework against IoTGoat

The main evaluation used IoTGoat, an intentionally insecure firmware environment based on OpenWrt. OWASP created it to help researchers and students study common IoT security weaknesses.

The OWASP IoTGoat project includes vulnerabilities mapped to the OWASP Internet of Things security risks. It should run only in an isolated laboratory.

The researchers configured VEXAIoT to attempt ten attack scenarios involving credentials, network services, software weaknesses, insecure updates, exposed data, and other IoT risks.

• Weak or hardcoded password discovery
• Cross-site scripting
• MiniUPnP backdoor exploitation
• Developer backdoor access
• Malicious firmware update execution
• DNS denial-of-service activity
• Plaintext credential interception
• Database information extraction
• Remote command execution
• Log deletion

IoTGoat tests reached a 94.5% success rate

The researchers ran each of the ten IoTGoat scenarios 20 times, producing 200 attack executions.

VEXAIoT completed 189 of those attempts successfully, resulting in a 94.5% success rate. Seven scenarios succeeded in every trial.

The framework recorded weaker results for the MiniUPnP backdoor and DNS denial-of-service scenarios. Each succeeded in 16 of 20 attempts, producing an 80% success rate.

IoTGoat result	Reported figure
Total scenarios	10
Trials per scenario	20
Total executions	200
Successful executions	189
Overall success rate	94.5%
Scenarios with 100% success	Seven
Lowest individual success rate	80%

Some failures came from command errors and AI refusals

The system did not fail only because an exploit was technically ineffective. Some attempts failed when the language model generated an incorrect command or refused to assist with an offensive action.

Researchers said the MiniUPnP scenario encountered command syntax problems. The agent could retry failed instructions, but it did not always produce a working replacement before the experiment ended.

Model refusals also affected several tests. Although the prompts framed the work as authorized security testing inside an isolated laboratory, the model sometimes declined to generate or run an attack.

These results show that an autonomous testing system can inherit the unpredictability of the language model beneath it.

Metasploitable2 provided a second test environment

The researchers also evaluated VEXAIoT against Metasploitable2, an intentionally vulnerable virtual machine maintained for penetration-testing practice.

The Rapid7 Metasploitable2 documentation describes it as a deliberately vulnerable Ubuntu virtual machine intended for security training and testing.

Metasploitable2 does not represent a dedicated IoT operating system. However, it contains services and weaknesses that can also appear in connected and embedded environments.

Researchers selected three scenarios:

• Exploitation of the VSFTPD 2.3.4 backdoor
• Recovery of exposed database credentials
• Remote code execution through an insecure distccd service

Metasploitable2 tests reached a 96.7% success rate

VEXAIoT performed 60 attacks against Metasploitable2, with 20 attempts for each scenario.

The framework successfully exploited the VSFTPD backdoor in every attempt. It also recovered the database credentials in all 20 trials.

The remote code execution scenario succeeded 18 times and failed twice because of model refusals.

Metasploitable2 attack	Successful attempts	Total attempts	Success rate
VSFTPD backdoor	20	20	100%
Database credentials	20	20	100%
Remote code execution	18	20	90%
Combined result	58	60	96.7%

Overall success reached 95% across 260 executions

Combining the IoTGoat and Metasploitable2 results, VEXAIoT completed 247 of 260 attack attempts.

That produced an overall success rate of 95%. Most attack types took less than two minutes to complete, although password-related tasks required more time.

The full VEXAIoT evaluation presents the results as evidence that LLM agents can automate parts of vulnerability assessment and exploit validation in controlled IoT and IoT-adjacent systems.

The reported success rate should not be interpreted as a 95% chance of compromising arbitrary internet-connected devices. Both test targets contained known vulnerabilities and were specifically designed for security exercises.

Parallel execution reduced the total testing time

Some attacks had no dependencies and could run simultaneously. Others required information or credentials collected during an earlier step.

The researchers grouped attacks according to those dependencies. They then ran independent operations in parallel while preserving the required order for connected tasks.

Sequential execution of the ten IoTGoat scenarios took approximately eight minutes and 31 seconds. Dependency-aware parallel execution reduced the time to about three minutes and 50 seconds.

Execution method	Approximate duration
Sequential execution	8 minutes and 31 seconds
Dependency-aware parallel execution	3 minutes and 50 seconds
Approximate time saved	4 minutes and 41 seconds

Parallel execution improved wall-clock performance, but it did not meaningfully reduce token use. Each attack still required its own AI reasoning and tool interaction.

The framework used ChatGPT 5.1 Thinking

The paper states that VEXAIoT used ChatGPT 5.1 Thinking to analyze reconnaissance results, create attack plans, generate commands, and interpret execution output.

The researchers passed Nmap and SearchSploit findings into structured prompts. They also supplied the available tools, target details, test objectives, and constraints of the isolated environment.

The agents logged generated commands, attack plans, and outputs. This design allowed researchers to observe the process and intervene when necessary, even though the framework could continue autonomously after execution began.

Established security tools perform the actual scanning and attacks

VEXAIoT does not replace all conventional penetration-testing software with an AI model. It uses the model primarily for reasoning, planning, tool selection, command generation, and result interpretation.

Nmap still performs network reconnaissance. SearchSploit provides access to known public exploit information, while tools such as Bettercap and available exploit scripts perform individual actions.

The official Nmap guide shows that many discovery capabilities used by the framework existed long before agentic AI. VEXAIoT attempts to automate decisions that a human penetration tester would normally make after reviewing the scan results.

Component	Role in VEXAIoT
Large language model	Analyzes findings, plans attacks, generates commands, and interprets results
Nmap	Discovers systems, ports, protocols, and services
SearchSploit	Finds known vulnerabilities and public exploit references
Bettercap	Supports network interception and related testing
Public exploit scripts	Perform specific vulnerability checks and exploitation attempts

High success rates need careful interpretation

IoTGoat and Metasploitable2 contain intentionally planted security problems. Researchers and students use them because the vulnerabilities remain discoverable and exploitable.

A production IoT environment may include different firmware builds, undocumented protocols, custom hardware, endpoint protections, segmented networks, and patched software.

Real devices may also respond unpredictably to scanning and exploitation. An incorrect command could interrupt a safety system, damage stored data, or make an embedded device unusable.

The evaluation did not establish how VEXAIoT compares with a human penetration tester, a single-agent AI design, or a conventional scripted automation system across the same scenarios.

VEXAIoT still produces unreliable outputs

Researchers identified several limitations that prevent the framework from serving as a fully dependable autonomous security platform.

The language model can hallucinate information, generate invalid commands, misunderstand tool output, or refuse to complete authorized tests. Retry logic can resolve some problems, but it cannot guarantee a correct result.

Key limitations include:

• Commands that contain incorrect syntax or parameters
• False assumptions about the target environment
• Model refusals during legitimate laboratory testing
• Limited validation of generated attack commands
• Dependence on accurate Nmap and SearchSploit findings
• Testing against intentionally vulnerable systems
• No evidence of performance against production IoT fleets
• Token costs that increase with the number and complexity of attacks

Autonomous exploit execution creates safety risks

A system that can scan devices and execute exploits needs strict controls. A targeting mistake could direct harmful commands toward systems outside the authorized test environment.

Organizations evaluating similar frameworks should isolate the laboratory, block outbound access, define an explicit target list, record every command, and require approval for destructive actions.

The IoTGoat training environment itself warns users to treat the project as deliberately insecure software rather than deployable firmware.

Suitable safeguards include:

1. Run the framework in an isolated network with no production access.
2. Use an allow-list containing only authorized target addresses.
3. Block internet routing from vulnerable test machines.
4. Require human approval before destructive or persistence-related actions.
5. Store complete logs of prompts, commands, outputs, and decisions.
6. Set execution timeouts and resource limits.
7. Reset virtual machines to known snapshots after each test.
8. Review generated commands before using them on physical devices.

The system may help authorized IoT security testing

VEXAIoT could eventually help security teams automate repetitive parts of a controlled assessment. It may reduce the time required to interpret scan results, find public exploit references, and validate known weaknesses.

The framework could also help defenders confirm whether a published vulnerability remains exploitable in a test copy of an IoT device.

The SearchSploit tool already helps professionals search for public proof-of-concept code. An AI agent can add an orchestration layer that decides when and how to use those results.

Human reviewers still need to define the scope, assess safety, verify findings, and determine whether the generated actions comply with legal and organizational rules.

Future versions could add stronger command controls

The researchers plan to improve the system with schema-constrained command generation. This approach could force commands to follow an expected structure before the framework runs them.

They also propose retrieval-augmented vulnerability reasoning, larger IoT firmware testbeds, human approval policies, and defensive agents that help prioritize and mitigate discovered weaknesses.

Future research areas include:

• Stronger validation of AI-generated commands
• Better recovery after failed attacks
• Human approval for high-risk actions
• Larger and more varied firmware test environments
• Defensive agents that recommend fixes
• Comparisons with human testers and traditional automation
• Testing across additional IoT architectures and protocols

VEXAIoT is a research tool, not evidence of a live campaign

The study demonstrates that AI agents can coordinate established offensive tools and complete known attack scenarios with a high success rate in a controlled environment.

It does not show that attackers currently use VEXAIoT against internet-connected devices. The researchers did not report deploying the framework against production systems or targets without permission.

The Metasploitable2 test machine and IoTGoat were built to support training, making them substantially easier and safer to attack than real-world infrastructure.

The research still highlights an important change in security automation. AI agents can now coordinate reconnaissance, vulnerability lookup, command generation, execution, and retry logic within one workflow.

Security teams should prepare for both legitimate and malicious uses of that capability while keeping autonomous exploit execution behind strict authorization and technical safeguards.

FAQ