【CVE-2026-4588】Pre-Auth shareSafeGroup sk Forgery in kodbox 1.64 Leading to Unauthorized Disclosure of Organization and User Information

Vulnerability ID: VPLUS-2026-12444
Product: kodbox (https://github.com/kalcaddle/kodbox)
Affected Version: 1.64
Severity: High
Vulnerability Type: V09 – Access Control Weakness
Authentication: Pre-Auth (no prior authentication required)
Confidence: 99%
Status: Confirmed
Discovery Time: 2026-02-28 16:46:09

Affected Component / Endpoint

• Product: kodbox 1.64

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

• Function: shareSafeGroup (around line 142)

• Endpoint pattern:
  GET /?explorer/shareOut/shareSafeGroup&sk=<forged_sk>&method=<action>&...

Technical Description / Root Cause

In kodbox 1.64, the shareSafeGroup action relies on a signed parameter sk as the primary access control mechanism for group-related operations. The verification logic for sk is implemented using the Mcrypt class.

When the site-level API key (shareOutSiteApiKey) is not configured (left empty), the verification logic silently falls back to Mcrypt::$defaultKey, a hard-coded default key embedded in Mcrypt.class.php.

Because this default key is static and known in the source code, an attacker can reproduce the signing logic locally and generate valid sk values without any knowledge of deployment-specific secrets. The forged sk is then accepted by the target kodbox 1.64 instance, even for unauthenticated clients, allowing pre-auth calls to sensitive shareSafeGroup methods such as groupList and memberList.

Root cause (V11):

• shareSafeGroup’s sk validation falls back to a hard-coded default key (Mcrypt::$defaultKey) when shareOutSiteApiKey is empty.

• This enables forging of valid signatures for shareSafeGroup requests and bypasses proper authorization checks, resulting in unauthorized disclosure of organization and user information.

Attack Vector

An unauthenticated attacker can directly invoke the affected endpoint using a forged sk generated with the default key logic:

Example request (reading members of groupID=1):

Working PoC (adapted for kodbox 1.64 source layout):

The same forged sk token can be reused for:

to enumerate group structures.

Observed Result / Impact in kodbox 1.64

On a kodbox 1.64 instance, the PoC succeeds without any authenticated session and returns sensitive information:

Example groupList response:

Example memberList response:

Impact on kodbox 1.64:

• Pre-auth unauthorized read of group structure (organization hierarchy).

• Enumeration of groupID, groupPath, and group names.

• Disclosure of user records for the affected groups, including administrator account identifiers and names.

• Facilitates further targeted attacks against privileged accounts (e.g., password guessing, phishing, social engineering).

Duplicate Check

A duplicate check using GET /vulns?exclude_vuln_id=VPLUS-2026-12444 only returned vulnerabilities VPLUS-2026-12440 and VPLUS-2026-12429, both affecting shareMake-related functionality.

The present issue specifically affects shareSafeGroup in kodbox 1.64 and focuses on forged sk tokens enabling pre-auth group and member information disclosure. It is functionally distinct and not a duplicate.

Remediation Recommendations for kodbox 1.64

1. Eliminate the default key fallback:

   • Remove Mcrypt::$defaultKey or ensure it is never used for security-sensitive signing/verification.

   • Fail hard if shareOutSiteApiKey is empty instead of silently falling back.

2. Enforce a strong, non-empty shareOutSiteApiKey:

   • Require a high-entropy, deployment-specific API key for all shareSafeGroup operations.

   • Add installation or startup checks to prevent running with an empty or weak key.

3. Use standard, modern cryptography with identity binding:

   • Replace custom schemes with a standard AEAD mode (e.g., AES-GCM or ChaCha20-Poly1305).

   • Bind tokens to purpose, audience, and expiry; validate all fields strictly when processing sk.

4. Add proper authentication and authorization checks:

   • Do not rely solely on sk for protection of groupList, memberList, and similar operations.

   • Require a valid user session and enforce fine-grained authorization based on the user’s role and group membership.

5. Operational measures:

   • After patching, rotate any keys that may have used the default or weak configuration.

   • Review access logs for unauthenticated requests to explorer/shareOut/shareSafeGroup that returned code=true.