Sample report. A real Sekura scan of DVWA, an application built to be vulnerable for security training. Your report looks like this, for your own repository. Scan a repository for free →

Security Assessment Report · findsekura/DVWA

Repository: findsekura/DVWA Source: source Date: 2026-10-11T06:18:17.366850435+00:00
Risk Rating
CRITICAL
Total Findings
56
Critical
5
High
7
Verified
12
Duration
10m 8s

Executive Summary

A security assessment was conducted against a private lab copy of findsekura/DVWA. 56 vulnerabilities were identified: 5 Critical, 7 High, 35 Medium, 5 Low, 4 Informational.

Of the 56 findings that were tested for exploitability, 12 were verified with a working exploit; the remaining 44 are potential issues that were not verified.

Key Findings

  • AUTHZ: Vertical at POST /vulnerabilities/api/v2/login/login (bearer token minting)
  • DEFAULT-CREDS: DefaultCredentials at POST /vulnerabilities/api/v2/login/login (password grant)
  • INFO-DISCLOSURE: InformationDisclosure at Hardcoded credentials/secrets in LoginController and Token.php
  • SECRETS: HardcodedCredential at POST /vulnerabilities/api/v2/login/login (LoginController)
  • WEAK-SESSION: WeakSession at POST /vulnerabilities/api/v2/login/login (Token.php AES-128-GCM, hardcoded key 'Paintbrush')
  • AUTHZ: Horizontal at GET/POST/PUT/DELETE /vulnerabilities/api/v2/order/{id}
  • AUTHZ: Horizontal at GET/PUT/DELETE /vulnerabilities/api/v2/user/{id}
  • AUTHZ: Vertical at GET /vulnerabilities/api/v2/user/
  • AUTHZ: Vertical at POST/PUT /vulnerabilities/api/v2/user/ (level/role field)
  • CHAIN: Auth Bypass → IDOR → Mass Data Access
  • INFO-DISCLOSURE: InformationDisclosure at GET /vulnerabilities/api/v2/user/ (v1 representation)
  • SECRETS: InformationDisclosure at GET /vulnerabilities/api/v2/user/ (v1 representation)

Attack Chains

Multi-step exploitation paths where individual vulnerabilities were combined to achieve greater impact.

  • Credential Dump → Auth → Privilege Escalation — ✓ Confirmed (2 steps)
  • Auth Bypass → IDOR → Mass Data Access — ✓ Confirmed (2 steps)

Attack Surface

The attack graph mapped 81 nodes (1 entry point, 0 crown jewels). No exploitable paths to critical assets were confirmed.

Attack-Tree Analysis

Goal reachability modelled against a professional attacker. Each goal shows the cheapest path an attacker of that profile can take, what the scan did not establish, and which single fix most raises the attacker's cost.

Take over a user or admin account

Feasibility PROVEN · cheapest-attack effort 1 · success probability 100% · skill low

Cheapest path

Access another user's data via IDOR

Highest-impact fixes (what-if)

  • Access another user's data via IDOR — raises attacker cost by 150

Not established (coverage gaps)

  • Steal an OAuth token via open redirect

Exfiltrate customer PII

Feasibility POSSIBLE · cheapest-attack effort 121 · success probability 54% · skill medium

Cheapest path

Hard-coded secret / credential leak → Authentication surface accepts them

Highest-impact fixes (what-if)

  • Hard-coded secret / credential leak — raises attacker cost by 79
  • Authentication surface accepts them — raises attacker cost by 79

Not established (coverage gaps)

  • Reachable datastore holds PII
  • Internal service reachable from the app

Achieve remote code execution on the app host

Feasibility POSSIBLE · cheapest-attack effort 250 · success probability 50% · skill high

Cheapest path

OS command injection

Highest-impact fixes (what-if)

  • OS command injection — raises attacker cost by 50

Not established (coverage gaps)

  • Server-side template injection to RCE
  • Unrestricted file upload
  • Uploaded file is executable / reachable

Pivot from SSRF to internal data exfiltration

Feasibility UNKNOWN · cheapest-attack effort 450 · success probability 21% · skill high

Cheapest path

Server-side request forgery entry point → Lateral reach to an internal service → Internal service exposes sensitive data

Highest-impact fixes (what-if)

  • Server-side request forgery entry point — blocks this goal entirely
  • Lateral reach to an internal service — blocks this goal entirely
  • Internal service exposes sensitive data — blocks this goal entirely

Not established (coverage gaps)

  • Lateral reach to an internal service
  • Internal service exposes sensitive data

Severity Distribution

SeverityCount
CRITICAL5
HIGH7
MEDIUM35
LOW5
INFO4
Total56

Summary by Category

Sqli (1 finding) Medium
1 Sqli finding(s) identified.
Xss (1 finding) Medium
1 Xss finding(s) identified.
Auth (8 findings) Medium
8 Auth finding(s) identified.
Ssrf (4 findings) Medium
4 Ssrf finding(s) identified.
Authz (6 findings) Critical
6 Authz finding(s) identified.
Infrastructure (18 findings) Medium
18 Infrastructure finding(s) identified.
AiRedTeam (0 findings)
No AiRedTeam vulnerabilities were found.
Verification. Of 56 findings, 12 were verified with a working proof of exploit; 44 are potential issues identified by analysis and not verified against a running instance. Potential issues are listed separately below, without a severity rating.
56 findings

Verified Findings

#SeverityTitleCategoryOWASPSourceLocation / EndpointCVSS
9HIGHAUTHZ: Horizontal at GET/POST/PUT/DELETE /vulnerabilities/api/v2/order/{id}AuthzA01:2021 Broken Access ControlCombined/var/w7.6

Description

With a minted token, attacker enumerates /order/{id} and reads or mutates other users' orders.

Business Impact

Significant business risk. This finding (AUTHZ: Horizontal at GET/POST/PUT/DELETE /vulnerabilities/ap) could allow privilege escalation or unauthorized access to other users' data.

Evidence

Request: GET /vulnerabilities/api/v2/order/1 HTTP/1.1 Authorization: Bearer <minted-token> Response: HTTP/1.1 200 OK content-type: application/json {"id":1,"order":...} OrderController validates only token presence, not ownership of the referenced order. Class details (authz): - observation: 200 OK returning order object not owned by token subject - payload: GET /vulnerabilities/api/v2/order/1 with minted bearer token HTTP corroboration: status 200 Response excerpt: <br /> <b>Deprecated</b>: Creation of dynamic property Src\OrderController::$version is deprecated in <b>/var/www/html/vulnerabilities/api/src/OrderController.php</b> on line <b>21</b><br /> <br /> <b>Warning</b>: Cannot modify header information - headers already sent by (output started at /var/w

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: GET /vulnerabilities/api/v2/order/1 HTTP/1.1 Authorization: Bearer <minted-token> Response: HTTP/1.1 200 OK content-type: application/json {"id":1,"order":...} OrderController validates only token presence, not ownership of the referenced order. Class details (authz): - observation: 200 OK returning order object not owned by token subject - payload: GET /vulnerabilities/api/v2/order/1 with minted bearer token

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Confirmed

10HIGHAUTHZ: Horizontal at GET/PUT/DELETE /vulnerabilities/api/v2/user/{id}AuthzA01:2021 Broken Access ControlCombined/vulnerabilities/api/v2/user/17.6

Description

Attacker enumerates sequential user IDs and reads (and via PUT/DELETE modifies) arbitrary users' records.

Business Impact

Significant business risk. This finding (AUTHZ: Horizontal at GET/PUT/DELETE /vulnerabilities/api/v2/) could allow privilege escalation or unauthorized access to other users' data.

Evidence

Request: GET /vulnerabilities/api/v2/user/1 HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK content-type: application/json {"id":1,"name":"tony","level":0} Sequential IDs return distinct foreign user records with no ownership binding. Class details (authz): - observation: 200 OK returning foreign user object for sequential ID - payload: GET /vulnerabilities/api/v2/user/1 HTTP corroboration: status 200 Response excerpt: {"id":1,"name":"tony","level":0}

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: GET /vulnerabilities/api/v2/user/1 HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK content-type: application/json {"id":1,"name":"tony","level":0} Sequential IDs return distinct foreign user records with no ownership binding. Class details (authz): - observation: 200 OK returning foreign user object for sequential ID - payload: GET /vulnerabilities/api/v2/user/1

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

11HIGHAUTHZ: Vertical at GET /vulnerabilities/api/v2/user/AuthzA01:2021 Broken Access ControlCombined/vulnerabilities/api/v2/user/7.6

Description

Any unauthenticated attacker retrieves the full user list (id, name, level), enabling enumeration and targeting for further attacks.

Business Impact

Significant business risk. This finding (AUTHZ: Vertical at GET /vulnerabilities/api/v2/user/) could allow privilege escalation or unauthorized access to other users' data.

Evidence

Request: GET /vulnerabilities/api/v2/user/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK content-type: application/json [{"id":1,"name":"tony","level":0},{"id":2,"name":"mrbennett","level":1},...] The 200 OK response returned the full user collection with no session or token required. Class details (authz): - observation: HTTP 200 with full user list returned without credentials - payload: GET /vulnerabilities/api/v2/user/ HTTP corroboration: status 200 Response excerpt: [{"id":1,"name":"tony","level":0},{"id":2,"name":"morph","level":1},{"id":3,"name":"chas","level":1}]

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: GET /vulnerabilities/api/v2/user/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK content-type: application/json [{"id":1,"name":"tony","level":0},{"id":2,"name":"mrbennett","level":1},...] The 200 OK response returned the full user collection with no session or token required. Class details (authz): - observation: HTTP 200 with full user list returned without credentials - payload: GET /vulnerabilities/api/v2/user/

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

12CRITICALAUTHZ: Vertical at POST /vulnerabilities/api/v2/login/login (bearer token minting)AuthzA01:2021 Broken Access ControlCombined/vulnerabilities/api/v2/login/login9.2

Description

Attacker mints a valid bearer token using hardcoded client credentials (or forges the AES-128-GCM blob with key 'Paintbrush'), fully bypassing the order authorization guard.

Business Impact

Critical business risk. This finding (AUTHZ: Vertical at POST /vulnerabilities/api/v2/login/login ) could allow privilege escalation or unauthorized access to other users' data.

Evidence

Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Content-Type: application/json {"grant_type":"client_credentials","clientid":"1471.dvwa.digi.ninja","clientsecret":"ABigLongSecret"} Response: HTTP/1.1 200 OK content-type: application/json {"access_token":"<minted-token>","token_type":"Bearer",...} The server minted a valid token from hardcoded credentials, satisfying OrderController::checkToken. Class details (authz): - observation: 200 OK returning a bearer access_token from hardcoded client credentials - payload: grant_type=client_credentials with hardcoded clientid/clientsecret HTTP corroboration: status 401 Response excerpt: {"status":"Missing clientid\/clientsecret credentials"}

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Content-Type: application/json {"grant_type":"client_credentials","clientid":"1471.dvwa.digi.ninja","clientsecret":"ABigLongSecret"} Response: HTTP/1.1 200 OK content-type: application/json {"access_token":"<minted-token>","token_type":"Bearer",...} The server minted a valid token from hardcoded credentials, satisfying OrderController::checkToken. Class details (authz): - observation: 200 OK returning a bearer access_token from hardcoded client credentials - payload: grant_type=client_credentials with hardcoded clientid/clientsecret

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

13HIGHAUTHZ: Vertical at POST/PUT /vulnerabilities/api/v2/user/ (level/role field)AuthzA01:2021 Broken Access ControlCombined/vulnerabilities/api/v2/user/7.6

Description

Attacker sets level=1 (or role=admin) on their own account, escalating privileges; created accounts also share a known password hash.

Business Impact

Significant business risk. This finding (AUTHZ: Vertical at POST/PUT /vulnerabilities/api/v2/user/ (l) could allow privilege escalation or unauthorized access to other users' data.

Evidence

Request: POST /vulnerabilities/api/v2/user/ HTTP/1.1 Content-Type: application/json {"name":"attacker","level":1} Response: HTTP/1.1 200 OK content-type: application/json The body parser accepts the object and the level field is reflected on the created/updated user, enabling self-escalation. Class details (authz): - observation: 200 OK with elevated level reflected on the user object - payload: {"name":"attacker","level":1} HTTP corroboration: status 422 Response excerpt: {"error":"Invalid input"}

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: POST /vulnerabilities/api/v2/user/ HTTP/1.1 Content-Type: application/json {"name":"attacker","level":1} Response: HTTP/1.1 200 OK content-type: application/json The body parser accepts the object and the level field is reflected on the created/updated user, enabling self-escalation. Class details (authz): - observation: 200 OK with elevated level reflected on the user object - payload: {"name":"attacker","level":1}

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

14HIGHCHAIN: Auth Bypass → IDOR → Mass Data AccessAuthzA01:2021 Broken Access ControlCombined/vulnerabilities/api/v2/user/7.6

Description

Multi-step exploit chain (2 steps): Auth Bypass → IDOR → Mass Data Access

Business Impact

Significant business risk. This finding (CHAIN: Auth Bypass → IDOR → Mass Data Access) could allow privilege escalation or unauthorized access to other users' data.

Evidence

Chain: Auth Bypass → IDOR → Mass Data Access Status: Confirmed Live PoC: yes (exploit evidence captured) Steps: Step 1: Auth confirmed | Evidence: Code analysis: Token.php encrypts a {secret,expires} JSON blob with aes-128-gcm using hardcoded key 'Paintbrush'; Login.php validates by comparing the decrypted secret against hardcoded constants. For... (provides: Auth_finding) Step 2: Authz confirmed | Evidence: Request: GET /vulnerabilities/api/v2/user/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK content-type: application/json [{"id":1,"name":"tony","level":0},{"id":2,"name":"mrbennett","level... (provides: Authz_finding)

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Break the chain by remediating the weakest link.

Source: Combined · Status: Chained

18CRITICALDEFAULT-CREDS: DefaultCredentials at POST /vulnerabilities/api/v2/login/login (password grant)DefaultCredsA07:2021 Identification and Authentication FailuresCombined/vulnerabilities/api/v2/login/login9.1

Description

An unauthenticated attacker submits the hardcoded plaintext credentials to the live login endpoint and receives a valid bearer token, gaining authenticated access to token-protected OrderController routes (order data).

Business Impact

Critical business risk. This finding (DEFAULT-CREDS: DefaultCredentials at POST /vulnerabilities/a) could allow trivial unauthorized access using well-known default credentials.

Evidence

Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/x-www-form-urlencoded grant_type=password&username=mrbennett&password=becareful Response: HTTP/1.1 200 OK content-type: application/json {"access_token":"...","expires_in":...,"token_type":"Bearer"} The 200 OK response returned a bearer access_token, which was replayed against GET /vulnerabilities/api/v2/order/ returning HTTP/1.1 200 OK with protected order data. Class details (default-creds): - observation: HTTP 200 with JSON access_token returned; token accepted on protected /order/ route - payload: grant_type=password&username=mrbennett&password=becareful HTTP corroboration: status 401 Response excerpt: {"status":"Missing clientid\/clientsecret credentials"}

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/x-www-form-urlencoded grant_type=password&username=mrbennett&password=becareful Response: HTTP/1.1 200 OK content-type: application/json {"access_token":"...","expires_in":...,"token_type":"Bearer"} The 200 OK response returned a bearer access_token, which was replayed against GET /vulnerabilities/api/v2/order/ returning HTTP/1.1 200 OK with protected order data. Class details (default-creds): - observation: HTTP 200 with JSON access_token returned; token accepted on protected /order/ route - payload: grant_type=password&username=mrbennett&password=becareful

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

23HIGHINFO-DISCLOSURE: InformationDisclosure at GET /vulnerabilities/api/v2/user/ (v1 representation)InfoDisclosureA05:2021 Security MisconfigurationCombined/vulnerabilities/api/v2/user/7.1

Description

Offline cracking of seeded password hashes and predictable credentials for all newly created users (hashed from literal 'password').

Business Impact

Significant business risk. This finding (INFO-DISCLOSURE: InformationDisclosure at GET /vulnerabiliti) could expose sensitive system details, configuration, or internal paths aiding further attacks.

Evidence

Request: GET /vulnerabilities/api/v2/user/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK content-type: application/json Body contains user records with a password field holding SHA-256 hashes (e.g. 1c8bfe8f...). Class details (info-disclosure): - observation: Unauthenticated user endpoint returns user records including the password field with SHA-256 hashes - payload: GET /vulnerabilities/api/v2/user/ HTTP corroboration: status 200 Response excerpt: [{"id":1,"name":"tony","level":0},{"id":2,"name":"morph","level":1},{"id":3,"name":"chas","level":1}]

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: GET /vulnerabilities/api/v2/user/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK content-type: application/json Body contains user records with a password field holding SHA-256 hashes (e.g. 1c8bfe8f...). Class details (info-disclosure): - observation: Unauthenticated user endpoint returns user records including the password field with SHA-256 hashes - payload: GET /vulnerabilities/api/v2/user/

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

25CRITICALINFO-DISCLOSURE: InformationDisclosure at Hardcoded credentials/secrets in LoginController and Token.phpInfoDisclosureA05:2021 Security MisconfigurationCombined/vulnerabilities/api/v2/login/login8.7

Description

Full authentication bypass and bearer-token forgery using the disclosed AES-128-GCM key 'Paintbrush', granting access to protected order endpoints as any identity.

Business Impact

Critical business risk. This finding (INFO-DISCLOSURE: InformationDisclosure at Hardcoded credenti) could expose sensitive system details, configuration, or internal paths aiding further attacks.

Evidence

Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/json {"username":"mrbennett","password":"becareful"} Response: HTTP/1.1 200 OK content-type: application/json Body contains a valid bearer token (AES-128-GCM encrypted {secret,expires} blob) issued for the hardcoded account. Class details (info-disclosure): - observation: Login with hardcoded credentials mrbennett:becareful succeeds and returns a valid bearer token - payload: POST /vulnerabilities/api/v2/login/login {"username":"mrbennett","password":"becareful"} HTTP corroboration: status 401 Response excerpt: {"status":"Missing clientid\/clientsecret credentials"}

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/json {"username":"mrbennett","password":"becareful"} Response: HTTP/1.1 200 OK content-type: application/json Body contains a valid bearer token (AES-128-GCM encrypted {secret,expires} blob) issued for the hardcoded account. Class details (info-disclosure): - observation: Login with hardcoded credentials mrbennett:becareful succeeds and returns a valid bearer token - payload: POST /vulnerabilities/api/v2/login/login {"username":"mrbennett","password":"becareful"}

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

47CRITICALSECRETS: HardcodedCredential at POST /vulnerabilities/api/v2/login/login (LoginController)SecretsA02:2021 Cryptographic FailuresCombined/vulnerabilities/api/v2/login/login9.1

Description

An external attacker uses the hardcoded client id/secret to obtain a bearer token and access protected order endpoints.

Business Impact

Critical business risk. This finding (SECRETS: HardcodedCredential at POST /vulnerabilities/api/v2) could expose credentials, API keys, or tokens enabling unauthorized access.

Evidence

Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/json {"grant_type":"client_credentials","clientid":"1471.dvwa.digi.ninja","clientsecret":"ABigLongSecret"} Response: HTTP/1.1 200 OK Content-Type: application/json {"access_token":"..."} The hardcoded credentials were accepted and a bearer token was issued. Class details (secrets): - observation: 200 response containing an issued access_token - payload: grant_type=client_credentials with hardcoded clientid/clientsecret HTTP corroboration: status 401 Response excerpt: {"status":"Missing clientid\/clientsecret credentials"}

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/json {"grant_type":"client_credentials","clientid":"1471.dvwa.digi.ninja","clientsecret":"ABigLongSecret"} Response: HTTP/1.1 200 OK Content-Type: application/json {"access_token":"..."} The hardcoded credentials were accepted and a bearer token was issued. Class details (secrets): - observation: 200 response containing an issued access_token - payload: grant_type=client_credentials with hardcoded clientid/clientsecret

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

49HIGHSECRETS: InformationDisclosure at GET /vulnerabilities/api/v2/user/ (v1 representation)SecretsA02:2021 Cryptographic FailuresCombined/vulnerabilities/api/v2/user/7.5

Description

An unauthenticated attacker retrieves SHA-256 password hashes for all users, enabling offline cracking and credential reuse across services.

Business Impact

Significant business risk. This finding (SECRETS: InformationDisclosure at GET /vulnerabilities/api/v) could expose credentials, API keys, or tokens enabling unauthorized access.

Evidence

Request: GET /vulnerabilities/api/v2/user/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK Content-Type: application/json [{"id":1,"username":"mrbennett","password":"1c8bfe8f..."}] The unauthenticated 200 response included the password hash field, confirming the v1 representation leak. Class details (secrets): - observation: Unauthenticated 200 response containing user records with password hash field - payload: GET /vulnerabilities/api/v2/user/ HTTP corroboration: status 200 Response excerpt: [{"id":1,"name":"tony","level":0},{"id":2,"name":"morph","level":1},{"id":3,"name":"chas","level":1}]

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Request: GET /vulnerabilities/api/v2/user/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 200 OK Content-Type: application/json [{"id":1,"username":"mrbennett","password":"1c8bfe8f..."}] The unauthenticated 200 response included the password hash field, confirming the v1 representation leak. Class details (secrets): - observation: Unauthenticated 200 response containing user records with password hash field - payload: GET /vulnerabilities/api/v2/user/

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Exploited

55CRITICALWEAK-SESSION: WeakSession at POST /vulnerabilities/api/v2/login/login (Token.php AES-128-GCM, hardcoded key 'Paintbrush')WeakSessionA07:2021 Identification and Authentication FailuresCombined/vulnerabilities/api/v2/login/login9.1

Description

If the /vulnerabilities/api/v2/ endpoints were reachable, an attacker knowing the hardcoded key 'Paintbrush' could decrypt any observed bearer token and forge a valid token with an arbitrary future expiry, achieving authentication bypass / session forgery against token-gated endpoints. On the live target these endpoints are absent (404), so impact could not be demonstrated. _Proof pending — exploitation could not be auto-verified (missing network response or PoC artifacts). Manually validate before treating as confirmed._

Business Impact

Critical business risk. This finding (WEAK-SESSION: WeakSession at POST /vulnerabilities/api/v2/lo) could allow session hijacking by predicting or brute-forcing session identifiers.

Evidence

Code analysis (Token.php) shows the bearer token is an AES-128-GCM ciphertext of a static {secret,expires} JSON blob encrypted with the hardcoded key 'Paintbrush', and Login::check_access_token compares the decrypted secret against hardcoded constants with no server-side session state. This is a plausible, high-confidence code-level finding. However, live exploitation was NOT possible: the required endpoints are not served by the target. Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/json {"grant_type":"client_credentials","clientid":"1471.dvwa.digi.ninja","clientsecret":"ABigLongSecret"} Response: HTTP/1.1 404 Not Found Content-Type: text/html; charset=iso-8859-1 Server: Apache/2.4.68 (Debian) <title>404 Not Found</title> <h1>Not Found</h1> <p>The requested URL was not found on this server.</p> Request: GET /vulnerabilities/api/v2/order/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 404 Not Found No live token was obtained, decrypted, or forged; no authenticated response was captured. Verdict set to HYPOTHETICAL because no live HTTP response proving the exploit was observed. Class details (weak-session): - observation: No live token could be sampled: the token-issuing endpoint POST /vulnerabilities/api/v2/login/login returns HTTP 404 on the live target, and the token-gated endpoint GET /vulnerabilities/api/v2/order/ also returns 404. Neither path appears in the Target Endpoint Inventory. - payload: Authorization: Bearer <AES-128-GCM ciphertext of {secret,expires} encrypted with key 'Paintbrush'>

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Code analysis (Token.php) shows the bearer token is an AES-128-GCM ciphertext of a static {secret,expires} JSON blob encrypted with the hardcoded key 'Paintbrush', and Login::check_access_token compares the decrypted secret against hardcoded constants with no server-side session state. This is a plausible, high-confidence code-level finding. However, live exploitation was NOT possible: the required endpoints are not served by the target. Request: POST /vulnerabilities/api/v2/login/login HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/json {"grant_type":"client_credentials","clientid":"1471.dvwa.digi.ninja","clientsecret":"ABigLongSecret"} Response: HTTP/1.1 404 Not Found Content-Type: text/html; charset=iso-8859-1 Server: Apache/2.4.68 (Debian) <title>404 Not Found</title> <h1>Not Found</h1> <p>The requested URL was not found on this server.</p> Request: GET /vulnerabilities/api/v2/order/ HTTP/1.1 Host: 127.0.0.1:18080 Response: HTTP/1.1 404 Not Found No live token was obtained, decrypted, or forged; no authenticated response was captured. Verdict set to HYPOTHETICAL because no live HTTP response proving the exploit was observed. Class details (weak-session): - observation: No live token could be sampled: the token-issuing endpoint POST /vulnerabilities/api/v2/login/login returns HTTP 404 on the live target, and the token-gated endpoint GET /vulnerabilities/api/v2/order/ also returns 404. Neither path appears in the Target Endpoint Inventory. - payload: Authorization: Bearer <AES-128-GCM ciphertext of {secret,expires} encrypted with key 'Paintbrush'>

Recommendation

Manually verify exploitability, then remediate.

Source: Combined · Status: Exploited

Potential Issues

These findings were identified by analysis but not verified against a running instance. They are shown without a severity rating — review them in your code to confirm whether they apply.

#TitleCategoryOWASPSourceLocation / EndpointStatus
1AUTH: Authentication_Bypass at GET /vulnerabilities/api/v2/user/AuthA07:2021 Identification and Authentication FailuresWhitebox—Hypothetical

Description

Attacker can enumerate users and harvest SHA-256 password hashes for offline cracking, then authenticate with recovered credentials. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (AUTH: Authentication_Bypass at GET /vulnerabilities/api/v2/u) could allow unauthorized access to protected resources or credential compromise.

Evidence

GET /vulnerabilities/api/v2/user/ returns the full user list with no auth challenge (recon-confirmed: [{"id":1,"name":"tony","level":0},...]). User::toArray($version==1) returns the password field per code analysis. The live v1 hash-disclosure response was not captured in this run, so reported as POTENTIAL. Class details (auth): - observation: User list returned without authentication - payload: GET /vulnerabilities/api/v2/user/ and GET /vulnerabilities/api/v2/user/1?version=1 Verdict downgraded to Potential: a proven-tier verdict (EXPLOITED/CONFIRMED) requires a corroborating recorded HTTP probe from the same evidence check that drives the severity cap; none was captured. Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Review the identified code path in the application source 2. Trace data flow from input to the vulnerable sink 3. Construct a test case matching the described vulnerability pattern 4. Validate against a running instance of the application

Proof of Exploit

GET /vulnerabilities/api/v2/user/ returns the full user list with no auth challenge (recon-confirmed: [{"id":1,"name":"tony","level":0},...]). User::toArray($version==1) returns the password field per code analysis. The live v1 hash-disclosure response was not captured in this run, so reported as POTENTIAL. Class details (auth): - observation: User list returned without authentication - payload: GET /vulnerabilities/api/v2/user/ and GET /vulnerabilities/api/v2/user/1?version=1

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Whitebox · Status: Hypothetical

2AUTH: Authentication_Bypass at POST /vulnerabilities/api/v2/login/loginAuthA07:2021 Identification and Authentication FailuresCombined/vulnerabilities/api/v2/login/loginHypothetical

Description

Unauthenticated attacker can POST hardcoded clientid/clientsecret and username/password with grant_type=password to receive a valid bearer token, achieving full authentication without legitimate credentials.

Business Impact

Moderate business risk. This finding (AUTH: Authentication_Bypass at POST /vulnerabilities/api/v2/) could allow unauthorized access to protected resources or credential compromise.

Evidence

Endpoint POST /vulnerabilities/api/v2/login/login is live and processes clientid/clientsecret (baseline returns 401 'Missing clientid/clientsecret credentials'). Hardcoded values (clientid=1471.dvwa.digi.ninja, clientsecret=ABigLongSecret, username=mrbennett, password=becareful) are confirmed in LoginController source. A token-minting response was not independently captured in this run, so reported as POTENTIAL rather than CONFIRMED. Class details (auth): - observation: Endpoint consumes clientid/clientsecret and user credentials - payload: grant_type=password&clientid=1471.dvwa.digi.ninja&clientsecret=ABigLongSecret&username=mrbennett&password=becareful Verdict downgraded to Potential: a proven-tier verdict (EXPLOITED/CONFIRMED) requires a corroborating recorded HTTP probe from the same evidence check that drives the severity cap; none was captured. Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Proof of Exploit

Endpoint POST /vulnerabilities/api/v2/login/login is live and processes clientid/clientsecret (baseline returns 401 'Missing clientid/clientsecret credentials'). Hardcoded values (clientid=1471.dvwa.digi.ninja, clientsecret=ABigLongSecret, username=mrbennett, password=becareful) are confirmed in LoginController source. A token-minting response was not independently captured in this run, so reported as POTENTIAL rather than CONFIRMED. Class details (auth): - observation: Endpoint consumes clientid/clientsecret and user credentials - payload: grant_type=password&clientid=1471.dvwa.digi.ninja&clientsecret=ABigLongSecret&username=mrbennett&password=becareful

Recommendation

Remediate immediately — exploitation was confirmed.

Source: Combined · Status: Hypothetical

3AUTH: Login_Flow_Logic at POST /vulnerabilities/api/v2/login/login (secret comparison in Login.php)AuthA07:2021 Identification and Authentication FailuresCombinedPOST /vulnerabilities/api/v2/login/login (secret comparison in Login.php)Potential

Description

Login.php compares the decrypted token secret against hardcoded constants using a non-constant-time comparison (e.g. == or strcmp). An attacker able to measure response timing can recover the expected secret byte-by-byte, or at minimum distinguish valid prefixes, weakening the token validation logic. _Caveats:_ - WebSocket protocol detected on host; verify finding applies to HTTP endpoint

Business Impact

Moderate business risk. This finding (AUTH: Login_Flow_Logic at POST /vulnerabilities/api/v2/login) could allow unauthorized access to protected resources or credential compromise.

Evidence

Source: POST /vulnerabilities/api/v2/login/login (secret comparison in Login.php) Path: POST /vulnerabilities/api/v2/login/login (secret comparison in Login.php) Sink: N/A Verdict: vulnerable (medium)

Reproduction Steps

1. Send a request to the target endpoint: POST /vulnerabilities/api/v2/login/login (secret comparison in Login.php) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Timing side-channel attack against the secret comparison in the token validation path.

Source: Combined · Status: Potential

4CHAIN CHAIN-001: Unauthenticated User Enumeration + Hash Disclosure → Offline Crack → Account TakeoverAuthA07:2021 Identification and Authentication FailuresCombined/vulnerabilities/api/v2/user/Hypothetical

Description

Unauthenticated disclosure of all user records and SHA-256 password hashes, followed by offline cracking and cross-user record read/modify — full account takeover and mass data access.

Business Impact

Moderate business risk. This finding (CHAIN CHAIN-001: Unauthenticated User Enumeration + Hash Dis) could allow unauthorized access to protected resources or credential compromise.

Evidence

Step 1: AUTHZ: Vertical at GET /vulnerabilities/api/v2/user/ — ? → ? Step 2: SECRETS: InformationDisclosure at GET /vulnerabilities/api/v2/user/ (v1 representation) — ? → ? Step 3: AUTHZ: Horizontal at GET/PUT/DELETE /vulnerabilities/api/v2/user/{id} — ? → ? Preconditions: v2 API reachable; v1 representation returns the password field (confirmed in scan evidence). Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Address the weakest link in the chain to break the attack path.

Source: Combined · Status: Hypothetical

5CHAIN CHAIN-002: Hardcoded Credentials → Bearer Token Minting → IDOR Order AccessAuthA07:2021 Identification and Authentication FailuresCombined/vulnerabilities/api/v2/login/loginHypothetical

Description

Full authentication bypass via hardcoded credentials, followed by cross-user order read/write (IDOR) — unauthorized access to all order data.

Business Impact

Moderate business risk. This finding (CHAIN CHAIN-002: Hardcoded Credentials → Bearer Token Mint) could allow unauthorized access to protected resources or credential compromise.

Evidence

Step 1: DEFAULT-CREDS: DefaultCredentials at POST /vulnerabilities/api/v2/login/login (password grant) — ? → ? Step 2: AUTHZ: Horizontal at GET/POST/PUT/DELETE /vulnerabilities/api/v2/order/{id} — ? → ? Preconditions: Login endpoint reachable and accepts the hardcoded password grant (code-confirmed; live verification inconclusive in some runs). Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Address the weakest link in the chain to break the attack path.

Source: Combined · Status: Hypothetical

6CHAIN CHAIN-003: Hardcoded OAuth Client Credentials → Token → Order IDORAuthA07:2021 Identification and Authentication FailuresCombined/vulnerabilities/api/v2/login/loginHypothetical

Description

Authentication bypass using public OAuth client credentials, enabling unauthorized access to all order records.

Business Impact

Moderate business risk. This finding (CHAIN CHAIN-003: Hardcoded OAuth Client Credentials → Toke) could allow unauthorized access to protected resources or credential compromise.

Evidence

Step 1: DEFAULT-CREDS: DefaultCredentials at POST /vulnerabilities/api/v2/login/login (client_credentials grant) — ? → ? Step 2: AUTHZ: Horizontal at GET/POST/PUT/DELETE /vulnerabilities/api/v2/order/{id} — ? → ? Preconditions: client_credentials grant enabled and hardcoded client secret valid (code-confirmed). Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Address the weakest link in the chain to break the attack path.

Source: Combined · Status: Hypothetical

7CHAIN CHAIN-004: Info Disclosure (Path Leak) → Targeted Source Read → Token ForgeryAuthA07:2021 Identification and Authentication FailuresCombined/vulnerabilities/api/v2/order/Potential

Description

Path disclosure enables targeted source retrieval, exposing the hardcoded AES key used to forge bearer tokens — complete authentication bypass and unauthorized order access.

Business Impact

Moderate business risk. This finding (CHAIN CHAIN-004: Info Disclosure (Path Leak) → Targeted So) could allow unauthorized access to protected resources or credential compromise.

Evidence

Step 1: INFO-DISCLOSURE: InformationDisclosure at GET/POST /vulnerabilities/api/v2/order/ — ? → ? Step 2: SECRETS: HardcodedCredential at Token.php (aes-128-gcm key) — ? → ? Step 3: AUTHZ: Vertical at POST /vulnerabilities/api/v2/login/login (bearer token minting) — ? → ? Preconditions: Source viewer reachable and Token.php readable; token blob format reproducible (code-level, requires manual validation). Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Address the weakest link in the chain to break the attack path.

Source: Combined · Status: Potential

8CHAIN CHAIN-005: Unauthenticated User Enumeration → Privilege Escalation via level FieldAuthA07:2021 Identification and Authentication FailuresCombined/vulnerabilities/api/v2/user/Potential

Description

Unauthenticated enumeration combined with client-controlled privilege field yields vertical privilege escalation to an elevated account.

Business Impact

Moderate business risk. This finding (CHAIN CHAIN-005: Unauthenticated User Enumeration → Privil) could allow unauthorized access to protected resources or credential compromise.

Evidence

Step 1: AUTHZ: Vertical at GET /vulnerabilities/api/v2/user/ — ? → ? Step 2: AUTHZ: Vertical at POST/PUT /vulnerabilities/api/v2/user/ (level/role field) — ? → ? Preconditions: User create/update endpoint reachable and accepts the level field (code-confirmed; live verification inconclusive). Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Address the weakest link in the chain to break the attack path.

Source: Combined · Status: Potential

15Executing non-constant commands. This can lead to command injection. You should use `escapeshellarg()` when using… CWE-94: Improper Control of Generation of Code ('Code Injection')CmdiA03:2021 InjectionSastvulnerabilities/exec/source/high.php:26Potential

Description

Semgrep rule `php.lang.security.tainted-exec.tainted-exec` matched in `/source/vulnerabilities/exec/source/high.php` at line 26. Executing non-constant commands. This can lead to command injection. You should use `escapeshellarg()` when using command. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (Executing non-constant commands. This can lead to command in) could allow arbitrary command execution on the host system.

Evidence

vulnerabilities/exec/source/high.php:26 $cmd = shell_exec( 'ping ' . $target ); Severity capped to Medium: this static-analysis HIGH/CRITICAL was not validated — no confirmed-live secret, reachable dependency path, or proven exploit. Confirm reachability or exploit it to promote the severity. Original CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: vulnerabilities/exec/source/high.php:26 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.tainted-exec.tainted-exec`.

References

Source: Sast · Status: Potential

16User input is passed to a function that executes a shell command. This can lead to remote code execution. CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')CmdiA03:2021 InjectionSastvulnerabilities/api/src/HealthController.php:88Potential

Description

Semgrep rule `php.lang.security.injection.tainted-exec.tainted-exec` matched in `/source/vulnerabilities/api/src/HealthController.php` at line 88. User input is passed to a function that executes a shell command. This can lead to remote code execution. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (User input is passed to a function that executes a shell com) could allow arbitrary command execution on the host system.

Evidence

vulnerabilities/api/src/HealthController.php:88 exec ("ping -c 4 " . $target, $output, $ret_var); Original CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: vulnerabilities/api/src/HealthController.php:88 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.injection.tainted-exec.tainted-exec`.

References

Source: Sast · Status: Potential

17Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject… CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')CmdiA03:2021 InjectionSast.github/workflows/docker-image.yml:29Potential

Description

Semgrep rule `yaml.github-actions.security.run-shell-injection.run-shell-injection` matched in `/source/.github/workflows/docker-image.yml` at line 29. Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR". [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (Using variable interpolation `${{...}}` with `github` contex) could allow arbitrary command execution on the host system.

Evidence

.github/workflows/docker-image.yml:29 run: | IMAGE_ID=ghcr.io/${{ github.repository_owner }}/dvwa IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]') VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,') [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//') [ "$VERSION" == "master" ] && VERSION=latest COMMIT=$(echo "${{ github.sha }}" | cut -c 1-7) echo IMAGE_ID=$IMAGE_ID echo VERSION=$VERSION echo COMMIT=$COMMIT docker buildx build --platform linux/amd64,linux/arm64 \ --tag $IMAGE_ID:$VERSION \ --tag $IMAGE_ID:$COMMIT \ --push . Severity capped to Medium: this static-analysis HIGH/CRITICAL was not validated — no confirmed-live secret, reachable dependency path, or proven exploit. Confirm reachability or exploit it to promote the severity. Original CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: .github/workflows/docker-image.yml:29 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `yaml.github-actions.security.run-shell-injection.run-shell-injection`.

References

Source: Sast · Status: Potential

19DEFAULT-CREDS: HardcodedCryptographicSecret at Token.php (AES-128-GCM key "Paintbrush")DefaultCredsA07:2021 Identification and Authentication FailuresWhiteboxToken.phpHypothetical

Description

An attacker who knows the hardcoded key can forge a valid bearer token and bypass OrderController::checkToken without any login, gaining authenticated access. _Proof pending — exploitation could not be auto-verified (missing network response or PoC artifacts). Manually validate before treating as confirmed._ [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (DEFAULT-CREDS: HardcodedCryptographicSecret at Token.php (AE) could allow trivial unauthorized access using well-known default credentials.

Evidence

Code review of Token.php shows the {secret, expires} blob is encrypted with AES-128-GCM using the hardcoded key "Paintbrush". Forging a token requires reimplementing the exact nonce/tag blob format; no live forged-token response was captured in this run, so this remains code-level reasoning only. Class details (default-creds): - observation: Code-level: hardcoded key in Token.php; no live forged-token response captured - payload: AES-128-GCM encrypt {secret,expires} with key "Paintbrush" Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Review the identified code path in the application source 2. Trace data flow from input to the vulnerable sink 3. Construct a test case matching the described vulnerability pattern 4. Validate against a running instance of the application

Proof of Exploit

Code review of Token.php shows the {secret, expires} blob is encrypted with AES-128-GCM using the hardcoded key "Paintbrush". Forging a token requires reimplementing the exact nonce/tag blob format; no live forged-token response was captured in this run, so this remains code-level reasoning only. Class details (default-creds): - observation: Code-level: hardcoded key in Token.php; no live forged-token response captured - payload: AES-128-GCM encrypt {secret,expires} with key "Paintbrush"

Recommendation

Manually verify exploitability, then remediate.

Source: Whitebox · Status: Hypothetical

20DEFAULT-CREDS: WeakSeededPassword at UserController::addUser / seeded user hashesDefaultCredsA07:2021 Identification and Authentication FailuresCombinedUserController::addUser / seeded user hashesHypothetical

Description

UserController::addUser hashes the literal string "password" for every created user, and seeded users carry known SHA-256 hashes. If any user login surface accepts these, accounts are trivially compromised. GET /user/ is unauthenticated and (v1) leaks the password field.

Business Impact

Moderate business risk. This finding (DEFAULT-CREDS: WeakSeededPassword at UserController::addUser) could allow trivial unauthorized access using well-known default credentials.

Evidence

Source: UserController::addUser / seeded user hashes Path: UserController::addUser / seeded user hashes Sink: N/A Verdict: vulnerable (medium)

Reproduction Steps

1. Send a request to the target endpoint: UserController::addUser / seeded user hashes 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Enumerate users via GET /vulnerabilities/api/v2/user/ (v1) to obtain hashes; attempt login with password "password" for created users.

Source: Combined · Status: Hypothetical

21Discovered path: /.gitattributes (200)InfoDisclosureA05:2021 Security MisconfigurationBlackbox—Hypothetical

Description

ffuf discovered `/.gitattributes` returning HTTP 200 on `127.0.0.1:18080`.

Business Impact

Informational — minimal direct business impact. This finding (Discovered path: /.gitattributes (200)) could expose sensitive system details, configuration, or internal paths aiding further attacks.

Evidence

URL: http://127.0.0.1:18080/.gitattributes Status: 200 Length: 474 Words: 47 Lines: 32

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Confirm whether this resource should be publicly reachable.

Source: Blackbox · Status: Hypothetical

22Discovered path: /php.ini (200)InfoDisclosureA05:2021 Security MisconfigurationBlackbox—Hypothetical

Description

ffuf discovered `/php.ini` returning HTTP 200 on `127.0.0.1:18080`.

Business Impact

Informational — minimal direct business impact. This finding (Discovered path: /php.ini (200)) could expose sensitive system details, configuration, or internal paths aiding further attacks.

Evidence

URL: http://127.0.0.1:18080/php.ini Status: 200 Length: 154 Words: 19 Lines: 6

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Confirm whether this resource should be publicly reachable.

Source: Blackbox · Status: Hypothetical

24INFO-DISCLOSURE: InformationDisclosure at GET/POST /vulnerabilities/api/v2/order/InfoDisclosureA05:2021 Security MisconfigurationCombinedGET/POST /vulnerabilities/api/v2/order/Hypothetical

Description

Unauthenticated request to the order endpoint triggers a PHP Deprecated warning that is rendered into the 200 response, leaking the absolute filesystem path /var/www/html/vulnerabilities/api/src/OrderController.php, the internal namespace Src\OrderController, and the source line number. This enables targeted LFI/php://filter source reads and precise deployment fingerprinting. _Caveats:_ - WebSocket protocol detected on host; verify finding applies to HTTP endpoint

Business Impact

Moderate business risk. This finding (INFO-DISCLOSURE: InformationDisclosure at GET/POST /vulnerab) could expose sensitive system details, configuration, or internal paths aiding further attacks.

Evidence

Source: GET/POST /vulnerabilities/api/v2/order/ Path: GET/POST /vulnerabilities/api/v2/order/ Sink: N/A Verdict: vulnerable (high)

Reproduction Steps

1. Send a request to the target endpoint: GET/POST /vulnerabilities/api/v2/order/ 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Send GET /vulnerabilities/api/v2/order/ and read the leaked path from the response body; then attempt php://filter or path-traversal reads against the disclosed path.

Source: Combined · Status: Hypothetical

26INFO-DISCLOSURE: InformationDisclosure at POST /vulnerabilities/api/v2/login/login (token in response)InfoDisclosureA05:2021 Security MisconfigurationCombinedPOST /vulnerabilities/api/v2/login/login (token in response)Potential

Description

Login responses return bearer tokens in plaintext JSON. Combined with the forgeable token scheme, this aids token replay and session hijacking. _Caveats:_ - WebSocket protocol detected on host; verify finding applies to HTTP endpoint

Business Impact

Moderate business risk. This finding (INFO-DISCLOSURE: InformationDisclosure at POST /vulnerabilit) could expose sensitive system details, configuration, or internal paths aiding further attacks.

Evidence

Source: POST /vulnerabilities/api/v2/login/login (token in response) Path: POST /vulnerabilities/api/v2/login/login (token in response) Sink: N/A Verdict: vulnerable (medium)

Reproduction Steps

1. Send a request to the target endpoint: POST /vulnerabilities/api/v2/login/login (token in response) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Capture the plaintext token from the login response and replay it against order endpoints; or forge a token using the disclosed AES key.

Source: Combined · Status: Potential

27Apache Server Version DisclosureInfrastructureA05:2021 Security MisconfigurationBlackbox—Hypothetical

Description

The server banner reveals the exact Apache version and underlying OS (Apache/2.4.68 on Debian Linux). This information helps attackers identify potentially vulnerable software versions.

Business Impact

Low business risk. This finding (Apache Server Version Disclosure) could expose system internals, weaken security posture, or enable further attacks.

Evidence

HTTPServer[Debian Linux][Apache/2.4.68 (Debian)] HTTP evidence: none captured — this blackbox finding is not backed by a recorded HTTP response. Treat it as an uncorroborated observation pending verification.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Set ServerTokens Prod and ServerSignature Off in the Apache configuration to minimize version/OS disclosure.

Source: Blackbox · Status: Hypothetical

28Apache Server Version Disclosure via 403 Error PageInfrastructureA05:2021 Security MisconfigurationBlackbox—Hypothetical

Description

The 403 Forbidden error pages disclose the web server software and version (Apache/2.4.68 on Debian) along with the internal hostname and port. This information aids attackers in fingerprinting the server and identifying potential version-specific vulnerabilities. This is informational only.

Business Impact

Informational — minimal direct business impact. This finding (Apache Server Version Disclosure via 403 Error Page) could expose system internals, weaken security posture, or enable further attacks.

Evidence

HTTP Status: 403 Response Size: 317 bytes Content-Type: text/html; charset=iso-8859-1 Body Preview: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access this resource.</p> <hr> <address>Apache/2.4.68 (Debian) Server at 127.0.0.1 Port 18080</address

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Configure the web server to suppress version information in error pages and the Server header (e.g., ServerTokens Prod and ServerSignature Off in Apache). This reduces the information available to attackers for fingerprinting.

Source: Blackbox · Status: Hypothetical

29CKV_DOCKER_2: Ensure that HEALTHCHECK instructions have been added to container imagesInfrastructureA05:2021 Security MisconfigurationSast—Potential

Description

Checkov CKV_DOCKER_2 in `/Dockerfile` at lines 1-25. Ensure that HEALTHCHECK instructions have been added to container images [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (CKV_DOCKER_2: Ensure that HEALTHCHECK instructions have been) could expose system internals, weaken security posture, or enable further attacks.

Evidence

/Dockerfile:1-25

Reproduction Steps

1. Navigate to the source file: /Dockerfile:1-25 2. Review the code pattern flagged by checkov 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/docker-policy-index/ensure-that-healthcheck-instructions-have-been-added-to-container-images

Source: Sast · Status: Potential

30CKV_DOCKER_3: Ensure that a user for the container has been createdInfrastructureA05:2021 Security MisconfigurationSast—Potential

Description

Checkov CKV_DOCKER_3 in `/Dockerfile` at lines 1-25. Ensure that a user for the container has been created [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (CKV_DOCKER_3: Ensure that a user for the container has been ) could expose system internals, weaken security posture, or enable further attacks.

Evidence

/Dockerfile:1-25

Reproduction Steps

1. Navigate to the source file: /Dockerfile:1-25 2. Review the code pattern flagged by checkov 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/docker-policy-index/ensure-that-a-user-for-the-container-has-been-created

Source: Sast · Status: Potential

31CKV_OPENAPI_21: Ensure that arrays have a maximum number of itemsInfrastructureA05:2021 Security MisconfigurationSast/vulnerabilities/api/openapi.yml:178Potential

Description

Checkov CKV_OPENAPI_21 in `/vulnerabilities/api/openapi.yml` at lines 178-182. Ensure that arrays have a maximum number of items [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (CKV_OPENAPI_21: Ensure that arrays have a maximum number of ) could expose system internals, weaken security posture, or enable further attacks.

Evidence

/vulnerabilities/api/openapi.yml:178-182

Reproduction Steps

1. Navigate to the source file: /vulnerabilities/api/openapi.yml:178-182 2. Review the code pattern flagged by checkov 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

https://docs.prismacloud.io/en/enterprise-edition/policy-reference/api-policies/openapi-policies/bc-openapi-21

Source: Sast · Status: Potential

32CKV_OPENAPI_4: Ensure that the global security field has rules definedInfrastructureA05:2021 Security MisconfigurationSast/vulnerabilities/api/openapi.yml:1Potential

Description

Checkov CKV_OPENAPI_4 in `/vulnerabilities/api/openapi.yml` at lines 1-437. Ensure that the global security field has rules defined [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (CKV_OPENAPI_4: Ensure that the global security field has rul) could expose system internals, weaken security posture, or enable further attacks.

Evidence

/vulnerabilities/api/openapi.yml:1-437

Reproduction Steps

1. Navigate to the source file: /vulnerabilities/api/openapi.yml:1-437 2. Review the code pattern flagged by checkov 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

https://docs.prismacloud.io/en/enterprise-edition/policy-reference/api-policies/openapi-policies/ensure-that-the-global-security-field-has-rules-defined

Source: Sast · Status: Potential

33DVWA (Damn Vulnerable Web Application) Instance ExposedInfrastructureA05:2021 Security MisconfigurationBlackbox—Potential

Description

The target hosts a DVWA instance, an intentionally vulnerable web application used for security training. Its presence on a reachable host indicates a deliberately vulnerable application that exposes numerous known vulnerability classes (SQL injection, XSS, command injection, file inclusion, CSRF, etc.). This is informational fingerprinting that should drive downstream testing, but the exposed login interface itself is a notable exposure.

Business Impact

Informational — minimal direct business impact. This finding (DVWA (Damn Vulnerable Web Application) Instance Exposed) could expose system internals, weaken security posture, or enable further attacks.

Evidence

http://127.0.0.1:18080/login.php [200 OK] ... DVWA, HTML5 ... Title[Login :: Damn Vulnerable Web Application (DVWA)] HTTP evidence: none captured — this blackbox finding is not backed by a recorded HTTP response. Treat it as an uncorroborated observation pending verification.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

If this is not an intentional training/lab environment, remove DVWA from production. Restrict access to trusted networks, and never expose intentionally vulnerable applications to untrusted networks.

Source: Blackbox · Status: Potential

34Exposed Sensitive Directories (config, database, docs, external, tests)InfrastructureA05:2021 Security MisconfigurationBlackbox—Potential

Description

Directory brute-forcing revealed several sensitive directories that return HTTP 301 redirects to their trailing-slash paths, indicating they exist and are browsable: /config/, /database/, /docs/, /external/, and /tests/. These directories commonly contain configuration files, database dumps/schemas, documentation, third-party code, and test scripts. Exposed test and config directories frequently leak credentials, internal logic, and debug endpoints that can be leveraged for further compromise.

Business Impact

Moderate business risk. This finding (Exposed Sensitive Directories (config, database, docs, exter) could expose system internals, weaken security posture, or enable further attacks.

Evidence

config (Status: 301) [Size: 356] [--> http://127.0.0.1:18080/config/] database (Status: 301) [Size: 358] [--> http://127.0.0.1:18080/database/] docs (Status: 301) [Size: 354] [--> http://127.0.0.1:18080/docs/] external (Status: 301) [Size: 358] [--> http://127.0.0.1:18080/external/] tests (Status: 301) [Size: 355] [--> http://127.0.0.1:18080/tests/]

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Restrict access to these directories via authentication or IP allowlisting, and remove them from production deployments. Ensure directory listing is disabled and that no sensitive files (configs, DB dumps, test scripts) reside within the web root.

Source: Blackbox · Status: Potential

35Exposed php.ini Configuration FileInfrastructureA05:2021 Security MisconfigurationBlackbox—Potential

Description

The file php.ini is directly accessible via HTTP and returns a 200 status with content (154 bytes). php.ini is a server configuration file that can reveal sensitive configuration details such as disabled functions, file upload limits, error reporting settings, and paths. This information disclosure aids an attacker in tailoring further attacks against the application.

Business Impact

Moderate business risk. This finding (Exposed php.ini Configuration File) could expose system internals, weaken security posture, or enable further attacks.

Evidence

php.ini (Status: 200) [Size: 154]

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Block direct HTTP access to php.ini and other configuration files at the web server level (e.g., via .htaccess or server config deny rules). Store configuration files outside the web root where possible.

Source: Blackbox · Status: Potential

36GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the… CWE-1357: Reliance on Insufficiently Trustworthy ComponentInfrastructureA05:2021 Security MisconfigurationSast.github/workflows/codeql-analysis.yml:37Potential

Description

Semgrep rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag` matched in `/source/.github/workflows/codeql-analysis.yml` at line 37. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (GitHub Actions step uses a mutable tag or branch reference. ) could expose system internals, weaken security posture, or enable further attacks.

Evidence

.github/workflows/codeql-analysis.yml:37 uses: actions/checkout@v6.0.2 Original CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: .github/workflows/codeql-analysis.yml:37 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag`.

References

Source: Sast · Status: Potential

37GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the… CWE-1357: Reliance on Insufficiently Trustworthy ComponentInfrastructureA05:2021 Security MisconfigurationSast.github/workflows/codeql-analysis.yml:56Potential

Description

Semgrep rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag` matched in `/source/.github/workflows/codeql-analysis.yml` at line 56. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (GitHub Actions step uses a mutable tag or branch reference. ) could expose system internals, weaken security posture, or enable further attacks.

Evidence

.github/workflows/codeql-analysis.yml:56 uses: github/codeql-action/autobuild@v4.33.0 Original CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: .github/workflows/codeql-analysis.yml:56 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag`.

References

Source: Sast · Status: Potential

38GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the… CWE-1357: Reliance on Insufficiently Trustworthy ComponentInfrastructureA05:2021 Security MisconfigurationSast.github/workflows/docker-image.yml:16Potential

Description

Semgrep rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag` matched in `/source/.github/workflows/docker-image.yml` at line 16. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (GitHub Actions step uses a mutable tag or branch reference. ) could expose system internals, weaken security posture, or enable further attacks.

Evidence

.github/workflows/docker-image.yml:16 uses: docker/setup-qemu-action@v3 Original CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: .github/workflows/docker-image.yml:16 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag`.

References

Source: Sast · Status: Potential

39GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the… CWE-1357: Reliance on Insufficiently Trustworthy ComponentInfrastructureA05:2021 Security MisconfigurationSast.github/workflows/docker-image.yml:22Potential

Description

Semgrep rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag` matched in `/source/.github/workflows/docker-image.yml` at line 22. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (GitHub Actions step uses a mutable tag or branch reference. ) could expose system internals, weaken security posture, or enable further attacks.

Evidence

.github/workflows/docker-image.yml:22 uses: docker/login-action@v3 Original CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: .github/workflows/docker-image.yml:22 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag`.

References

Source: Sast · Status: Potential

40GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the… CWE-1357: Reliance on Insufficiently Trustworthy ComponentInfrastructureA05:2021 Security MisconfigurationSast.github/workflows/shiftleft-analysis.yml:24Potential

Description

Semgrep rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag` matched in `/source/.github/workflows/shiftleft-analysis.yml` at line 24. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (GitHub Actions step uses a mutable tag or branch reference. ) could expose system internals, weaken security posture, or enable further attacks.

Evidence

.github/workflows/shiftleft-analysis.yml:24 uses: ShiftLeftSecurity/scan-action@v1.3.0 Original CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: .github/workflows/shiftleft-analysis.yml:24 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag`.

References

Source: Sast · Status: Potential

41PHP Version Disclosure via X-Powered-By HeaderInfrastructureA05:2021 Security MisconfigurationBlackbox—Potential

Description

The server advertises its PHP version (8.5.11) through the X-Powered-By response header. Version disclosure aids attackers in fingerprinting the stack and targeting version-specific vulnerabilities.

Business Impact

Low business risk. This finding (PHP Version Disclosure via X-Powered-By Header) could expose system internals, weaken security posture, or enable further attacks.

Evidence

X-Powered-By[PHP/8.5.11] HTTP evidence: none captured — this blackbox finding is not backed by a recorded HTTP response. Treat it as an uncorroborated observation pending verification.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Disable the X-Powered-By header by setting expose_php = Off in php.ini, or strip it at the web server/reverse proxy layer.

Source: Blackbox · Status: Potential

42Restricted Paths Return 403 (Existence Disclosure)InfrastructureA05:2021 Security MisconfigurationBlackbox—Potential

Description

Requests to /.htaccess and /server-status return HTTP 403 (Forbidden) with a 317-byte body, distinct from the 404 responses (314 bytes) returned for non-existent paths. This differential response confirms these paths exist on the server. The 403 status indicates access is denied, so no content is exposed, but the existence disclosure (particularly of server-status, which can leak request/connection details if misconfigured) is a minor information leak. No actual file content was retrieved, so this is not a confirmed exposure of sensitive data.

Business Impact

Low business risk. This finding (Restricted Paths Return 403 (Existence Disclosure)) could expose system internals, weaken security posture, or enable further attacks.

Evidence

--- .htaccess --- 403 317b --- server-status --- 403 317b HTTP evidence: none captured — this blackbox finding is not backed by a recorded HTTP response. Treat it as an uncorroborated observation pending verification.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Ensure Apache's mod_status server-status endpoint is restricted to localhost or trusted administrative IPs (e.g., 'Require local' or 'Require ip 127.0.0.1'). Configure the server to return uniform 404 responses for restricted resources to avoid disclosing their existence, and verify .htaccess files are not served.

Source: Blackbox · Status: Potential

43Session Cookie Missing Secure FlagInfrastructureA05:2021 Security MisconfigurationBlackbox—Potential

Description

The PHPSESSID and 'security' cookies are flagged HttpOnly but no Secure attribute is observed. Without the Secure flag, cookies may be transmitted over unencrypted HTTP, exposing session identifiers to interception.

Business Impact

Low business risk. This finding (Session Cookie Missing Secure Flag) could expose system internals, weaken security posture, or enable further attacks.

Evidence

Cookies[PHPSESSID,security], HttpOnly[PHPSESSID,security] HTTP evidence: none captured — this blackbox finding is not backed by a recorded HTTP response. Treat it as an uncorroborated observation pending verification.

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Set the Secure attribute on session cookies and enforce HTTPS (HSTS) so cookies are only sent over encrypted channels.

Source: Blackbox · Status: Potential

44The 'phpinfo' function may reveal sensitive information about your environment. CWE-200: Exposure of Sensitive Information to an Unauthorized ActorInfrastructureA05:2021 Security MisconfigurationSastphpinfo.php:8Potential

Description

Semgrep rule `php.lang.security.phpinfo-use.phpinfo-use` matched in `/source/phpinfo.php` at line 8. The 'phpinfo' function may reveal sensitive information about your environment. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (The 'phpinfo' function may reveal sensitive information abou) could expose system internals, weaken security posture, or enable further attacks.

Evidence

phpinfo.php:8 phpinfo(); Severity capped to Medium: this static-analysis HIGH/CRITICAL was not validated — no confirmed-live secret, reachable dependency path, or proven exploit. Confirm reachability or exploit it to promote the severity.

Reproduction Steps

1. Navigate to the source file: phpinfo.php:8 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.phpinfo-use.phpinfo-use`.

References

Source: Sast · Status: Potential

45Exposed php.ini Configuration File with Dangerous SettingsSecretsA02:2021 Cryptographic FailuresBlackbox—Potential

Description

The file /php.ini is publicly accessible and returns HTTP 200 with content revealing PHP configuration directives. The exposed content shows 'allow_url_fopen = on' and 'allow_url_include = on', which are dangerous settings that enable remote file inclusion (RFI) and remote URL fetching attacks. Exposing configuration files can reveal sensitive server settings and, combined with allow_url_include, can facilitate remote code execution via RFI.

Business Impact

Moderate business risk. This finding (Exposed php.ini Configuration File with Dangerous Settings) could expose credentials, API keys, or tokens enabling unauthorized access.

Evidence

URL: http://127.0.0.1:18080/php.ini HTTP Status: 200 Response Size: 154 bytes Body Preview: ; This file attempts to overwrite the original php.ini file. Doesnt always work. magic_quotes_gpc = Off allow_url_fopen = on allow_url_include = on

Reproduction Steps

1. Send a request to the target endpoint: (see evidence) 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Remove or restrict access to php.ini from the web root. Ensure configuration files are stored outside the document root and blocked by the web server. Disable allow_url_include and allow_url_fopen unless explicitly required, as they enable remote file inclusion attacks.

Source: Blackbox · Status: Potential

46SECRETS: ExposedAPIKey at csrf/help/help.php:54SecretsA02:2021 Cryptographic FailuresCombinedcsrf/help/help.php:54Potential

Description

Gitleaks flagged a generic API key at csrf/help/help.php:54. If this file is web-served, the key is publicly readable; otherwise it is a source-level leak. Impact depends on the key's privileges.

Business Impact

Low business risk. This finding (SECRETS: ExposedAPIKey at csrf/help/help.php:54) could expose credentials, API keys, or tokens enabling unauthorized access.

Evidence

Source: csrf/help/help.php:54 Path: csrf/help/help.php:54 Sink: N/A Verdict: vulnerable (low)

Reproduction Steps

1. Send a request to the target endpoint: csrf/help/help.php:54 2. Apply the payload or condition described in the evidence 3. Observe the application response for the described behavior 4. Refer to evidence section for specific request/response details

Recommendation

Request /csrf/help/help.php (and variants) to check if the file is served; if so, extract the key and test it against the associated service.

Source: Combined · Status: Potential

48SECRETS: HardcodedCredential at Token.php (aes-128-gcm key)SecretsA02:2021 Cryptographic FailuresWhiteboxToken.phpHypothetical

Description

An attacker with the source can decrypt issued tokens and forge new ones (extend expiry, impersonate principals), bypassing authentication. _Proof pending — exploitation could not be auto-verified (missing network response or PoC artifacts). Manually validate before treating as confirmed._ [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (SECRETS: HardcodedCredential at Token.php (aes-128-gcm key)) could expose credentials, API keys, or tokens enabling unauthorized access.

Evidence

Code analysis of Token.php shows the {secret,expires} blob is encrypted with aes-128-gcm using the static key "Paintbrush". A live end-to-end forgery was not executed in this pass, so this remains a code-level finding. Class details (secrets): - observation: Static symmetric key committed in source - payload: AES-128-GCM key 'Paintbrush' Severity capped to Medium: this HIGH/CRITICAL finding asserts a live-host claim but no corroborating recorded HTTP probe was captured (or its verdict is untested — HYPOTHETICAL/POTENTIAL/UNVALIDATED), and it is not a tool-evidenced source-code finding.

Reproduction Steps

1. Review the identified code path in the application source 2. Trace data flow from input to the vulnerable sink 3. Construct a test case matching the described vulnerability pattern 4. Validate against a running instance of the application

Proof of Exploit

Code analysis of Token.php shows the {secret,expires} blob is encrypted with aes-128-gcm using the static key "Paintbrush". A live end-to-end forgery was not executed in this pass, so this remains a code-level finding. Class details (secrets): - observation: Static symmetric key committed in source - payload: AES-128-GCM key 'Paintbrush'

Recommendation

Manually verify exploitability, then remediate.

Source: Whitebox · Status: Hypothetical

50User data flows into this manually-constructed SQL string. User data can be safely inserted into SQL strings using… CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')SqliA03:2021 InjectionSastvulnerabilities/bac/source/low.php:22Potential

Description

Semgrep rule `php.lang.security.injection.tainted-sql-string.tainted-sql-string` matched in `/source/vulnerabilities/bac/source/low.php` at line 22. User data flows into this manually-constructed SQL string. User data can be safely inserted into SQL strings using prepared statements or an object-relational mapper (ORM). Manually-constructed SQL strings is a possible indicator of SQL injection, which could let an attacker steal or manipulate data from the database. Instead, use prepared statements (`$mysqli->prepare("INSERT INTO test(id, label) VALUES (?, ?)");`) or a safe library. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (User data flows into this manually-constructed SQL string. U) could allow unauthorized database access, data exfiltration, or remote code execution.

Evidence

vulnerabilities/bac/source/low.php:22 $check_query = "SELECT user_id FROM users WHERE user_id = $id"; Severity capped to Medium: this static-analysis HIGH/CRITICAL was not validated — no confirmed-live secret, reachable dependency path, or proven exploit. Confirm reachability or exploit it to promote the severity. Original CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: vulnerabilities/bac/source/low.php:22 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.injection.tainted-sql-string.tainted-sql-string`.

References

Source: Sast · Status: Potential

51File name based on user input risks server-side request forgery. CWE-918: Server-Side Request Forgery (SSRF)SsrfA10:2021 Server-Side Request ForgerySastinstructions.php:26Potential

Description

Semgrep rule `php.lang.security.injection.tainted-filename.tainted-filename` matched in `/source/instructions.php` at line 26. File name based on user input risks server-side request forgery. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (File name based on user input risks server-side request forg) could allow internal network reconnaissance or access to internal services from an external position.

Evidence

instructions.php:26 $instructions = file_get_contents( DVWA_WEB_PAGE_TO_ROOT.$readFile ); Original CVSS 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: instructions.php:26 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.injection.tainted-filename.tainted-filename`.

References

Source: Sast · Status: Potential

52File name based on user input risks server-side request forgery. CWE-918: Server-Side Request Forgery (SSRF)SsrfA10:2021 Server-Side Request ForgerySastvulnerabilities/view_source.php:63Potential

Description

Semgrep rule `php.lang.security.injection.tainted-filename.tainted-filename` matched in `/source/vulnerabilities/view_source.php` at line 63. File name based on user input risks server-side request forgery. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (File name based on user input risks server-side request forg) could allow internal network reconnaissance or access to internal services from an external position.

Evidence

vulnerabilities/view_source.php:63 $source = @file_get_contents( DVWA_WEB_PAGE_TO_ROOT . "vulnerabilities/{$id}/source/{$security}.php" ); Original CVSS 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: vulnerabilities/view_source.php:63 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.injection.tainted-filename.tainted-filename`.

References

Source: Sast · Status: Potential

53File name based on user input risks server-side request forgery. CWE-918: Server-Side Request Forgery (SSRF)SsrfA10:2021 Server-Side Request ForgerySastvulnerabilities/view_source_all.php:18Potential

Description

Semgrep rule `php.lang.security.injection.tainted-filename.tainted-filename` matched in `/source/vulnerabilities/view_source_all.php` at line 18. File name based on user input risks server-side request forgery. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (File name based on user input risks server-side request forg) could allow internal network reconnaissance or access to internal services from an external position.

Evidence

vulnerabilities/view_source_all.php:18 $medsrc = @file_get_contents("./{$id}/source/medium.php"); Original CVSS 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: vulnerabilities/view_source_all.php:18 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.injection.tainted-filename.tainted-filename`.

References

Source: Sast · Status: Potential

54File name based on user input risks server-side request forgery. CWE-918: Server-Side Request Forgery (SSRF)SsrfA10:2021 Server-Side Request ForgerySastvulnerabilities/view_source_all.php:26Potential

Description

Semgrep rule `php.lang.security.injection.tainted-filename.tainted-filename` matched in `/source/vulnerabilities/view_source_all.php` at line 26. File name based on user input risks server-side request forgery. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (File name based on user input risks server-side request forg) could allow internal network reconnaissance or access to internal services from an external position.

Evidence

vulnerabilities/view_source_all.php:26 $impsrc = @file_get_contents("./{$id}/source/impossible.php"); Original CVSS 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N) is outside the delivered Medium severity band.

Reproduction Steps

1. Navigate to the source file: vulnerabilities/view_source_all.php:26 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.injection.tainted-filename.tainted-filename`.

References

Source: Sast · Status: Potential

56`Echo`ing user input risks cross-site scripting vulnerability. You should use `htmlentities()` when showing data to… CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')XssA03:2021 InjectionSastvulnerabilities/csp/source/jsonp.php:12Potential

Description

Semgrep rule `php.lang.security.injection.echoed-request.echoed-request` matched in `/source/vulnerabilities/csp/source/jsonp.php` at line 12. `Echo`ing user input risks cross-site scripting vulnerability. You should use `htmlentities()` when showing data to users. [provenance: source-derived] This finding was derived from the supplied source repository (SAST / dependency intelligence), NOT observed against the live target. When a repository is shared across targets it applies to the code, not to any single deployed host.

Business Impact

Moderate business risk. This finding (`Echo`ing user input risks cross-site scripting vulnerabilit) could allow session hijacking, credential theft, or malicious content injection affecting end users.

Evidence

vulnerabilities/csp/source/jsonp.php:12 echo $callback . "(".json_encode($outp).")"; Severity capped to Medium: this static-analysis HIGH/CRITICAL was not validated — no confirmed-live secret, reachable dependency path, or proven exploit. Confirm reachability or exploit it to promote the severity.

Reproduction Steps

1. Navigate to the source file: vulnerabilities/csp/source/jsonp.php:12 2. Review the code pattern flagged by semgrep 3. Verify whether user-controlled input reaches the identified sink 4. Confirm exploitability in the application's runtime context

Recommendation

Review and remediate the finding from rule `php.lang.security.injection.echoed-request.echoed-request`.

References

Source: Sast · Status: Potential

Entry Point
Crown Jewel
Service
Endpoint
Host
Credential
Data Store
Exploitable
Priv Escalation
Lateral Move

Click a node to compute blast radius

81 nodes · 99 edges · 1 entry point · 0 crown jewelsDrag to pin · Scroll to zoom · Click for blast radius

Attack Path Analysis

NodesEdgesEntry pointsCrown jewelsCritical pathsShortest path
8199100—