Multi-step exploitation paths where individual vulnerabilities were combined to achieve greater impact.
The attack graph mapped 81 nodes (1 entry point, 0 crown jewels). No exploitable paths to critical assets were confirmed.
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.
Feasibility PROVEN · cheapest-attack effort 1 · success probability 100% · skill low
Cheapest path
Highest-impact fixes (what-if)
Not established (coverage gaps)
Feasibility POSSIBLE · cheapest-attack effort 121 · success probability 54% · skill medium
Cheapest path
Highest-impact fixes (what-if)
Not established (coverage gaps)
Feasibility POSSIBLE · cheapest-attack effort 250 · success probability 50% · skill high
Cheapest path
Highest-impact fixes (what-if)
Not established (coverage gaps)
Feasibility UNKNOWN · cheapest-attack effort 450 · success probability 21% · skill high
Cheapest path
Highest-impact fixes (what-if)
Not established (coverage gaps)
| Severity | Count |
|---|---|
| CRITICAL | 5 |
| HIGH | 7 |
| MEDIUM | 35 |
| LOW | 5 |
| INFO | 4 |
| Total | 56 |
| # | Severity | Title | Category | OWASP | Source | Location / Endpoint | CVSS |
|---|---|---|---|---|---|---|---|
| 9 | HIGH | AUTHZ: Horizontal at GET/POST/PUT/DELETE /vulnerabilities/api/v2/order/{id} | Authz | A01:2021 Broken Access Control | Combined | /var/w | 7.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. | |||||||
| 10 | HIGH | AUTHZ: Horizontal at GET/PUT/DELETE /vulnerabilities/api/v2/user/{id} | Authz | A01:2021 Broken Access Control | Combined | /vulnerabilities/api/v2/user/1 | 7.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. | |||||||
| 11 | HIGH | AUTHZ: Vertical at GET /vulnerabilities/api/v2/user/ | Authz | A01:2021 Broken Access Control | Combined | /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. | |||||||
| 12 | CRITICAL | AUTHZ: Vertical at POST /vulnerabilities/api/v2/login/login (bearer token minting) | Authz | A01:2021 Broken Access Control | Combined | /vulnerabilities/api/v2/login/login | 9.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. | |||||||
| 13 | HIGH | AUTHZ: Vertical at POST/PUT /vulnerabilities/api/v2/user/ (level/role field) | Authz | A01:2021 Broken Access Control | Combined | /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. | |||||||
| 14 | HIGH | CHAIN: Auth Bypass → IDOR → Mass Data Access | Authz | A01:2021 Broken Access Control | Combined | /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. | |||||||
| 18 | CRITICAL | DEFAULT-CREDS: DefaultCredentials at POST /vulnerabilities/api/v2/login/login (password grant) | DefaultCreds | A07:2021 Identification and Authentication Failures | Combined | /vulnerabilities/api/v2/login/login | 9.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. | |||||||
| 23 | HIGH | INFO-DISCLOSURE: InformationDisclosure at GET /vulnerabilities/api/v2/user/ (v1 representation) | InfoDisclosure | A05:2021 Security Misconfiguration | Combined | /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. | |||||||
| 25 | CRITICAL | INFO-DISCLOSURE: InformationDisclosure at Hardcoded credentials/secrets in LoginController and Token.php | InfoDisclosure | A05:2021 Security Misconfiguration | Combined | /vulnerabilities/api/v2/login/login | 8.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. | |||||||
| 47 | CRITICAL | SECRETS: HardcodedCredential at POST /vulnerabilities/api/v2/login/login (LoginController) | Secrets | A02:2021 Cryptographic Failures | Combined | /vulnerabilities/api/v2/login/login | 9.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. | |||||||
| 49 | HIGH | SECRETS: InformationDisclosure at GET /vulnerabilities/api/v2/user/ (v1 representation) | Secrets | A02:2021 Cryptographic Failures | Combined | /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. | |||||||
| 55 | CRITICAL | WEAK-SESSION: WeakSession at POST /vulnerabilities/api/v2/login/login (Token.php AES-128-GCM, hardcoded key 'Paintbrush') | WeakSession | A07:2021 Identification and Authentication Failures | Combined | /vulnerabilities/api/v2/login/login | 9.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. | |||||||
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.
| # | Title | Category | OWASP | Source | Location / Endpoint | Status |
|---|---|---|---|---|---|---|
| 1 | AUTH: Authentication_Bypass at GET /vulnerabilities/api/v2/user/ | Auth | A07:2021 Identification and Authentication Failures | Whitebox | — | 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. | ||||||
| 2 | AUTH: Authentication_Bypass at POST /vulnerabilities/api/v2/login/login | Auth | A07:2021 Identification and Authentication Failures | Combined | /vulnerabilities/api/v2/login/login | Hypothetical |
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. | ||||||
| 3 | AUTH: Login_Flow_Logic at POST /vulnerabilities/api/v2/login/login (secret comparison in Login.php) | Auth | A07:2021 Identification and Authentication Failures | Combined | POST /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. | ||||||
| 4 | CHAIN CHAIN-001: Unauthenticated User Enumeration + Hash Disclosure → Offline Crack → Account Takeover | Auth | A07:2021 Identification and Authentication Failures | Combined | /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. | ||||||
| 5 | CHAIN CHAIN-002: Hardcoded Credentials → Bearer Token Minting → IDOR Order Access | Auth | A07:2021 Identification and Authentication Failures | Combined | /vulnerabilities/api/v2/login/login | Hypothetical |
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. | ||||||
| 6 | CHAIN CHAIN-003: Hardcoded OAuth Client Credentials → Token → Order IDOR | Auth | A07:2021 Identification and Authentication Failures | Combined | /vulnerabilities/api/v2/login/login | Hypothetical |
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. | ||||||
| 7 | CHAIN CHAIN-004: Info Disclosure (Path Leak) → Targeted Source Read → Token Forgery | Auth | A07:2021 Identification and Authentication Failures | Combined | /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. | ||||||
| 8 | CHAIN CHAIN-005: Unauthenticated User Enumeration → Privilege Escalation via level Field | Auth | A07:2021 Identification and Authentication Failures | Combined | /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. | ||||||
| 15 | Executing 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') | Cmdi | A03:2021 Injection | Sast | vulnerabilities/exec/source/high.php:26 | Potential |
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 | ||||||
| 16 | User 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') | Cmdi | A03:2021 Injection | Sast | vulnerabilities/api/src/HealthController.php:88 | Potential |
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 | ||||||
| 17 | Using 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') | Cmdi | A03:2021 Injection | Sast | .github/workflows/docker-image.yml:29 | Potential |
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 | ||||||
| 19 | DEFAULT-CREDS: HardcodedCryptographicSecret at Token.php (AES-128-GCM key "Paintbrush") | DefaultCreds | A07:2021 Identification and Authentication Failures | Whitebox | Token.php | Hypothetical |
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. | ||||||
| 20 | DEFAULT-CREDS: WeakSeededPassword at UserController::addUser / seeded user hashes | DefaultCreds | A07:2021 Identification and Authentication Failures | Combined | UserController::addUser / seeded user hashes | Hypothetical |
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. | ||||||
| 21 | Discovered path: /.gitattributes (200) | InfoDisclosure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 22 | Discovered path: /php.ini (200) | InfoDisclosure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 24 | INFO-DISCLOSURE: InformationDisclosure at GET/POST /vulnerabilities/api/v2/order/ | InfoDisclosure | A05:2021 Security Misconfiguration | Combined | GET/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. | ||||||
| 26 | INFO-DISCLOSURE: InformationDisclosure at POST /vulnerabilities/api/v2/login/login (token in response) | InfoDisclosure | A05:2021 Security Misconfiguration | Combined | POST /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. | ||||||
| 27 | Apache Server Version Disclosure | Infrastructure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 28 | Apache Server Version Disclosure via 403 Error Page | Infrastructure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 29 | CKV_DOCKER_2: Ensure that HEALTHCHECK instructions have been added to container images | Infrastructure | A05:2021 Security Misconfiguration | Sast | — | 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 | ||||||
| 30 | CKV_DOCKER_3: Ensure that a user for the container has been created | Infrastructure | A05:2021 Security Misconfiguration | Sast | — | 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 | ||||||
| 31 | CKV_OPENAPI_21: Ensure that arrays have a maximum number of items | Infrastructure | A05:2021 Security Misconfiguration | Sast | /vulnerabilities/api/openapi.yml:178 | Potential |
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 | ||||||
| 32 | CKV_OPENAPI_4: Ensure that the global security field has rules defined | Infrastructure | A05:2021 Security Misconfiguration | Sast | /vulnerabilities/api/openapi.yml:1 | Potential |
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 | ||||||
| 33 | DVWA (Damn Vulnerable Web Application) Instance Exposed | Infrastructure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 34 | Exposed Sensitive Directories (config, database, docs, external, tests) | Infrastructure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 35 | Exposed php.ini Configuration File | Infrastructure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 36 | GitHub 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 Component | Infrastructure | A05:2021 Security Misconfiguration | Sast | .github/workflows/codeql-analysis.yml:37 | Potential |
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 | ||||||
| 37 | GitHub 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 Component | Infrastructure | A05:2021 Security Misconfiguration | Sast | .github/workflows/codeql-analysis.yml:56 | Potential |
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 | ||||||
| 38 | GitHub 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 Component | Infrastructure | A05:2021 Security Misconfiguration | Sast | .github/workflows/docker-image.yml:16 | Potential |
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 | ||||||
| 39 | GitHub 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 Component | Infrastructure | A05:2021 Security Misconfiguration | Sast | .github/workflows/docker-image.yml:22 | Potential |
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 | ||||||
| 40 | GitHub 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 Component | Infrastructure | A05:2021 Security Misconfiguration | Sast | .github/workflows/shiftleft-analysis.yml:24 | Potential |
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 | ||||||
| 41 | PHP Version Disclosure via X-Powered-By Header | Infrastructure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 42 | Restricted Paths Return 403 (Existence Disclosure) | Infrastructure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 43 | Session Cookie Missing Secure Flag | Infrastructure | A05:2021 Security Misconfiguration | Blackbox | — | 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. | ||||||
| 44 | The 'phpinfo' function may reveal sensitive information about your environment. CWE-200: Exposure of Sensitive Information to an Unauthorized Actor | Infrastructure | A05:2021 Security Misconfiguration | Sast | phpinfo.php:8 | Potential |
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 | ||||||
| 45 | Exposed php.ini Configuration File with Dangerous Settings | Secrets | A02:2021 Cryptographic Failures | Blackbox | — | 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. | ||||||
| 46 | SECRETS: ExposedAPIKey at csrf/help/help.php:54 | Secrets | A02:2021 Cryptographic Failures | Combined | csrf/help/help.php:54 | Potential |
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. | ||||||
| 48 | SECRETS: HardcodedCredential at Token.php (aes-128-gcm key) | Secrets | A02:2021 Cryptographic Failures | Whitebox | Token.php | Hypothetical |
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. | ||||||
| 50 | User 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') | Sqli | A03:2021 Injection | Sast | vulnerabilities/bac/source/low.php:22 | Potential |
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 | ||||||
| 51 | File name based on user input risks server-side request forgery. CWE-918: Server-Side Request Forgery (SSRF) | Ssrf | A10:2021 Server-Side Request Forgery | Sast | instructions.php:26 | Potential |
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 | ||||||
| 52 | File name based on user input risks server-side request forgery. CWE-918: Server-Side Request Forgery (SSRF) | Ssrf | A10:2021 Server-Side Request Forgery | Sast | vulnerabilities/view_source.php:63 | Potential |
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 | ||||||
| 53 | File name based on user input risks server-side request forgery. CWE-918: Server-Side Request Forgery (SSRF) | Ssrf | A10:2021 Server-Side Request Forgery | Sast | vulnerabilities/view_source_all.php:18 | Potential |
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 | ||||||
| 54 | File name based on user input risks server-side request forgery. CWE-918: Server-Side Request Forgery (SSRF) | Ssrf | A10:2021 Server-Side Request Forgery | Sast | vulnerabilities/view_source_all.php:26 | Potential |
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 | ||||||
| 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') | Xss | A03:2021 Injection | Sast | vulnerabilities/csp/source/jsonp.php:12 | Potential |
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
| ||||||
| Nodes | Edges | Entry points | Crown jewels | Critical paths | Shortest path |
|---|---|---|---|---|---|
| 81 | 99 | 1 | 0 | 0 | — |