See what a web Agentic Deep Scan report looks like
A 227-page assessment of VulnBank, a deliberately vulnerable banking app and its API. It shows how each finding is proven with requests you can rerun, scored, and traced to its root cause.
- Target
- VulnBank web app and API
- Scan
- Web Agentic Deep Scan
- Length
- 227 pages
- Result
- Overall risk: critical
Run on a deliberately vulnerable demo target. No customer data.
What's inside
Executive summary
The overall risk, the main attack paths and what to fix first, up front.
Findings table
Every finding with its risk, CVSS score, status and a short description.
Proven exploits
Detailed write-ups of the top critical and high issues, with evidence and business impact.
How to fix
The root cause of each finding and how to fix it, with reproduction steps you can rerun.
Annotated finding
One finding, step by step
How the report takes a single finding from the target that was tested to the fix. Each step points to its page in the full report.
- Target
vulnbank.org, a live demo bank
A deliberately vulnerable online-banking app and API built for security training, tested live. The report records its features and the technology observed behind it.
Report page 2 - Scope
One domain, every endpoint found on it
Sign-in, transfers, loans, cards, uploads, the admin panel and the AI-agent API, tested from 14 December 2025 to 16 March 2026 without test credentials. Subdomains were out of scope.
Report page 2 - Method
Every finding comes with its proof
Agents explore the app and attempt each attack. Confirmed findings include the requests that reproduce them and validation attempts; leads that could not be confirmed are marked as potential.
Report page 7 - Workflow
Sign-in and access control
The finding sits in the sign-in and authorization layer that protects every request, including the admin functions.
Report page 48 - Finding
Critical (CVSS 9.8): access tokens not verified
The server accepted access tokens without checking that they were genuine, so the admin panel and admin actions were reachable without an account.
Report page 48 - Evidence
The requests and responses that prove it
The report shows the trimmed requests and responses from the scan: a request without a valid token is rejected, then the check is bypassed and an admin action succeeds.
Report page 49 - Fix
Verify every token, check roles on the server
The report traces the flaw to tokens decoded without checking their signature, and to authorization that trusts the is_admin claim inside the token. The fix: verify every signature and load the user's role on the server.
Report page 58 - Status
Scored, mapped and tracked
The findings table lists each issue with its risk, CVSS score, status and a short description.
Report page 20
How the agent decided
Why this counts as a risk
A scanner reports whatever matches a rule. Before reporting, the agent checks that a clue leads to real harm and rules out the harmless explanations. Here is how it reasoned about one finding on vulnbank.org.
Step 1
Why does the balance page answer without a login?
GET /check_balance/<account number> returned 200 with another user's username and balance, with no token and no cookie.
Report page 23Step 2
Could it be a cached copy?
The agent sent the request again with no-cache headers and a unique nonce. The response said cf-cache-status: DYNAMIC, so it came from the server, not from a cache.
Report page 24Step 3
Is the endpoint just lenient about tokens?
A request with a made-up token, Bearer invalid, got the same 200 and the same data. The endpoint doesn't check the token at all.
Report page 24Step 4
Is this real data or a static demo?
Signed in as one user, the agent made a 12.34 transfer, then read that user's transactions without logging in. The new transaction was there.
Report page 25Step 5
Why does it happen?
POST /transfer rejects a missing token with 401, so authentication exists, but it isn't applied to these two reads. The API specification lists them with no security.
Report page 26Step 6
So, is it a risk?
Yes, Critical. Anyone on the internet can read account balances and transaction histories, and use 200 versus 404 answers to find valid account numbers.
Report page 27Step 7
What fixes it?
Require a valid token on both endpoints and return 401 without one. Then check that the account belongs to the caller, and return 403 if it doesn't.
Report page 27
Want this report for your own app?
Book a demo and we'll walk you through a scan of your mobile app, web app or API.