Kodbox 1.64 Pre-Auth SSRF via Forged ShareOut _check Token

Vulnerability Report – VPLUS-2026-12429

1. Basic Information

• Vulnerability ID: VPLUS-2026-12429

• Title: KodExplorer 4.52: Pre-Auth ShareOut Endpoint Allows Unauthenticated Share Modification via Forged _check Token

• Product: KodExplorer – Web File Manager

• Product URL (GitHub): https://github.com/kalcaddle/kodbox

• Affected Version:

  • Confirmed on Kodbox 1.64

  • Other versions: not tested

• Severity: High

• Vulnerability Type: V17 – Missing Authorization / Access Control

• Authentication: Pre-Auth (no login required)

• Confidence: 99%

• Verification Status: Confirmed (reproduced with PoC)

• CVSS: Not assigned

• CVE: Not assigned

• Discovery Time: 2026-02-28 16:38:46

2. Description

In Kodbox 1.64, the explorer/shareOut/shareMake endpoint uses a _check parameter to guard sensitive share-out operations. This parameter is validated via Mcrypt::decode(..., "kodShareOut") using a hard-coded symmetric key.

Because the key "kodShareOut" is embedded in the codebase, any party with access to a KodExplorer installation or source code can forge valid _check tokens offline. The application then accepts these forged tokens as if they were legitimate, allowing unauthenticated users to call sensitive endpoints that manage external collaboration shares.

This results in:

• Unauthenticated creation and modification of external collaboration (shareOut) configurations, including targeting high-privilege users such as admin.

• Attacker-controlled server-side requests through the siteFrom and siteTo parameters, which may lead to SSRF-like behavior depending on how those URLs are used.

The core issues are a combination of missing authorization and cryptographic misuse.

3. Affected Components

• Product: KodExplorer 4.52

• Repository: https://github.com/kalcaddle/KodExplorer

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

• Function: shareMake

• Line: 24 (vulnerable entry point)

Supporting code uses:

• Mcrypt::decode(..., "kodShareOut") for _check validation with a hard-coded key.

4. Attack Vector

An unauthenticated remote attacker can directly invoke the vulnerable endpoint using a crafted HTTP GET request with a forged _check:

Characteristics:

• No authentication cookie or token is required in KodExplorer 4.52.

• A valid-looking _check is sufficient for the server to accept the operation.

• All business parameters (shareOut, shareID, shareUser, siteTo, etc.) are attacker-controlled.

5. Technical Details / Root Cause

In KodExplorer 4.52, the _check parameter for shareMake (and related endpoints) is validated using a custom Mcrypt-based mechanism:

Specific weaknesses:

1. Hard-coded symmetric key ("kodShareOut"):

   • The key is part of the distributed code (https://github.com/kalcaddle/KodExplorer), and thus not secret.

   • Anyone can reproduce Mcrypt::encode(..., "kodShareOut") locally to generate valid tokens for arbitrary data.

2. Custom, non-standard crypto scheme (Mcrypt/MD5-style misuse):

   • Mcrypt is deprecated and unsafe for new designs.

   • The scheme is used as an authorization token, but it is not:

     • Bound to a user session,

     • Bound to time (no expiration),

     • Protected against replay,

     • Backed by a modern AEAD or HMAC construction.

3. Missing real authorization checks in KodExplorer:

   • For explorer/shareOut/shareMake in 4.52, possession of a valid _check token is effectively treated as sufficient to perform privileged operations.

   • There is no server-side enforcement that the caller is logged in or has the right permission to edit the specified share.

Consequently, any attacker who can run the KodExplorer crypto code (e.g., with a cloned copy from GitHub) can forge _check tokens and call privileged endpoints on a production instance without authentication.

6. Proof of Concept (PoC)

6.1. PoC Script (Kodbox 1.64)

The following Bash script, using the Kodbox 1.64 Mcrypt.class.php from the GitHub repository, demonstrates the vulnerability:

6.2. PoC Execution Result

Executing the above against a KodExplorer 4.52 instance (unauthenticated) returns:

This confirms that the share record is edited/created without any login on the KodExplorer 4.52 server.

7. Independent Agent Verification

A de-duplication check was first done via:

Result:

indicating no prior record.

The agent then generated a _check value using KodExplorer’s own Mcrypt::encode logic:

shareCheck request (KodExplorer 4.52):

shareCheck response:

shareMake request (KodExplorer 4.52):

shareMake response:

Outcome on KodExplorer 4.52:

• The forged _check is accepted.

• shareCheck returns ok:check.

• shareMake successfully edits share ID 1 without any authentication.

8. Impact

On KodExplorer 4.52:

1. Unauthorized share manipulation:

   • An unauthenticated attacker can create or modify external collaboration (“shareOut”) records.

   • They can assign permissions (e.g., auth: "read") to high-privilege users such as admin.

2. Potential SSRF or internal interactions:

   • siteFrom and siteTo parameters can be set to attacker-controlled URLs.

   • If KodExplorer performs server-side HTTP requests to these URLs, this may be leveraged for SSRF against internal services.

3. Bypass of authentication and authorization model:

   • The attacker does not need a valid user account on the KodExplorer instance.

   • All protection rests on a forgeable _check token derived from a public, hard-coded key.

This results in a high-severity breach of integrity and potentially confidentiality within KodExplorer deployments.

9. Remediation Recommendations

For KodExplorer (repository: https://github.com/kalcaddle/KodExplorer), especially version 4.52:

1. Enforce proper auth on shareOut endpoints:

   • Require a valid authenticated session for shareCheck and shareMake except for strictly defined public operations.

   • Ensure only the share owner or authorized admin can create, edit, or delete share records.

2. Remove the hard-coded key "kodShareOut":

   • Replace it with a per-deployment high-entropy secret stored in configuration or a secret manager (not in code).

   • Support secret rotation.

3. Replace custom Mcrypt/MD5-like scheme:

   • Stop using Mcrypt and any custom crypto as an authorization mechanism.

   • Use well-reviewed primitives:

     • AEAD (e.g., AES-GCM, ChaCha20-Poly1305), or

     • HMAC (e.g., HMAC-SHA256) over canonicalized parameters.

4. Bind tokens to context and time if tokens remain necessary:

   • Include a timestamp and expiry.

   • Include a nonce to mitigate replay.

   • Cover all sensitive parameters (siteFrom, siteTo, shareID, shareUser, shareOut, etc.) in the MAC/AEAD.

5. Restrict siteFrom / siteTo behavior:

   • If any server-side request is performed:

     • Enforce allowlists or domain restrictions.

     • Block internal IP ranges and cloud metadata endpoints.

     • Limit to necessary protocols (http/https only, if applicable).

6. Logging and monitoring:

   • Log all calls to explorer/shareOut/shareCheck and explorer/shareOut/shareMake with user (if any), IP, and parameters.

   • After patching, review historical logs on KodExplorer 4.52 deployments to detect suspicious share changes or unusual siteTo values.

10. Summary

KodExplorer 1.64 contains a high-severity vulnerability in the explorer/shareOut/shareMake endpoint. A hard-coded cryptographic key and custom Mcrypt-based _check design allow attackers to forge authorization tokens offline and perform unauthenticated share modifications and potentially attacker-controlled server-side requests.

Remediation requires:

• Adding proper authentication/authorization checks for share management in KodExplorer.

• Replacing the hard-coded key and custom crypto with modern, secret, and per-deployment cryptographic mechanisms.