← Back to Feed CACHED · 2026-08-24 12:49:00 · CACHE_KEY CVE-2026-5618
CVE-2026-5618 · CWE-918 · Disclosed 2026-04-06

A vulnerability was detected in kalcaddle kodbox up to 1.64.

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.

"Pre-auth SSRF in a niche file manager with ~3.5K internet instances — low blast radius, patch at leisure."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify internet-facing kodbox instance

The attacker scans for kodbox login pages using Shodan/FOFA/Censys fingerprints (e.g., 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.
Conditions required:
  • Target kodbox instance is internet-facing
  • Target runs version ≤ 1.64
Where this breaks in practice:
  • 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
Detection/coverage: Shodan/Censys queries: title:KodBox or http.favicon.hash matching kodbox favicon
STEP 02

Forge shareOut _check token offline

The attacker uses the publicly known hard-coded key 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.
Conditions required:
  • Knowledge of the hard-coded key (public since disclosure)
  • Ability to run the Mcrypt encryption locally (PHP or equivalent)
Where this breaks in practice:
  • Requires reading the PoC and replicating the Mcrypt logic — trivial for a competent attacker but not point-and-click
STEP 03

Submit forged SSRF request via shareMake

The attacker sends a crafted POST to 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.
Conditions required:
  • Forged token from Step 2
  • Target server can reach the internal URL
Where this breaks in practice:
  • 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
Detection/coverage: WAF rules inspecting siteFrom/siteTo parameters for internal IP ranges (RFC 1918, link-local). Server-side: monitor outbound HTTP from the kodbox process to unexpected destinations.
STEP 04

Leverage SSRF for internal reconnaissance or limited data access

If the SSRF returns partial responses, the attacker can enumerate internal services, probe cloud metadata, or interact with unauthenticated internal APIs. The documented impact ceiling is Low across CIA — no known path to RCE, credential theft, or full file read has been demonstrated. This is the terminal step of the documented chain.
Conditions required:
  • SSRF response is at least partially returned to the attacker
  • Interesting internal services are reachable from the kodbox host
Where this breaks in practice:
  • No demonstrated escalation to RCE or full data exfiltration
  • Modern cloud deployments mitigate metadata SSRF via IMDSv2/metadata concealment
  • Network segmentation limits lateral reach
Detection/coverage: Network IDS/IPS rules for unexpected outbound connections from web-tier hosts. Cloud provider metadata protection (IMDSv2 enforcement).
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo evidence. Not listed in CISA KEV. No known campaigns or threat actor usage documented as of 2026-08-24.
Proof of ConceptPublic. 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 Score0.00323 (0.32nd percentile) — negligible exploitation probability in the next 30 days.
KEV StatusNot listed. No CISA KEV entry.
CVSS 3.1 VectorCVSS: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 Score2.9 (LOW) per NVD reassessment — significantly lower than the 3.1 score of 5.6.
Affected Versionskodbox 1.0 through 1.64 (all releases prior to 1.65).
Fixed Version1.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 & CreditDisclosed 2026-04-06 via VulDB. Vendor was contacted early but did not respond. Researcher identity linked to vulnplus-note writeup.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.5/10)

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.

HIGH Vulnerability mechanics and attack path
HIGH Affected version range and fix availability
MEDIUM Exposure population (Shodan count may undercount non-standard ports)
LOW Whether vendor silently patched in 1.65 vs. a later release

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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).
  3. 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/shareMake containing RFC 1918, link-local (169.254.x.x), or localhost addresses in the siteFrom/siteTo parameters.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
fi
07 · Bottom Line

If you remember one thing.

TL;DR
If you're managing 10,000 enterprise hosts, you almost certainly have zero kodbox instances — confirm with an asset scan and move on. If you do find one, it's a niche self-hosted file manager, not infrastructure. The noisgate reassessed verdict is LOW, which carries no mitigation SLA — treat it as backlog hygiene. Upgrade to kodbox ≥ 1.65.03 (ideally the latest 1.69.03) within the noisgate remediation SLA for LOW (no fixed deadline; prioritize below MEDIUM and above). In the interim, ensure the instance is not internet-facing — place it behind a VPN or zero-trust proxy. There is no active exploitation, no KEV listing, and EPSS is 0.3%, so this is not worth pulling resources from higher-priority patching.

Sources

  1. NVD — CVE-2026-5618
  2. VulDB Entry #355408
  3. Vulnerability-Lookup — CVE-2026-5618
  4. GHSA-582G-J67J-5Q79 — GitHub Advisory
  5. kodbox GitHub Releases
  6. kodbox GitHub Repository
  7. THREATINT — CVE-2026-5618
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.