Yaga Exploring Web Applications

From intelligent reconnaissance to multi-stage exploit chaining

Web applications are the most exploited attack surface in today's cybersecurity landscape: 68% of confirmed incidents in the Verizon DBIR 2025 involve a web application as the primary vector. This article details how Yaga conducts complete, autonomous security assessments against web applications, from initial reconnaissance and technology fingerprinting to exploit construction and multi-stage vulnerability chaining. We describe the architecture of the Web Exploitation Pipeline, the mechanism for intercepting and analyzing HTTP requests and responses, the technology detection engine, the dynamic payload construction system, and the Chain Engine, responsible for orchestrating attacks that combine multiple vulnerabilities into maximum-impact sequences. Based on the HackerSec benchmark (150 web cases covering the entire OWASP Top 10), Yaga reaches 98% detection accuracy, 97.6% resolution in XSS scenarios and 93.3% precision in exploitation chains, outperforming all comparable autonomous systems by a margin above 30 percentage points.

1. Introduction

The web remains the primary battleground of offensive security. Modern web applications combine reactive frontends, RESTful and GraphQL APIs, distributed microservices, complex authentication pipelines (OAuth2, SAML, JWT) and, increasingly, components integrated with Large Language Models (LLMs). Each layer of that stack introduces distinct vulnerability classes, and the interaction between layers creates chaining opportunities that traditional scanning tools cannot detect.

Automated scanners such as Burp Suite, OWASP ZAP and Nuclei operate predominantly in pointwise detection mode: each request is analyzed in isolation, and each vulnerability is reported as an independent finding. That approach fails to capture scenarios where the real impact emerges only from the combination of multiple vulnerabilities: an IDOR that alone allows reading another user's data, but which, combined with a Stored XSS and a CSRF flaw, enables complete takeover of administrative accounts.

Yaga was designed to run a web pentest completely and autonomously. It does not limit itself to firing predefined payloads at known endpoints: it maps the application intelligently, understands the underlying architecture and technologies, analyzes the behavior of HTTP requests and responses to infer business logic, builds exploits tailored to the specific context and, crucially, chains multiple vulnerabilities into attack sequences that maximize demonstrable impact.

This article presents, for the first time in technical detail, how each phase of Yaga's web exploitation pipeline operates, from first contact with a target URL to the generation of the final report with chained proofs of concept.

2. Methodology: from start to finish of the web pentest

Yaga follows PTES (Penetration Testing Execution Standard) as its operational framework. Each pipeline phase maps to a PTES phase: Recon corresponds to Intelligence Gathering, Tech Profiler and Surface Mapper implement Threat Modeling, the Detection Engine executes Vulnerability Analysis, Exploit Builder and Chain Engine correspond to Exploitation and Post-Exploitation, and report generation completes the Reporting phase.

The testing engine implements the 12 categories of the OWASP WSTG v4.2, totaling more than 90 individual test cases: WSTG-INFO (11 tests), WSTG-CONF (12 tests), WSTG-IDNT/ATHN (21 tests), WSTG-ATHZ (4 tests), WSTG-SESS (9 tests), WSTG-INPV (19 tests), WSTG-ERRH/CRYP (8 tests), WSTG-BUSN (9 tests), WSTG-CLNT and WSTG-APIT. The WSTG provides the "what to test"; the LLM provides the "how to test".

Yaga aligns its tests to the OWASP ASVS v4.0.3, operating at level L2 by default and covering the 14 requirement categories (V1 through V14). Each finding is mapped to the violated ASVS requirement: a JWT with algorithm confusion maps to V3.5.3, a rate limiting failure to V2.2.1, a missing CSP to V14.4.3. That traceability makes the reports directly usable in compliance processes.

Every vulnerability receives a CWE (Common Weakness Enumeration) identifier, a mapping to MITRE ATT&CK techniques and a contextualized CVSS 4.0 score. The triple taxonomy (CWE for classification, ATT&CK for tactical context, CVSS for prioritization) enables integration with platforms such as DefectDojo and ThreadFix.

3. Architecture of the Web Exploitation Pipeline

Yaga's web exploitation pipeline operates in seven sequential phases, each feeding the next with structured data. The intelligence is cumulative: every discovery refines the mental model the agent maintains of the target application.

FIGURE 1: Yaga's web exploitation pipeline, seven phases with a central Knowledge Graph

3.1 The central knowledge graph

At the center of Yaga's architecture sits the Knowledge Graph: a graph data structure that persists throughout the entire assessment and connects information from every phase. It is what lets the agent sustain, from the first request to the final report, the same mental model a specialist builds of an application while testing it. Each node of the graph represents a discovered entity (endpoint, parameter, cookie, header, technology, vulnerability), and the edges represent relationships (parameter_belongs_to_endpoint, endpoint_requires_authentication, vulnerability_depends_on_another).

The graph lets the Chain Engine, in phase 6, answer questions such as: "is there an attack path starting from a public endpoint that results in code execution on the server?", a question that only makes sense for whoever conducts the test end to end, with the accumulated view of every phase.

3.2 Agentic capabilities: connecting findings through the graph

The agentic nature is what defines Yaga. It is not a model that answers questions, nor a tool that fires checks: it is an autonomous pentest agent that operates against the target, accumulating intelligence and connecting apparently independent discoveries into advanced exploitation chains.

Every finding discovered by any phase of the pipeline is immediately inserted into the Knowledge Graph as a typed node. The agent then runs a continuous enrichment cycle: for each new node, it evaluates whether potential edges exist to nodes already present in the graph, relationships of dependency, precondition or escalation that turn isolated findings into complete attack paths.

This agentic capability operates at three levels:

1. Automatic correlation: when Yaga discovers an IDOR in GET /api/users/:id and, separately, identifies a Stored XSS in the profile field, the graph connects both. The IDOR provides access to other users' data, and the XSS inserted into an admin's profile will execute whenever any user (including administrators) views that profile. The IDOR+XSS chain emerges automatically from the graph, with no need for predefined rules.
2. Precondition reasoning: the agent reasons about what is required to exploit each vulnerability. If a Blind SQLi requires authentication, Yaga searches the graph for paths that provide credentials: an open registration endpoint, default credentials, or a JWT with a weak secret. Each unsatisfied precondition becomes a sub-goal that steers the exploitation.
3. Impact escalation: medium or low severity findings that, connected through the graph, produce critical impact are automatically reclassified. An Information Disclosure (low) that reveals an internal API key (medium), which grants access to an admin panel (high), which exposes all client data (critical): each node alone is tolerable, but the path in the graph demonstrates real critical risk.

FIGURE 2: Individual findings connected by semantic relationships form exploitation chains

3.2.1 Continuous graph enrichment cycle

For each new node inserted into the graph, Yaga triggers an enrichment cycle in which the LLM evaluates potential edges against existing nodes. The edges are typed: depends_on (vuln B requires output from A), escalates_to (two mediums combine into a critical), same_surface (same affected component) and credential_flow (one produces credentials consumed by another). The enrichment is bidirectional: upon discovering SSRF and later an internal Redis without authentication, the graph retroactively connects both, forming the SSRF-to-Redis chain, which would not exist if each finding were assessed in isolation.

3.2.2 Context propagation across phases

Each phase reads from and writes to the Knowledge Graph, creating a multidirectional flow. The technology profile from Phase 2 feeds back into Phase 1 (upon detecting Django, the crawler looks for /__debug__/). Late discoveries trigger re-execution: if the SQLi reveals internal endpoints, Yaga reactivates the crawler. Phase 6 operates over the graph accumulated from all phases: a staging subdomain (Phase 1) + an expired certificate (Phase 2) + an endpoint without auth (Phase 3) can compose a critical chain that no single phase would recognize on its own.

3.2.3 Dependency resolution and sub-goals

The Chain Engine implements backward chaining augmented with LLM reasoning. To reach an impact goal, it decomposes into prerequisites: admin access requires credentials, which may come from (a) SQLi in the users table, (b) a JWT with a weak secret, or (c) a vulnerable password reset. Each unsatisfied prerequisite becomes an active sub-goal. If the direct paths are blocked (MFA on the admin), Yaga looks for indirect paths by combining the findings available in the graph.

3.2.4 Dynamic severity classification through the graph

Yaga classifies severity by the real context of the finding, not by the vulnerability class: a Stored XSS in a field viewed by admins, without CSP, chainable with CSRF, is critical, whereas a reflected XSS on a 404 page is low. The Chain Engine recalculates severity when new edges appear: an Information Disclosure (low) that reveals an API key (CWE-798) unlocking admin access is reclassified as high. This aligns with the OWASP Risk Rating: Technical Impact × Business Impact.

4. Phase 1: reconnaissance and intelligent crawling

Web reconnaissance begins before the first HTTP request. Yaga operates in three stages of progressive collection.

4.1 Passive reconnaissance

Before touching the target, Yaga collects information from passive sources:

• DNS Enumeration: subdomain resolution via curated wordlists, Certificate Transparency logs (crt.sh) and selective DNS bruteforce enumeration. Each discovered subdomain is classified by the probability of hosting a web application (analysis of A/AAAA/CNAME records).
• OSINT Gathering: queries to Shodan, Censys and SecurityTrails to identify exposed services, banners, TLS certificates and alternative ports.
• Historical Analysis: queries to the Wayback Machine and Common Crawl to identify old endpoints that may have been removed from the current application but remain accessible (path leakage).
• Automated Google Dorking: structured queries to find exposed configuration files, debug pages, backup directories and indexed administrative panels.

4.2 Active and deep crawling

After passive reconnaissance, Yaga starts crawling the web application using an approach that combines traditional crawling with semantic understanding.

4.2.1 Spider with JavaScript understanding

Unlike traditional crawlers that only follow <a href> links, Yaga executes JavaScript in the application context to discover:

• Routes defined in SPA frameworks (React Router, Vue Router, Angular Routes)
• API endpoints called via fetch() or XMLHttpRequest
• Dynamic forms rendered by JavaScript
• WebSocket endpoints and Event Source connections
• Programmatically constructed parameters

Listing 1: route extraction from frontend bundles

4.2.2 Context-based endpoint discovery

Yaga does not limit itself to what the crawler finds. Based on the technologies detected (Phase 2), it generates candidate endpoints using LLM reasoning:

• If it detects Laravel: it tests /telescope, /horizon, /_debugbar, /api/documentation
• If it detects Django: it tests /admin/, /__debug__/, /api/schema/
• If it detects Spring Boot: it tests /actuator/, /actuator/env, /actuator/heapdump
• If it detects Node.js/Express: it tests /.env, /package.json, /graphql, /playground

This contextual generation is one of the points where the LLM backbone makes a difference: instead of a static wordlist, Yaga reasons about which endpoints are likely given the observed technology stack.

4.2.3 Coverage and clustering

Estimated coverage is computed via capture-recapture (Chapman estimator):

Ê_total = (k₁ + 1)(k₂ + 1) m + 1 − 1

where k₁ and k₂ are the endpoints from two passes and m the intersection. Endpoints are clustered via DBSCAN with cosine similarity:

sim(v_a, v_b) = v_a · v_b ‖v_a‖ · ‖v_b‖

over the feature vector v_e = [s_status, s_size, s_time, s_type, s_auth]. Similarity above 0.92 groups endpoints, reducing redundant tests.

4.3 Authentication surface mapping

Yaga pays special attention to the authentication flow, since it defines the barrier between the public surface and the authenticated surface:

• Identifies login and registration forms
• Maps OAuth2/OIDC flows (authorization_endpoint, token_endpoint, redirect URIs)
• Analyzes session cookies (HttpOnly, Secure, SameSite flags, expiration time)
• Detects JWTs in Authorization headers or cookies, and analyzes claims and signing algorithm
• Identifies password reset, MFA enrollment and account recovery endpoints

Listing 2: authentication surface map (example)

5. Phase 2: Technology Profiler, understanding the stack

Precisely identifying the target application's technologies is critical because it determines which vulnerability classes are likely, which payloads will be effective and which evasion techniques will be necessary. Yaga implements a multi-layer fingerprinting system.

5.1 Server and framework fingerprinting

Every HTTP response carries signals that reveal the stack: the Server header (web server and version), X-Powered-By (backend framework), the X-Request-Id pattern, the Set-Cookie format, plus Content-Security-Policy, X-Frame-Options and Strict-Transport-Security, which indicate the hardening level. Yaga extracts and catalogs every header of every response, building a probabilistic profile.

TABLE I: Technology confidence matrix (example)

5.1.1 Application layer (behavior)

Beyond static headers, Yaga analyzes application behavior to infer technologies. The error format is a strong signal: stack traces from Django, Laravel, Spring Boot, Express and ASP.NET have distinct patterns. A 500 response with Traceback (most recent call last) confirms Python; a trace starting at at Object.<anonymous> (/app/server.js) confirms Node.js.

5.2 WAF and protection mechanism detection

Identifying Web Application Firewalls and protection mechanisms is essential to calibrate payloads. Each WAF leaves its own indicators: Cloudflare (cf-ray header, __cfduid cookie, 403 page), AWS WAF (x-amzn-requestid), Akamai (AkamaiGHost), ModSecurity (response body pattern, paranoia level), Imperva (incap_ses cookie, visid_incap) and F5 BIG-IP ASM (TS cookie prefix, X-WA- headers).

Yaga performs active WAF detection by sending canonical payloads known to trigger generic rules and analyzing the blocking pattern (status code, response body, added headers). This allows Phase 5 (Exploit Builder) to automatically adjust payloads to work around the specific rules detected.

6. Phase 3: HTTP request and response analysis

HTTP traffic analysis is one of the stages where Yaga's autonomy is most evident. It intercepts each request and response pair and interprets on its own the semantic meaning of the interaction, using the LLM to infer the business logic behind each field, without depending on a human operator reading the traffic.

6.1 Interception and structured parsing

For each request/response pair, Yaga extracts and structures the data, annotating points of interest. In the example of an order creation request, it flags user-controlled parameters and references to other resources:

Listing 3: annotated analysis of a request

On the response side, Yaga identifies excessive data exposure and sequential patterns that enable enumeration:

Listing 4: annotated analysis of a response

6.2 Semantic understanding of business logic

The LLM backbone lets Yaga go beyond syntactic analysis and understand the business logic implicit in each flow:

• Purchase flow: Yaga identifies that product_id + quantity + coupon_code form a financial transaction, and tests price manipulation (negative quantity, coupon applied multiple times, race condition at checkout).
• Permission flow: upon detecting roles (admin, customer, editor), Yaga automatically tests horizontal access (swapping a resource ID) and vertical access (swapping a role or reaching administrative endpoints with a regular user token).
• Upload flow: upon finding an upload endpoint, Yaga tests the bypass variants: double extension, null byte, content-type mismatch, polyglot files and path traversal in the filename.

6.3 State and session flow analysis

Yaga tracks session state across multiple requests, building a state machine model of the application and highlighting the transitions that represent attack paths (authentication bypass, privilege escalation, price manipulation at checkout).

6.4 Response differentiation for blind detection

For vulnerabilities with no visible output (Blind SQL Injection, Blind SSRF, Blind XSS), Yaga implements advanced response differentiation techniques:

• Time-based: measures response time with millisecond precision, injects a controlled delay and compares against the baseline.
• Boolean-based: compares body size, JSON structure and status code between true and false requests.
• Error-based: analyzes subtle differences in error messages that indicate differential processing of the input.
• Out-of-band: sets up external listeners (DNS callback, HTTP callback) to confirm interactions that are not reflected in the direct response.

6.4.1 Statistical detection and entropy

Time-based detection uses Welch's t-test to separate the signal from network noise:

t = T_probe − T_base √s²_probe/n_probe + s²_base/n_base

with adaptive threshold τ_detect = μ_base + 3σ_base. Token entropy is measured via Shannon, H(X) = −∑_i=1ⁿ p(x_i) log₂ p(x_i) (safe tokens: H ≥ 5.0 bits/char), complemented with a chi-square test for uniformity. Boolean-based differentiation uses the normalized difference:

Δ_bool = |len(R_true) − len(R_false)| max(len(R_true), len(R_false))

where Δ above 0.1 across 5 repetitions confirms the injection. The listing below shows the internal log confirming a Blind SQLi through a combination of boolean and time-based signals:

Listing 5: internal log confirming a Blind SQLi

7. Phase 4: vulnerability detection engine

With the application map, the technology profile and the business flow model built, Yaga enters the active detection phase. The engine operates systematically across the entire OWASP Top 10 Web, but with intelligent prioritization based on the context already accumulated.

7.1 Contextual test prioritization

Instead of running every test against every endpoint, Yaga prioritizes based on the probability of success. The prioritization score of each test t for endpoint e is:

P_{priority(t,e)} = P(vuln | tech_e) × w_impact(t) × (1 − P_waf(t))

where P(vuln | tech_e) is the conditional probability of a vulnerability given the technology stack, w_impact is the weight of the potential impact (RCE = 1.0, data leak = 0.8, info disclosure = 0.3) and P_waf is the probability of being blocked by the detected WAF. The conditional probability is derived from historical benchmark data: a SQLi in PHP+MySQL has P = 0.72, against 0.15 for a SQLi in Node.js+PostgreSQL with prepared statements.

TABLE II: Test prioritization by detected context

7.2 Full coverage of the OWASP Top 10 Web

Every test executed is tracked against three simultaneous references: the WSTG v4.2 test case ID, the applicable ASVS 4.0.3 requirement and the CWE identifier. That triple mapping guarantees traceability across standards and enables compliance reporting.

7.2.1 A01, Broken Access Control

IDOR (swapping resource IDs across sessions of different privilege), forced browsing, method tampering, CORS misconfiguration and directory traversal. Yaga maintains simultaneous sessions per role (admin, editor, viewer, anonymous) and runs each request with each session, comparing responses to detect horizontal and vertical flaws. WSTG-ATHZ-01 to ATHZ-04. CWE-639, CWE-284, CWE-862, CWE-863. ASVS V4.1 to V4.3.

7.2.2 A02, Cryptographic Failures

TLS configuration (weak protocols, vulnerable cipher suites), sensitive data in transit without HTTPS, mixed content, and detection of weak hashing (MD5/SHA1) through analysis of reset responses. WSTG-CRYP-01 to CRYP-04. CWE-326, CWE-327, CWE-319, CWE-614. ASVS V6.1 to V6.4, V9.1.

7.2.3 A03, Injection

Coverage of every injection class, with payloads contextualized to the DBMS and runtime detected by the Tech Profiler. Yaga also detects second-order injections. WSTG-INPV-05 to INPV-18. CWE-89, CWE-79, CWE-78, CWE-94, CWE-90, CWE-643. ASVS V5.2 to V5.5.

TABLE III: Injection test matrix (base payloads and evasion variants)

Payloads are adapted to the detected runtime: MySQL uses its own delay function, PostgreSQL its own, MSSQL the corresponding delay command.

7.2.4 A04, Insecure Design

Business logic flaws (skipping checkout steps, race conditions, quantity and price manipulation), absence of rate limiting (login brute force, enumeration via timing) and insufficient anti-automation. Yaga analyzes multi-step flows and runs race conditions to detect TOCTOU. WSTG-BUSL-01 to BUSL-09. CWE-840, CWE-841, CWE-362. ASVS V11.1.

7.2.5 A05, Security Misconfiguration

Default credentials on admin panels, unnecessary features enabled (debug mode, stack traces, directory listing), missing security headers (HSTS, CSP, X-Content-Type-Options, X-Frame-Options), permissive CORS and public cloud storage (S3/Azure/GCS). WSTG-CONF-01 to CONF-11. CWE-16, CWE-942, CWE-693. ASVS V14.1 to V14.5.

7.2.6 A06, Vulnerable and Outdated Components

Yaga cross-references detected versions (via fingerprinting) against CVE databases (NVD, GitHub Security Advisories, Snyk) and verifies whether the exploit path is reachable in the target's real configuration, reducing false positives from components that are vulnerable but unreachable. WSTG-INFO-02, INFO-08, INFO-09. CWE-937, CWE-1104. ASVS V14.2.

7.2.7 A07, Identification and Authentication Failures

JWT attacks (none algorithm, RS256/HS256 confusion, brute force of weak secrets, claim tampering, JWK injection via jku/x5u), session fixation, credential stuffing with absent rate limiting, and weak password policies. WSTG-ATHN-01 to ATHN-10. CWE-287, CWE-384, CWE-307, CWE-640. ASVS V2.1 to V2.10.

7.2.8 A08, Software and Data Integrity Failures

Deserialization attacks (Java, PHP, Python, .NET), CI/CD tampering and missing Subresource Integrity on external CDN scripts. Yaga automatically detects the serialization format by magic bytes and selects the appropriate gadget chains. WSTG-INPV-14, INPV-16. CWE-502, CWE-829, CWE-494. ASVS V5.5, V10.1 to V10.3.

7.2.9 A09, Security Logging and Monitoring Failures

Yaga checks whether its own testing activity generates alerts: it runs noisy attacks and then checks whether they were detected and logged. The absence of detection of an active pentest indicates an incident response failure. WSTG-ERRH-01, ERRH-02. CWE-778, CWE-223. ASVS V7.1 to V7.4.

7.2.10 A10, Server-Side Request Forgery (SSRF)

Classic SSRF (URL manipulation to reach internal services), Blind SSRF (confirmed via DNS/HTTP callback), SSRF via redirect and access to cloud metadata. Yaga identifies parameters that accept URLs (url, webhook, callback, avatar, import) and tests access to internal endpoints, to the cloud metadata endpoint and to internal ports, with bypass via alternative IP encoding, DNS rebinding and chaining with open redirects. WSTG-INPV-19. CWE-918, CWE-611. ASVS V12.6.

8. Phase 5: Exploit Builder, dynamic exploit construction

Identifying a vulnerability is only half the work in a pentest: what proves risk is the exploitation. When the detection engine confirms a finding, Yaga builds a functional exploit that demonstrates the real impact, always within the authorized scope of the engagement.

8.1 Exploit Builder architecture

The Exploit Builder operates in three stages. In Stage 1 (context analysis), it receives from the Knowledge Graph the type of confirmed vulnerability, the affected endpoint and parameter, the stack technologies (to calibrate the payload), the WAF and active protections (to calibrate evasion), the current privilege level and the desired impact goal (set by the Chain Engine or by default).

In Stage 2 (payload generation), the LLM generates tailored payloads, not drawn from a static list. Each payload is built considering the injection context, the WAF rules and the observed CSP policy:

Listing 6: payload generation reasoning (XSS example)

In Stage 3 (validation and refinement), every generated exploit is tested before entering the report: it is executed against the target, Yaga confirms the expected effect occurred and, if it failed, analyzes the reason (WAF block, CSP violation, encoding issue) and generates a variant. Finally, the payload is reduced to the minimum necessary for reliable reproduction.

8.1.1 Search space and optimization

The brute force space is |S| = |Σ|^ℓ, with time t = |S| / (r × k). A JWT secret brute force is considered viable if the key entropy H_key = log₂(|S_secret|) < 40 bits. Fuzzing uses an AFL-style power schedule, E(s) = α × (1 / f(p(s)))^β, where seeds on rare paths receive more mutations. WAF evasion is treated as Bayesian inference, with the posterior updated on each iteration:

P(evasion | payload) = P(payload | evasion) × P(evasion) P(payload)

8.2 Exploit construction by vulnerability class

Upon confirming a SQLi, the Exploit Builder escalates automatically: it identifies the DBMS, enumerates the schema (tables, columns, types), proves read access to the sensitive data and, when the privilege allows, evidences the path to maximum impact. The figure below summarizes the escalation pipeline.

FIGURE 3: SQL Injection escalation, from detection to impact demonstration

The listing below illustrates a proof of concept generated by Yaga for blind boolean-based extraction, against a laboratory target and for the purpose of demonstrating impact in the report:

Listing 7: illustrative proof of concept, Blind Boolean SQLi

8.2.1 From alert to real impact (XSS)

Yaga does not settle for an alert(1). The Exploit Builder demonstrates the real impact of the XSS according to context: session theft (cookie replay as admin), in-context phishing (a fake login inside the application itself), chaining with CSRF to perform actions as the victim, and, for Stored XSS, propagation (the payload self-replicates when other users view the content).

FIGURE 4: XSS impact escalation

8.2.2 From request to cloud compromise (SSRF)

Upon confirming an SSRF in a URL parameter, Yaga demonstrates the impact chain in stages: it confirms access to loopback services, performs an internal port scan of common ports, and attempts to reach the cloud metadata endpoint (169.254.169.254) to verify, by reading, whether temporary IAM credentials are exposed. Once the exposure is confirmed, Yaga records enough for the client to reproduce and fix it, without using the credentials beyond what is necessary to evidence the access. The entire flow happens within the authorized scope and serves to size the business impact (potential compromise of the cloud account) in the report.

9. Phase 6: Chain Engine, chaining web exploits

The Chain Engine is Yaga's most significant architectural differentiator. While Phases 4 and 5 operate on individual vulnerabilities, the Chain Engine reasons about combinations of vulnerabilities to build attack chains with maximum impact.

9.1 Attack graph model

The Chain Engine models vulnerabilities as nodes in a directed graph, where each node has preconditions (what is required before exploiting) and postconditions (what is obtained after exploiting). Edges connect the postconditions of one vulnerability to the preconditions of another, and the goal is to find paths from the initial state (anonymous access) to maximum-impact states (account takeover, data breach and the like).

FIGURE 5: Solved attack graph, a 5-vulnerability chain to Admin Takeover

9.2 Chain resolution algorithm

The Chain Engine combines three mechanisms: graph search (BFS/DFS) to enumerate possible paths between the initial state and the goal states; LLM reasoning to assess the practical viability of each path and to generate intermediate steps that formal search would not capture; and empirical validation, running each candidate chain against the real target to confirm the transitions work in practice.

9.2.1 Graphs and shortest path

The graph G = (V, E, w) uses a difficulty weight w(u, v) = (1 − P_exploit) × (1 + P_detect) × c_priv. The most likely attack path is the shortest path via Dijkstra, d(v) = min_u∈pred(v) [d(u) + w(u, v)]. Pivot nodes are identified by betweenness centrality:

C_B(v) = ∑_s≠v≠t σ_st(v) σ_st

fixing one pivot breaks multiple chains at once. Targets are prioritized by PageRank, PR(v) = (1 − d)/N + d ∑_u∈in(v) PR(u)/|out(u)|, with d = 0.85. The combined impact is multiplicative, I_chain = 1 − ∏_v∈path (1 − I(v)): three medium findings (I = 0.5) produce I_chain = 0.875 (high).

9.3 Common web chaining patterns

Yaga recognizes and prioritizes empirically validated chaining patterns. The five most recurrent, presented as impact chains (from the initial input to the final impact), are:

• Pattern 1, Information Disclosure → Authentication Bypass: an exposed debug endpoint or verbose error messages reveal secrets (API keys, database credentials, JWT secrets), which lead to administrative access via the leaked key.
• Pattern 2, XSS → CSRF → Privilege Escalation: a Stored XSS in the profile executes when an admin views the content, runs in the privileged context and triggers a request that creates a new admin account, resulting in persistent access.
• Pattern 3, SSRF → Internal Service → Cloud Compromise: an SSRF reaches the cloud metadata endpoint, obtains temporary IAM credentials and enables a pivot to storage and internal services, with the potential for a cross-tenant data breach.
• Pattern 4, SQL Injection → write privilege → path to RCE: Yaga confirms the SQLi and verifies, by reading, whether the database account holds disk write privilege. With the privilege confirmed, the path to remote code execution is open and the finding is classified as critical. The proof recorded for the report is the reading of the privilege and the writable path, not the writing of an artifact on the server.
• Pattern 5, Insecure Deserialization → RCE: a serialized cookie is identified by magic bytes, the classpath is inferred from errors, and the corresponding gadget chain is identified. Confirmation is done by an out-of-band signal (DNS or HTTP callback), which proves execution without persisting any artifact on the target. Applicable to Java, PHP, Python and .NET.

9.4 Chain Engine performance metrics (web)

Within the 150 web cases of the HackerSec benchmark, 45 involve vulnerability chaining:

TABLE IV: Web chaining results (N = 45 cases with a chain)

Burp Suite Pro in automated scan mode, without a human operator. The comparison with Burp Suite refers to the automated mode: with a human pentester operating the tool, the results would be different. The value of automation is not to replace the pentester, but to amplify their capacity and cover surfaces that manual analysis would not reach in the available time.

10. Protection evasion and report generation

Modern web applications are rarely unprotected. WAFs, CSPs, rate limiters and input validators are common defenses that neutralize most payloads from generic automated tools. Yaga implements adaptive evasion techniques and, at the end, consolidates everything into a professional pentest report.

10.1 Adaptive WAF bypass

When a payload is blocked by the WAF, Yaga does not abandon the test: it starts a refinement cycle. It analyzes the blocking pattern, generates a variant applying techniques such as URL/Unicode encoding, case alternation, comment insertion and payload splitting, and tests again, iterating until it confirms the bypass or exhausts the variants.

FIGURE 6: Adaptive WAF bypass cycle

10.2 CSP bypass

Content Security Policy is a critical defense against XSS. Yaga analyzes the application's CSP and identifies bypass vectors: CDN sources that allow loading arbitrary packages, endpoints that accept a callback and can be abused through JSONP/script gadgets, and policies with 'self' without 'strict-dynamic' or nonce/hash, which leave the protection weaker than it could be. The result is a list of vectors prioritized by probability of success given the rest of the observed policy.

10.2.1 Rate limiting detection

Rate limiting is detected via linear regression over response times (t_i = α + βi, with β > 0 indicating throttling) and via CUSUM, S_i = max(0, S_i−1 + (x_i − μ₀ − k)). A changepoint at S_i > h calibrates the maximum safe speed, r_max = changepoint / Δt.

10.3 Rate limiting bypass

For endpoints protected by rate limiting, Yaga tests IP rotation (via X-Forwarded-For, X-Real-IP headers), parameter pollution to work around cache-key-based counting, temporal distribution of requests below the threshold, and endpoint variation (the same resource reachable through different paths, such as /api/v1/login versus /api/v2/login).

10.4 Phase 7: proof of concept and report generation

Every confirmed vulnerability generates a complete PoC package: a self-contained reproduction script, the exact raw request/response pair, automated screenshots (for XSS and visual vulnerabilities, via a headless browser), the chain diagram (for chained vulnerabilities) and the classification (OWASP category, CWE ID, computed CVSS score). Before it reaches the client, every finding goes through validation by a HackerSec specialist, who confirms the exploitation and the assigned classification.

10.4.1 Contextual CVSS 4.0

Yaga computes CVSS 4.0 by filling the metric groups with real evidence collected during the pentest, instead of leaving them as "Not Defined" (the generic scanner default, which equals the worst case and inflates severity). The Threat group (Exploit Maturity) is derived from the real exploitation result obtained by the agent; the Environmental group (Confidentiality, Integrity and Availability Requirements, plus the Modified Base Metrics) is derived from the asset's data classification and the controls effectively observed at runtime: a component behind a WAF raises Attack Complexity, and regulated data (LGPD/GDPR) forces the Confidentiality Requirement to High. This contextualization is the same methodological basis described in the article on Yaga's contextual criticality methodology, applied here to the web axis.

10.4.2 Report structure

The final report follows the professional pentest format, in six blocks: (1) Executive Summary (scope, summary of findings by severity, overall risk and recommendation); (2) Methodology (tools, test coverage, limitations); (3) Detailed findings by severity, each with title and classification (OWASP/CWE/CVSS), technical description, affected endpoint and parameter, proof of concept, demonstrated impact, exploitation chain where applicable and remediation recommendation; (4) Exploitation chains (diagram of each chain, combined versus individual impact, chain-based remediation prioritization); (5) Attack surface analysis (endpoint map, technology profile, overall posture); and (6) Appendices (relevant requests/responses, complete PoC scripts, tool configurations).

11. Case studies and benchmark results

The studies below illustrate Yaga's complete pipeline against realistic scenarios from the HackerSec benchmark. We then present the quantitative results over the 150 web cases and the comparison with traditional tools. The methodological caveat that applies across YagaBench is worth restating: a vulnerability only enters the count when it has actually been exploited and confirmed by a HackerSec specialist.

11.1 E-commerce: from XSS to mass account takeover

Target: e-commerce platform (PHP + Laravel + MySQL + Vue.js). During reconnaissance, Yaga discovers 47 API endpoints, the admin panel at /nova and a debug endpoint (/telescope) accessible without authentication. Profiling identifies Laravel 9.x, PHP 8.1, MySQL 8.0, Vue 3.x and Sanctum. HTTP analysis reveals tokens with SameSite=Lax (not Strict) and a CSRF token present but not validated on API routes.

Vulnerabilities: Stored XSS in the "product name" field (admin input, displayed to everyone), missing CSRF on POST /api/user/email/update, exposed debug endpoint and IDOR in GET /api/orders/{id}. Chain: Yaga obtains the application key through the debug endpoint, the Stored XSS is viewed by users and admins, it performs the victim's email change via CSRF, requests a password reset and, with access to the account, escalates to admin via the IDOR on the roles endpoint. Impact: mass account takeover, any visitor who views the compromised product has their account hijacked. No individual vulnerability would be Critical; the chain of 5 results in Critical impact.

11.2 Financial API: from Blind SQLi to data breach

Target: financial REST API (Node.js + Express + PostgreSQL + JWT). Reconnaissance finds 23 endpoints documented via an exposed Swagger; profiling identifies Express 4.18, PostgreSQL 15 and Sequelize ORM (with raw queries on 2 endpoints). Vulnerabilities: Blind SQLi (boolean-based) in GET /api/transactions?search=, accessible JWT public key, user enumeration via timing and excessive data exposure in /api/users/:id. Chain: the SQLi grants read access to the schema, to the users table (bcrypt hashes, balances) and to the service API keys table with elevated permissions; those keys reach admin endpoints capable of exporting the client base. Yaga records only the samples necessary to prove the access. Impact: financial data of every client exposed from a single search parameter. Total exploitation time: 23 minutes (with GPT 6 as the backend).

11.3 Multi-tenant SaaS: from SSRF to cloud compromise

Target: SaaS application (Python + Django + Redis + AWS), deployed on ECS Fargate. Vulnerabilities: SSRF in the "import data via URL" feature (POST /api/import), internal Redis without authentication and an IAM role with excessive permissions. Chain: the SSRF reaches the cloud metadata, obtains the temporary credentials of the container's IAM role, enumerates storage buckets and finds one with data from all tenants, evidencing cross-tenant read access; additionally, through the same SSRF, it reaches the internal Redis. Impact: compromise of all tenants' data. The SSRF in isolation would be High; with access to cloud credentials and an internal service, the impact is Critical.

11.4 Accuracy by OWASP Top 10 category

TABLE V: Yaga web detection by OWASP category (N = 150)

11.5 Detailed XSS performance

XSS has historically been one of the hardest vectors to automate. Yaga reaches 97.6% resolution, outperforming Burp Suite Pro by 49.4 percentage points, with the largest gaps in mXSS (100% versus 25%) and Blind XSS (90% versus 30%).

TABLE VI: XSS detection by subtype

11.6 Performance by LLM backend

TABLE VII: Web accuracy by LLM backend (N = 150)

Opus 5 leads in detection rate and chain accuracy in web scenarios (predominantly black-box). GPT 6 is about 7% faster, maintaining comparable accuracy.

11.7 Comparison with traditional tools

TABLE VIII: Yaga versus traditional tools (150 web scenarios)

The comparison highlights two distinct paradigms: pointwise detection via signatures versus contextual exploitation via reasoning. Nuclei and Nikto finish quickly, but detect only vulnerabilities with pre-existing templates. Burp Suite Pro is significantly more capable, but it still depends on static rules and does not perform autonomous chaining.

12. Limitations, future work and conclusion

12.1 Current limitations

• Complex business logic: vulnerabilities that require deep understanding of a specific domain (for example, manipulation of accounting rules) remain challenging. The detection rate for business logic flaws drops to 85% in highly specialized scenarios.
• JavaScript-heavy applications: SPAs with multi-step flows that require precise UI interaction (drag-and-drop, canvas, WebGL) may not be fully explored by the crawler.
• Aggressive rate limiting: targets with extremely restrictive limits (under 10 req/min) force the pipeline to operate at reduced speed, increasing the total assessment time.
• Zero-days in modern frameworks: Yaga detects known CVEs with over 98% accuracy, but discovering zero-days in well-maintained frameworks remains rare in black-box mode.
• Computational cost: each complete web assessment with a frontier backend consumes between US$ 15 and US$ 40 in LLM tokens, depending on the complexity of the application.

12.2 Future directions

• Vertical fine-tuning: models tuned for specific domains (fintech, healthcare, e-commerce) to improve business logic detection.
• Visual understanding: integration with multimodal models to analyze the rendered UI, not just the DOM and HTTP.
• Real-time steering interfaces: deepening the collaboration between the HackerSec specialist and Yaga during the operation, making even more fluid the human direction that already guides the agent's offensive strategy, combining the specialist's intuition with Yaga's execution speed.
• Continuous monitoring mode: operation as part of the CI/CD pipeline, assessing every deploy automatically.

12.3 Conclusion

The seven-phase pipeline describes a complete web pentest, conducted end to end by the agent itself: Yaga reasons about the application, understands its architecture, builds tailored exploits and chains vulnerabilities into maximum-impact sequences. The numbers support the thesis: 98% accuracy across 150 web scenarios, 97.6% in XSS and 93.3% in chaining. The architecture implements PTES, WSTG, ASVS and CWE end to end, enabling conformance with PCI DSS 11.3, SOC 2 and ISO 27001 A.12.6.

The central innovation is the Knowledge Graph and the Chain Engine operating together. Yaga does not deliver a flat list of disconnected findings: it transforms each finding into a demonstrable attack graph: not "there is an XSS and a missing CSRF token", but "an anonymous attacker injects JavaScript into the profile, executes as admin and forges a request that creates an admin account, five steps from anonymity to full control". The YagaBench v2.8 results confirm that orchestration matters more than the model: isolated models reach 27% to 58%, and Yaga raises that to 97% to 98.8%, a multiplication of 2x to 3.6x.

Yaga represents the convergence of LLM reasoning with a structured offensive methodology. As models evolve, the architecture ensures that improvements translate into superior results. The future is not to replace the pentester, but to amplify: Yaga executes in minutes what would take days, while HackerSec specialists direct the strategy, follow the operation, validate each finding before delivery and continuously refine the agent's offensive capability, freeing the specialist for complex business logic and strategic threat modeling.

References