Why Your AI Agent Cannot Solve Web CTF Challenges

Translated by GPT-5.6-terra

An AI Agent can sometimes do fairly well on a web CTF challenge even without much guidance. It looks around the page, identifies the technologies in use, and tries tools such as ffuf or sqlmap. It may test for SQL injection, SSRF, or LFI and retrieve a flag after only a few requests.

Yet some challenges remain unsolved after a long run. The Agent keeps testing the same login form or loses the web session it was using. It may successfully read a file and still fail to retrieve the flag. The conversation grows longer, while the challenge remains unsolved.

The previous post examined where Agents get stuck on reversing challenges. This post turns to web challenges. Drawing on papers and presentations published between 2025 and 2026, as well as open-source implementations, it looks at the traits of web challenges Agents solve well and at what gets in their way when they do not.

Note: Models are improving quickly, so the performance figures and failure cases in these sources may not apply unchanged to frontier models as of September 2026. This article focuses on the main findings of the sources and on difficulties we have recently encountered while using Agents to solve web challenges.

How Agents Solve Web Challenges
Challenges Agents Solve Well
Limits of Attack-Surface Exploration
The Difficulty of Tracking Sessions and State
Between Finding a Vulnerability and Capturing the Flag
Incorrect Hypotheses and Repeated Attempts
Problems Outside the Model: Tool Observation and Records
The Pitfalls of Determining Success
Conclusion
References

How Agents Solve Web Challenges

An Agent first surveys the target and looks for places where a vulnerability may exist. It checks ports and services, gathers endpoints and parameters, and reads page source and JavaScript bundles. When needed, it broadens its investigation with directory fuzzing or scanners. It then sends requests with suspicious inputs and compares differences in status codes, response bodies, redirects, and response times to determine whether a real vulnerability exists.

Finding a vulnerability does not finish the job. In a CTF, the Agent must obtain and submit the flag. In a benchmark with a separate attack objective, it must have that objective verified. The Agent therefore has to continue working after discovering a vulnerability and confirm the final verdict.

In a successful SQL injection case from CVE-Bench, several Agents divided that work. One Agent first identified the endpoint, found a boolean-blind injection with sqlmap, and extracted data. Another agent then submitted the extracted value to the evaluator for final verification [7]. The result from one stage was passed to the next, carrying the work from vulnerability discovery through validation.

CVE-Bench is a benchmark covering 40 Critical-severity web application CVEs. It runs vulnerable applications in containers and has a target-side evaluator check whether objectives such as file access, database access, or administrator login have been achieved. The paper reports both the success rate of a single attempt and the share of challenges solved at least once across five attempts [7].

To carry work across multiple stages, an Agent must retain more than the requests it has already sent. It must know which session it used, how far it has investigated, and what remains to be done before it can choose its next action. In browser-based challenges, this includes changes to cookies, storage, and the DOM. When this information is scattered only through conversation history, it can disappear as the history grows or is summarized, taking away context needed for later work.

Challenges Agents Solve Well

Agents tend to do better on challenges with a narrow investigation scope and results that are easy to observe. If the parameters to test are visible and changing an input produces an immediately observable response difference, it is easier to decide where to start and what to check next. The burden of continuing the task also falls when a complex session state does not need to be maintained.

It is even more favorable when an observed result can be easily connected to the cause of a vulnerability. Examples include error messages that reveal the function handling input, or source code where the path from an input to a vulnerable function is short and clear. If the vulnerability type is familiar to the model, deciding what to test next becomes easier as well.

The opposite is true when input processing is complex. A presentation titled Stress-Testing SAST and LLMs on Modern Web Backends shows a case where middleware validates a value in the query string while the handler reads a value with the same name from a JSON body. Even if validation code exists, the value actually used may be different. The Agent must therefore trace which value each stage handles [10].

Stress-Testing SAST and LLMs on Modern Web Backends is a Black Hat Europe 2025 presentation on how well conventional SAST and LLMs find vulnerabilities caused by complex data handling in modern web backends. It uses Unsafe Code Lab, a collection of vulnerable applications modeled after real development practices [10].

Challenges favorable to Agents have a clear investigation target and input-processing path, and they place little burden on state management. Assuming the required actions can be carried out with available tools, solving becomes easier when response differences are easy to interpret and less context must be carried into the next stage.

Limits of Attack-Surface Exploration

We now turn to the limits Agents face while solving web challenges and to the situations in which their work stalls.

Before choosing an attack technique, a web Agent may fail to identify where it should test at all.

The most frequent failure type in CVE-Bench was Insufficient Exploration. In the table analyzing Agent runs, the frequency of inadequate exploration ranged from 37.5~80.0%, depending on the configuration. Agents focused on the login form on the first page and missed other endpoints. In other cases, they scanned every port despite being given the target port, or analyzed external sites and the evaluator instead of the target [7].

CyberEvolver's cookie_injection case makes this problem clearer. The Agent read the home page and source, then tested URL parameters, forms, and directories. The actual injection point, however, was in a cookie. It inspected many locations while skipping the one it needed. It also failed to use the presence of Welcome back in the response as a boolean oracle [6].

CyberEvolver is a cybersecurity Agent research project that analyzes failed runs and modifies the scaffold used for the next run, including task instructions and tool configuration. It compares simply repeating the same Agent with improving the configuration based on failure causes across multiple security benchmarks, and analyzes cases such as cookie_injection, in which Agents miss a vulnerable input location or a clue in the response [6].

Counting requests alone does not reveal these omissions. The difference becomes visible when the tested items are recorded separately.

POST /login × username × SQLi       → failed
POST /login × password × SQLi       → untested
GET  /profile × id × IDOR           → needs reproduction
GET  /dashboard × session cookie    → untested

If this record is managed only in a single conversation session, compaction and similar processes can cause the Agent to repeat the same requests while overlooking untested items. To reduce this, PentesterFlow stores the state of each endpoint × parameter × vulnerability type combination and returns combinations with no record as an untested list [1]. The Agent records this state itself, however, so the system cannot find items that were categorized incorrectly. It helps manage the scope of exploration, but it cannot guarantee that each test was performed correctly.

PentesterFlow is an open-source Agent for web penetration testing. It provides HTTP requests, browser traffic capture, coverage, skills, and storage for findings. Its code comments also identify repeatedly testing the same point while missing other combinations as a major limitation [1].

To reduce exploration failures, an Agent should update its list of newly discovered endpoints and input locations whenever it sends a request. It should also revisit items recorded as failures to determine whether they were tested sufficiently. This reduces the chance that it repeatedly tests only conspicuous inputs or mistakes an untested attack surface for one it has already examined.

The Difficulty of Tracking Sessions and State

On the web, sending the same value to the same URL does not always produce the same result. Server and browser state changes according to login status and prior requests. Cookies, CSRF tokens, redirects, the DOM, and browser storage can all affect the next request. If a separate protocol such as WebSocket is used, the connection process and message order must be carried forward as well. The Agent is not simply creating one request; it must carry the state created by earlier requests into later ones.

Two web challenges in the evaluation in From Assistance to Autonomy required network-protocol analysis and multi-step interaction with the environment. When using the same Claude Sonnet 4.5 model, a private general-purpose Agent that could flexibly use a terminal and interactive tools solved both challenges, while Claude Code solved one. The CTF-solving NYU Agent and Cybench Agent solved neither. The authors identified inadequate support for maintaining sessions, handling multi-step tasks, and adapting to changing responses as major reasons. This comparison covers only two challenges and used different execution environments, so it cannot isolate the effect of any particular tool [5].

From Assistance to Autonomy: An Empirical Study of AI Use in a Live Capture-the-Flag (CTF) Competition is a USENIX Security 2026 paper. It observed 41 participants' use of AI during a live CTF and compared human teams with 12 combinations of four autonomous Agent frameworks and three models on the same 17 challenges. NYU Agent and Cybench Agent are CTF-solving frameworks used in the evaluation [5].

securinotes, analyzed by CyberEvolver, is a web CTF challenge in which the flag is stored in a hidden administrator note. The vulnerability was a NoSQL injection using a condition passed to the notes.count method, but the method could not be called through ordinary HTTP requests. The initial page contained only Meteor's default page and a JavaScript bundle; the actual data moved through DDP (Distributed Data Protocol) over WebSocket. The initial Agent failed to recognize this structure and kept trying forms, URL parameters, cookies, and JSON POST requests. In a later run, a script maintained the DDP connection and interacted with the method, extracting the administrator note [6].

Meteor is a framework for building both the client and server of a web application with JavaScript. It synchronizes data between client and server in real time, primarily through WebSocket-based DDP.

What separated success from failure in this case was not merely choosing the value to put into a request. The Agent had to keep a connection open through the protocol used by the application and preserve state created by earlier interactions. Reducing session- and state-tracking failures therefore requires examining not only request generation, but also whether tools support the interactions the task requires and can carry state changes into the next request.

Between Finding a Vulnerability and Capturing the Flag

Reproducing a vulnerability in a web CTF does not mean the challenge has been solved. Even after gaining the ability to read files or execute commands, the Agent must locate the target data and submit the flag. Between these stages, it must decide how to use the capability it has obtained to reach the remaining objective.

apb-vm2, analyzed by CyberEvolver, was an LFI challenge requiring the Agent to read /root/flag.txt. The Agent succeeded in reading files through an absolute path, but instead of applying that capability to the target file, it went back to testing other approaches and path-restriction bypasses. It had acquired the capability needed for the solve but did not turn it into the target data [6].

CTFExplorer found the same type of failure in challenges that spanned multiple services. The Silent Corridor and The Glass Atrium required Agents to use access gained from a public service to find internal services and access hidden data. The two challenges contained five flags in total, but each of the six evaluated models recovered only one or two. Exploiting the vulnerability in the first service still left the work of exploring and attacking internal services [4].

CTFExplorer proposes a benchmark that places 40 vulnerable web services on one network, an Agent architecture for exploring it, and CTFExplorerEval for evaluating execution traces. The Silent Corridor and The Glass Atrium are case studies in that benchmark examining multi-stage attacks [4].

Each two projects used different methods to carry earlier results into subsequent work. CyberEvolver revised task instructions based on failure records so that confirmed capabilities would be applied to the remaining objective and submission would not be delayed by unnecessary transformations after obtaining the target data [6]. CTFExplorer shared findings and failure records among Agents, with a supervisory Agent adjusting the next assignment. When failures repeated, a Critic Agent reviewed the record and intervened to change the direction of the approach [4].

In CyberEvolver's follow-up run, the Agent read the target file and submitted the flag. It attempted to interpret the retrieved string, but stopped further transformation when no meaningful result emerged and submitted the original string, which was accepted. The earlier run had successfully read a file yet failed to obtain the flag across 30 steps; after its instructions were revised, the later run completed retrieval and submission in 17 steps [6].

CTFExplorer also captured a flag through collaboration on a separate web challenge in Appendix D of its paper. Agents that could not independently complete the solve within short execution budgets carried it forward through shared records and intervention by the Supervisor and Critic Agents. However, even with this structure, the earlier two multi-stage challenges yielded only one or two of five flags. The structure helped complete some solves, but it did not resolve every remaining step in complex challenges [4].

To turn a vulnerability discovery into a captured flag, an Agent must choose the next task based on both the capability it has acquired and the objective still remaining. Revising task instructions or passing records between Agents are ways to keep that judgment moving forward. Even if the run or responsible Agent changes, the work is complete only when prior progress is used to obtain and submit the target data.

Incorrect Hypotheses and Repeated Attempts

An Agent does not necessarily make progress merely by continuing to run commands. If its initial hypothesis is wrong, changing an input string or increasing the run time can simply repeat the same failure. Passing the task to another Agent does not change the starting point if the new Agent accepts the earlier judgment unchanged.

In CTFExplorer's configuration-comparison experiment, varying the execution budget and the limit on the number of Agents did not steadily increase the solve rate. Runs that ended without progress used more Agents than successful runs. The researchers interpreted this as short-lived Agents repeating similar exploration while frequently reset context made it difficult to develop earlier reasoning. The result is limited to two models and three configurations, but it shows that adding Agents alone does not necessarily advance a stalled solve [4].

XBOW focused on the accumulation of misunderstandings and incorrect assumptions in long-running tasks. Its technical blog explains that it limited a solver Agent's loop of acting and checking results to 80 iterations. Although some cases still succeeded beyond that point, its own observation was that restarting with a new solver was more efficient than extending a run carrying accumulated misunderstandings [8].

These cases show two different failures: context being lost and incorrect assumptions accumulating. Ignoring confirmed facts to the next task is different from accepting the earlier interpretation of those facts unchanged. Even when records are preserved, the existing judgment may be wrong. Even when a new run begins, the same behavior will repeat if it does not incorporate the earlier failure.

CyberEvolver analyzes a failed run and changes the configuration of the next one. It organizes confirmed facts and failure causes from the execution record, then revises the Agent scaffold: task instructions, tool-use rules, and the way observations are processed. This carries an explanation of why the earlier attempt stalled into the next run. The research compared this approach with repeated runs that retained the initial Agent configuration [6].

The revised configuration produced a larger improvement than simply running the same configuration more often. Across four models and four evaluation settings, the average difference between the estimated cumulative solve rates at four and sixteen runs of the initial Agent was 1.4%. CyberEvolver's solve rate, in contrast, was on average 13.6% higher than the initial Agent's cumulative sixteen-run rate. The experiment was not limited to web challenges, but in this experiment changing the configuration based on failure analysis solved additional challenges that repeated execution did not [6].

Escaping an incorrect hypothesis is not simply a choice between extending a run and starting over. Confirmed facts from the earlier record should be retained, while the interpretation and working method that caused repeated failure must remain open to revision. A retry has meaning only when it is clear what the earlier failure changed in the next judgment.

Problems Outside the Model: Tool Observation and Records

Even when an Agent can perform the necessary interactions, that does not guarantee that the results are fully conveyed to the model. If a tool shows only part of a response or a conversation summary omits the basis for a judgment, the Agent may understand what happened only incompletely. Alongside the state-management issues discussed earlier, we also need to examine what the tools observe and what records they retain.

The HTTP tool in pentestkit examined in this article gathers links from href, src, and action, and gives the model only the first 4,000 characters of a response body. It stores up to 24,000 characters in a file, allowing some information that was not shown to the model to be revisited, but even that file does not guarantee the full response. This HTTP tool also cannot directly observe changes on the page after JavaScript executes in the browser [2].

Even when records are retained, reducing a result to only success or failure can discard differences in status codes, body length, redirects, and error types. Failing to distinguish a parser error from an error in the tool itself also leads to misreading the server's response. The gap between what a tool observed and what the model received affects later judgment.

Strix provides mechanisms for preserving its working environment and records. Since multiple Agents sharing a default browser can alter each other's page state, its guidance calls for a separate browser session per Agent. It also stores large tool outputs in files while sending only excerpts and file paths to the conversation. As context grows, it summarizes older records while keeping recent records in their original form [3].

Strix is an open-source tool in which multiple specialized Agents divide security-testing work. It supports interaction with an environment through browser, shell, and proxy tools, as well as records of findings and test progress [3].

This reduces the amount of information placed in the conversation while leaving a path to revisit stored output. A summary, however, does not replace the original record. PentesterFlow explicitly treats a summary as an imperfect index for locating earlier work. When exact addresses, response content, or earlier results are needed, it advises against concluding from a summary alone and recommends verification through a new tool call in the current session [1].

The adequacy of tool observation and records should be judged by whether the evidence needed for the next decision can be checked. Storing outputs and summarizing them can help continue a long task, but they cannot restore information that was never observed or was lost during storage. To reduce misunderstandings caused by tool limitations, it must be possible to distinguish what the Agent directly checked from what it inferred from a summary or a partial output.

The Pitfalls of Determining Success

Carrying out work intended to reach an objective and determining whether the objective was actually reached are separate problems. Even when an Agent runs a command and prints a result, we must verify where that result came from and what it proves.

The Black Hat USA 2025 presentation AI Agents for Offsec with Zero False Positives describes an Agent testing command injection that mishandled quotation marks and read /etc/passwd from its own environment. It treated this as success even though it had not retrieved a file from the target server [9]. The opposite error also occurred: in CTFExplorer, a Critic Agent judged an already accepted flag to be a hallucination [4]. Both the Agent declaring success and the Agent reviewing it can make judgments that differ from the actual result.

AI Agents for Offsec with Zero False Positives is a presentation on reducing false positives by checking an Agent's vulnerability claims with non-AI verification code. It covers evidence-checking methods for different vulnerability types and problems caused by poorly designed verifiers [9].

In evaluations with predetermined flags, the output string can be compared with the answer. pentestkit, which uses XBOW's public benchmark, injects a predetermined flag into the challenge environment and checks after execution whether that exact string appears in the Agent's output or result file [2]. CVE-Bench has a target-side evaluation server check predefined objectives such as file or database access and return success in the status field of its /done response [7]. Both methods check whether defined conditions were met independently of an Agent's declaration of success.

The XBOW benchmark is a set of 104 web-security CTF challenges published by XBOW in 2024. Each challenge runs in Docker and requires finding a hidden flag. A single objective can involve several vulnerabilities or solution steps. The official repository notes that, as of mid-2026, these challenges have become saturated and are no longer well suited to distinguishing model or Agent-framework performance [11].

Evaluation environments without predetermined flags can also prepare validation data. The Black Hat presentation above proposes placing a hard-to-guess canary string in a server file or database that should not normally be accessible, then having non-AI code compare it with the value submitted by the Agent. This distinguishes presenting output that merely resembles a file from actually accessing target data [9].

Actions whose result does not appear in a direct response can be confirmed with OAST (Out-of-Band Application Security Testing). OAST is a security-testing method that observes an application's behavior through communications received by a separate server; the observed communication is called a callback [12]. However, the fact that a communication was observed must still be assessed against the objective of the particular challenge.

Verification code does not eliminate every misjudgment. The same Black Hat presentation describes cases in which unintended behavior passed verification because the URL format or browser execution environment was not constrained enough. It also accepted a simple console output as evidence of XSS and produced an incorrect result. Checking only whether a particular signal occurred can miss whether that signal was caused by the target's vulnerability [9].

Success should be determined by whether evidence from the actual target fulfills the defined objective. In a real web service, we must also check whether the behavior was originally allowed. Especially for cases involving access to other users' data or business rules, obtaining a value alone is not enough to conclude that a vulnerability exists [9]. Distinguishing apparent success from real success requires checking the source of the result, achievement of the objective, and the scope of permitted behavior separately from the Agent's explanation.

Conclusion

To close, an ability of an agent to solve web challenges was shaped not only by the structure of the challenge, but also by what work it could perform with its tools and how well it could use earlier results. The favorable conditions and the situations in which solving stalls can be summarized together as follows.

Area	Conditions Favorable to Solving	Situations Where Solving Stalls
Exploration scope	Paths and input points are exposed, making it easy to decide what to investigate.	The Agent misses an important input point and repeatedly investigates only familiar paths.
State and stages	The state to maintain is simple, and there are few stages before the objective.	The Agent cannot maintain multiple connection states and intermediate results, or cannot apply an acquired capability to the next stage.
Tools and observation	It can perform required actions and observe differences in responses.	The tools do not support required actions, or the Agent makes decisions from partial output alone.
Records and task selection	It can revisit actual requests and responses and distinguish completed checks from remaining work.	Records disappear, or summaries omit evidence, causing the same work to be repeated.
Failure and revised judgment	It can revise hypotheses and working methods based on earlier failures.	A run is extended or a responsible Agent changes, but the same incorrect assumption is carried forward.

Making progress on a solve and actually solving the challenge must be distinguished. Clear success criteria and external verification are needed to establish whether the objective was reached. Yet even a verifier can produce a false conclusion when its conditions are wrong, so success determination must separately consider the following.

What to Check When Determining Success	Why It Needs Checking
Source of evidence	We must verify that an output value or observed signal came from the actual target.
Objective and validation criteria	We must distinguish a vulnerability candidate, reproduction, objective completion, and final acceptance, and check objective-appropriate evidence independently of the Agent's explanation.
Scope of permitted behavior	In a real web service, obtaining data alone does not establish a vulnerability. We must also determine whether the access or behavior was originally allowed.

Record preservation, task coordination, execution-configuration changes, and external verification are attempts to reduce these difficulties. But merely having those features is not enough. The records must inform the next judgment, failures must lead to changes in the working method, and evidence must be validated against the objective.

The failures examined in this article shared a common pattern. Agents missed required input points even after recognizing a vulnerability, failed to reach the target data even after obtaining a usable capability, and misjudged success even after obtaining a result.

Failing to carry the result of each stage into the next action and final verification: that is the reason of your AI agent cannot solve web CTF challenges.

References

[1] PentesterFlow/agent: https://github.com/PentesterFlow/agent

[2] lordx64/pentestkit: https://github.com/lordx64/pentestkit

[3] usestrix/strix: https://github.com/usestrix/strix

[4] Nanda Rani et al., “CTFExplorer: Evaluating LLM Offensive Agents Through Multi-Target Web CTF Benchmarking”: https://arxiv.org/abs/2602.08023v3

[5] Tingxuan Tang et al., “From Assistance to Autonomy: An Empirical Study of AI Use in a Live Capture-the-Flag (CTF) Competition”: https://www.usenix.org/system/files/usenixsecurity26-tang-tingxuan.pdf

[6] Yihe Fan et al., “CyberEvolver: Structured Self-Evolution for Cybersecurity Agents on the Fly”: https://arxiv.org/abs/2605.26195v2

[7] Yuxuan Zhu et al., “CVE-Bench: A Benchmark for AI Agents' Ability to Exploit Real-World Web Application Vulnerabilities”: https://arxiv.org/abs/2503.17332

[8] Albert Ziegler, XBOW, “Agents Built From Alloys”: https://xbow.com/blog/alloy-agents

[9] Brendan Dolan-Gavitt, Black Hat USA 2025, “AI Agents for Offsec with Zero False Positives”: https://i.blackhat.com/BH-USA-25/Presentations/US-25-Dolan-Gavitt-AI-Agents-for-Offsec-with-Zero-False-Positives-Thursday.pdf

[10] Andrew Konstantinov and Irina Iarlykanova, “Stress-Testing SAST and LLMs on Modern Web Backends,” Black Hat Europe 2025: https://i.blackhat.com/BH-EU-25/eu-25-Konstantinov-UnsafeCodeDetectionBenchmark.pdf

[11] XBOW, “XBOW Validation Benchmarks”: Official repository and details of challenge composition/flag injection. Checked 2026-09-06. Includes the README notice on benchmark saturation and reduced discriminative value.

[12] PortSwigger, “Out-of-band application security testing (OAST)”: Explanation of OAST, How Burp Collaborator observes communications.