Someone left a skeleton key taped under the doormat of a rarely-visited shed
CVE-2026-5618 is a pre-authentication Server-Side Request Forgery (SSRF) in kalcaddle kodbox ≤ 1.64, a self-hosted PHP web file manager. The vulnerable endpoints are explorer/shareOut/shareMake and shareCheck. A hard-coded cryptographic key (kodShareOut) used in a custom Mcrypt-based _check token design allows an unauthenticated attacker to forge authorization tokens offline, then create or modify external collaboration ("shareOut") records. By manipulating the siteFrom/siteTo parameters, the attacker can coerce the server into making HTTP requests to attacker-controlled or internal URLs — classic blind SSRF. Versions 1.0 through 1.64 are affected; versions 1.65.03+ appear to address the issue, though the vendor never publicly acknowledged the flaw.
The vendor's MEDIUM / 5.6 CVSS 3.1 score overstates the real-world risk. NVD's own CVSS 4.0 re-score landed at 2.9 (LOW), which is closer to reality. The SSRF yields only Low confidentiality, Low integrity, Low availability impact — there is no documented path to full response read-back, RCE, or credential theft. The affected product is a niche self-hosted file manager with roughly 3,500 internet-facing instances per Shodan, overwhelmingly operated by hobbyists and small businesses, not enterprise-scale deployments. The combination of limited blast radius, tiny exposure population, and no evidence of in-the-wild exploitation makes this a backlog item, not a fire drill.
4 steps from start to impact.
Identify internet-facing kodbox instance
title:"KodBox" or known URI paths like /index.php?explorer/). Roughly 3,500 instances are publicly indexed. The attacker selects a target running version ≤ 1.64.- Target kodbox instance is internet-facing
- Target runs version ≤ 1.64
- Only ~3,500 instances globally on Shodan — finding a valuable enterprise target is unlikely
- Many instances are on personal/hobby servers with no internal network worth probing
title:KodBox or http.favicon.hash matching kodbox faviconForge shareOut _check token offline
kodShareOut and the Mcrypt-based _check function from Mcrypt.class.php to forge a valid authorization token entirely offline. No interaction with the target is needed for this step. The PoC Bash script published by the researcher automates this.- Knowledge of the hard-coded key (public since disclosure)
- Ability to run the Mcrypt encryption locally (PHP or equivalent)
- Requires reading the PoC and replicating the Mcrypt logic — trivial for a competent attacker but not point-and-click
Submit forged SSRF request via shareMake
explorer/shareOut/shareMake with the forged _check token and a siteFrom/siteTo parameter pointing to an internal URL (e.g., http://169.254.169.254/latest/meta-data/ for cloud metadata, or an internal service). The server issues the HTTP request server-side. Response data may or may not be returned to the attacker depending on the kodbox code path — the CVSS C:L rating suggests limited or blind SSRF.- Forged token from Step 2
- Target server can reach the internal URL
- Blind or partial-read SSRF limits what the attacker can exfiltrate
- Cloud metadata endpoints may be protected by IMDSv2 (AWS) or equivalent
- Internal network segmentation limits reachable targets
siteFrom/siteTo parameters for internal IP ranges (RFC 1918, link-local). Server-side: monitor outbound HTTP from the kodbox process to unexpected destinations.Leverage SSRF for internal reconnaissance or limited data access
- SSRF response is at least partially returned to the attacker
- Interesting internal services are reachable from the kodbox host
- No demonstrated escalation to RCE or full data exfiltration
- Modern cloud deployments mitigate metadata SSRF via IMDSv2/metadata concealment
- Network segmentation limits lateral reach
The supporting signals.
| In-the-Wild Exploitation | No evidence. Not listed in CISA KEV. No known campaigns or threat actor usage documented as of 2026-08-24. |
|---|---|
| Proof of Concept | Public. A Bash PoC script demonstrating token forging and SSRF via the shareMake endpoint was published by the researcher alongside disclosure. Available via vulnplus-note. |
| EPSS Score | 0.00323 (0.32nd percentile) — negligible exploitation probability in the next 30 days. |
| KEV Status | Not listed. No CISA KEV entry. |
| CVSS 3.1 Vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L — Network-accessible, no auth required, but High complexity and Low impact across all three CIA pillars. No scope change. |
| CVSS 4.0 Score | 2.9 (LOW) per NVD reassessment — significantly lower than the 3.1 score of 5.6. |
| Affected Versions | kodbox 1.0 through 1.64 (all releases prior to 1.65). |
| Fixed Version | 1.65.03 (released 2026-03-30). Vendor never acknowledged the vulnerability; fix was inferred from version timeline. Latest release is 1.69.03 (2026-08-21). |
| Exposure Data | ~3,500 instances indexed on Shodan. Predominantly small/hobbyist deployments. No significant enterprise footprint documented. |
| Disclosure & Credit | Disclosed 2026-04-06 via VulDB. Vendor was contacted early but did not respond. Researcher identity linked to vulnplus-note writeup. |
noisgate verdict.
The single most decisive factor is the minuscule exposure population (~3,500 internet instances, virtually zero enterprise footprint) combined with a terminal impact ceiling of Low CIA — no demonstrated path to RCE, credential theft, or lateral movement. The affected component is a niche self-hosted file manager that does not occupy any high-value deployment role (not an IdP, hypervisor, backup server, CI/CD system, or network edge appliance), so no blast-radius floor applies.
Why this verdict
- Tiny exposure population: ~3,500 internet-facing instances globally, overwhelmingly hobbyist/small-business — finding a high-value enterprise target is a needle-in-a-haystack exercise.
- Limited SSRF impact: CVSS rates C:L/I:L/A:L with no scope change. No researcher or PoC has demonstrated escalation to RCE, full file read, or credential theft. This is blind or partial-read SSRF at best.
- No high-value role multiplier: kodbox is a web file manager. It is not deployed as an identity provider, domain controller, hypervisor, CI/CD server, backup appliance, or network edge device. The blast radius of compromise is limited to the kodbox host and its locally stored files — no fleet-scale, identity-scale, or supply-chain impact.
- Role multiplier: Evaluated against the high-value role catalog — kodbox does not match any category. In its typical deployment (standalone file-sharing server on a small network), compromise yields access to one host's files. Even in the rare case of an enterprise deployment with AD integration, the SSRF itself does not yield credentials or tokens that would enable domain escalation.
- Modern compensating controls reduce residual risk: IMDSv2 blocks cloud metadata SSRF; network segmentation limits internal reach; WAF rules can block RFC 1918 addresses in request parameters.
Why not higher?
The pre-authentication nature and public PoC initially suggest concern, but the SSRF impact is capped at Low CIA with no demonstrated escalation. The product has no meaningful enterprise installed base — it is not infrastructure software. There is no KEV listing, no active exploitation, and EPSS is in the bottom 1%. Upgrading to MEDIUM would overstate the risk to an enterprise defender managing 10,000 hosts who almost certainly has zero kodbox instances.
Why not lower?
Despite the tiny footprint, this is still a pre-auth vulnerability with a public PoC that could be weaponized against the small number of exposed instances. The hard-coded key effectively negates the AC:H rating since the key is now public knowledge, making exploitation more reliable than the CVSS vector implies. Marking IGNORE would be inappropriate if even one kodbox instance exists in the environment.
What to do — in priority order.
- Block external access to kodbox or place behind VPN/zero-trust proxy — If you run kodbox, it should not be directly internet-facing. Place it behind a VPN, Cloudflare Access, Tailscale, or similar zero-trust gateway. This eliminates the remote attack vector entirely. No noisgate mitigation SLA applies for LOW — treat as backlog hygiene.
- Upgrade to kodbox ≥ 1.65.03 — The fix appears to ship in 1.65.03 (2026-03-30). Latest is 1.69.03. Upgrade at your convenience within the noisgate remediation window for LOW (backlog).
- WAF rule blocking internal IPs in siteFrom/siteTo parameters — If you must keep kodbox internet-facing temporarily, add a WAF rule that rejects requests to
explorer/shareOut/shareMakecontaining RFC 1918, link-local (169.254.x.x), or localhost addresses in thesiteFrom/siteToparameters. - Enforce IMDSv2 on cloud instances — If kodbox runs on AWS/GCP/Azure, enforce IMDSv2 (or equivalent) to prevent SSRF-based cloud metadata theft. This is a general hygiene measure that neutralizes the most valuable SSRF target.
- Application-layer authentication hardening — the vulnerability bypasses authentication entirely via the hard-coded key, so enforcing stronger passwords or MFA on kodbox user accounts does not help.
- IP allowlisting on kodbox itself — kodbox does not natively support IP-based access restrictions at the application layer; this must be done at the network/reverse-proxy level.
- Disabling the shareOut feature via UI settings — no documented configuration toggle exists to disable the affected endpoint without code modification.
Crowdsourced verification payload.
Run this on the kodbox host (or any host that can reach the kodbox web root directory) as a user with read access to the kodbox PHP files. Example: bash check_cve_2026_5618.sh /var/www/kodbox
#!/usr/bin/env bash
# CVE-2026-5618 checker for kalcaddle kodbox
# Checks installed version against the fix threshold (1.65.03)
# Usage: bash check_cve_2026_5618.sh /path/to/kodbox
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
KODBOX_ROOT="${1:-/var/www/kodbox}"
VERSION_FILE="$KODBOX_ROOT/config/version.php"
if [ ! -f "$VERSION_FILE" ]; then
# Try alternate location
VERSION_FILE="$KODBOX_ROOT/app/controller/config.php"
fi
if [ ! -f "$VERSION_FILE" ]; then
echo "UNKNOWN — Could not locate kodbox version file at $KODBOX_ROOT"
exit 2
fi
# Extract version string
VERSION=$(grep -oP "['\"]version['\"]\s*=>\s*['\"]\K[0-9.]+" "$VERSION_FILE" 2>/dev/null || true)
if [ -z "$VERSION" ]; then
# Fallback: look for KOD_VERSION constant
VERSION=$(grep -oP "KOD_VERSION['\",\s]+['\"]\K[0-9.]+" "$VERSION_FILE" 2>/dev/null || true)
fi
if [ -z "$VERSION" ]; then
echo "UNKNOWN — Could not parse version from $VERSION_FILE"
exit 2
fi
echo "Detected kodbox version: $VERSION"
# Compare versions (1.65.03 is the fix threshold)
# Normalize: 1.64 -> 1.64.0, 1.65.03 -> 1.65.03
version_gte() {
printf '%s\n%s' "$2" "$1" | sort -t. -k1,1n -k2,2n -k3,3n -C
}
FIX_VERSION="1.65.03"
if version_gte "$VERSION" "$FIX_VERSION"; then
echo "PATCHED — kodbox $VERSION >= $FIX_VERSION (CVE-2026-5618 fixed)"
exit 0
else
echo "VULNERABLE — kodbox $VERSION < $FIX_VERSION (CVE-2026-5618 applies)"
# Also check for the hard-coded key as confirmation
if grep -rq 'kodShareOut' "$KODBOX_ROOT/app/" 2>/dev/null; then
echo " Confirmed: hard-coded key 'kodShareOut' found in source"
fi
exit 1
fiIf you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.