How ZeroThreat Finds, Validates, and Chains Vulnerabilities in OWASP Juice Shop

Illustrative Sample: This walkthrough uses OWASP Juice Shop, a deliberately vulnerable application published by OWASP for training and scanner benchmarking. Every issue shown is a real, publicly documented Juice Shop vulnerability, used here to demonstrate how ZeroThreat's engine works. No CVEs are claimed. Confirm all findings, payloads, and timings against a live scan before publishing, then remove this banner.

TL;DR

• ZeroThreat was pointed at a standard OWASP Juice Shop instance with no test scripts written in advance.
• It surfaced four high-impact issues: a critical SQL injection in the login endpoint, broken object-level authorization in the basket API, JWT algorithm confusion, and stored XSS in product reviews.
• Each was validated by controlled exploitation, not flagged on a signature. The login injection returns an administrator token whose password hash cracks offline to a weak value.
• Chained together, an unauthenticated request becomes full administrative control of the store.

OWASP Juice Shop is one of the most widely used intentionally vulnerable applications in security, written in Node.js, Express, and Angular with a full REST API behind it. That makes it a fair test of a modern scanner: most of its risk lives behind authentication and inside multi-step workflows, exactly where signature-based tools tend to stop. An unauthenticated crawl reaches only a fraction of the real attack surface.

We used ZeroThreat’s AI-powered pentesting tool against a default Juice Shop instance to show how its engine behaves on a realistic single-page application: how it reaches authenticated functionality without pre-written scripts, how it confirms each issue by exploiting it, and how it connects separate findings into a single path to takeover. Every finding below was validated, not merely detected. What follows is four confirmed weaknesses and the chain they form, ending in complete administrative access.

You’ve seen what ZeroThreat can find in Juice Shop. Now find out what’s hiding in your own application. Test My App

What We Tested Using ZeroThreat’s AI-Powered Pentesting?

ZeroThreat tested a default OWASP Juice Shop instance, covering the Angular front end and its REST API across both unauthenticated and authenticated states. The engine drove the application's multi-step flows the way a real user would, registering an account, logging in, adding items to a basket, and posting reviews, without any pre-written Playwright specs or manual test cases. That is what carried testing past the login wall into the REST endpoints where most of Juice Shop's real risk lives.

What ZeroThreat Found?

AI penetration testing confirmed four high-impact vulnerabilities in Juice Shop, one critical and three high. The table below is the map; each row is expanded in its own section, and the section after that shows how they combine into a single path to admin.

Vulnerability #1: SQL Injection in the Login Endpoint

Severity: Critical

Class: CWE-89

Endpoint: POST /rest/user/login

The email field on the login endpoint is concatenated directly into an SQL query, so a crafted value bypasses authentication and returns a valid session for the first matching account.

Affected Functionality:

User authentication. The login handler constructs its database query directly from the submitted email without using parameterized queries. As a result, an attacker can manipulate the input to terminate the string and comment out the password check, causing the injected input to be interpreted as SQL logic.

How It Works:

The query effectively becomes a lookup for a user whose email matches attacker-controlled input. A trailing comment removes the password condition entirely, and the OR clause makes the row selection always true. The first row returned is the administrator, so the application issues a session for that account.

Exploitation Flow:

POST /rest/user/login  Content-Type: application/json{  "email": "' OR 1=1--", "password": "anything"   }\  -> 200 OK  \-> { "authentication": {  "token": "<JWT for admin>", "umail": "admin@juice-sh.op"  }  }

Evidence:

The response returns an authenticated JWT for the administrator account together with the admin email, with no valid password ever supplied. The token payload includes the account's stored password hash.

Security Impact:

Complete authentication bypass against the highest-privilege account in the application, with no credentials. In a real store, this is the difference between a locked front door and one that opens anyone who knocks in a certain way.

Remediation:

Use parameterized queries or an ORM for every database interaction, so user input is never interpolated into SQL text. Reject authentication inputs containing SQL metacharacters at the boundary, and store passwords with a slow, salted hash, so a leaked hash resists offline cracking.

Finding isolated vulnerabilities is only half the story. See how AI can connect them into real attack paths. Explore AI-Powered Pentesting

Vulnerability #2: Broken Object-level Authorization in the Basket API

Severity: High

Class: CWE-639 / BOLA

Endpoint: GET /rest/basket/{id}

The basket API returns a basket by its numeric id without checking that the id belongs to the requesting user, so any authenticated user can read another user's basket by changing one number.

Affected Functionality:

Shopping basket retrieval. The endpoint trusts the object id in the URL and the identity in the session token separately, but never confirms the two match.

How It Works:

Authorization is enforced at the route (you must be logged in) but not at the object (you must own this basket). Incrementing or decrementing the id walks through other customers' baskets. This is Broken Object Level Authorization, the top risk in the OWASP API Security Top 10.

Exploitation Flow:

GET /rest/basket/1  Authorization: Bearer <low-privilege user token>  -> 200 OK  -> { "data": { "id": 1, "items": \[ ... another user's basket ... \]  }  }

Evidence:

A low-privilege account, authenticated to its own basket, successfully reads baskets belonging to other user ids and receives their contents in full.

Security Impact:

Horizontal access to other customers' data. At scale, enumerating ids exposes the order and cart data of the entire user base, a direct privacy and compliance exposure.

Remediation:

Enforce object-level ownership on every request: derive the basket from the authenticated session or verify that the requested id is owned by the caller before returning it. Never rely on the client to supply a trustworthy object of reference.

Vulnerability #3: JWT Algorithm Confusion

Severity: High

Class: CWE-347

Component: Token verification

Token verification can be tricked into accepting a token signed with the public key using HS256, letting an attacker forge a valid token for any account without the private key.

Affected functionality:

Session token validation. Tokens are issued with RS256 (asymmetric signing), but the verifier does not strictly pin the expected algorithm.

How It Works:

The RSA public key is, by design, public. If the verifier accepts HS256, an attacker signs a forged token using that public key as the HMAC secret. The verifier, expecting to check a signature against the public key, validates it. The attacker sets the account claim to the administrator and is trusted as an admin.

Exploitation Flow:

1\. Retrieve the server's RSA public key.  2\. Craft a JWT with header {"alg":"HS256"} and payload claiming the admin account.  3\. Sign it using the public key bytes as the HMAC-SHA256 secret.  4\. Send the forged token as the session bearer.  -> Accepted as the administrator. Evidence

A token the attacker generated locally, never issued by the server, is accepted for an administrator session on protected endpoints.

Security Impact:

Account takeover of any user, including admin, independent of the login flow. Even after the SQL injection is fixed, this alone re-opens the path to administrative access.

Remediation:

Pin the accepted algorithm explicitly in the verifier and reject any token whose header algorithm differs. Keep asymmetric verification keyed only to the public key for signature checking, never as an HMAC secret.

The cost of finding vulnerabilities is predictable. The cost of discovering them after an attack isn’t. Check Pricing

Vulnerability #4: Stored XSS in Product Reviews

Severity: High

Class: CWE-79

Endpoint: Product review submission

A product review stores user input and renders it back to other shoppers without encoding, so a review containing script markup executes in every viewer's browser.

Affected Functionality:

Product reviews. Submitted review text has persisted and later rendered into the page for anyone who views that product.

How It Works:

Input is neither sanitized on write nor encoded on output. A payload placed in the review body is stored verbatim and injected into the DOM when the product page loads, running in the context of each visitor's authenticated session.

Exploitation Flow:

Review body:  <iframe src="javascript:alert(document.domain)">  -> Stored and served to every viewer of the product page,executing in their session context.

Evidence:

The stored payload executes load for a separate user account viewing the product, confirming persistence and cross-user execution rather than a one-off reflected echo.

Security Impact:

Any visitor to the affected product becomes a target. In a session where a victim holds an active token, stored XSS can drive actions as that user, including reading or exfiltrating session data.

Remediation:

Encode output contextually when rendering user content, sanitize input against an allowlist, and add a Content Security Policy that blocks inline script execution as defense in depth.

From Individual Findings to an Attack Chain

Read alone - Each finding is serious. Read together - They are a single unbroken path from an anonymous visitor to full control of the store.

An attacker starts with no account. The SQL injection in the login endpoint (Finding 1) bypasses authentication and returns an administrator token whose payload carries the account's password hash. Because that hash is fast and unsalted, it cracks offline to a weak value, giving durable admin credentials rather than a single session. From there, the basket authorization flaw (Finding 2) demonstrates the data already reachable across the user base, and the JWT algorithm confusion (Finding 3) provides a second, independent way back into an admin session even if the login flaw is later patched. The result is not four issues to triage separately; it is one takeover with a backup key.

How ZeroThreat’s Web App Pentesting Validated the Findings?

ZeroThreat’s web app pentesting does not report a vulnerability until it has proven the vulnerability is real by exploiting it in a controlled way and confirming the impact.

That is what separates these four findings from the noise a signature scanner would produce against the same target. Each one ran through the same pipeline before it earned a place in this report:

Think your application would survive the same test? Put ZeroThreat against your attack surface and find out. Book a Demo

Conclusion

OWASP Juice Shop makes the point clean: the vulnerabilities that matter most rarely sit on the surface. They live behind authentication and inside multi-step workflows, and their real severity only shows when separate issues connect into a single path to takeover.

Reaching them takes an engine that drives an application the way a real user does and then confirms each finding by exploiting it, so what reaches the report is evidence rather than a pile of unverified alerts.

That is exactly how ZeroThreat’s AI penetration testing tool works against your own web apps and APIs. It discovers the deep, workflow-dependent issues, validates them to keep false positives near zero, maps them to business impact, and hands your team the attack chain alongside the fix. See what it surfaces in your own application. Sign up for free and run your first scan in minutes.