phpUploader before 2

phpUploader (the shimosyan/phpUploader project, a small Japanese PHP file-sharing script) before 2.0.2 runs an unbounded SELECT * on the uploaded-files table in the index controller and JSON-encodes the entire result set into an inline <script> block on every page load. Any unauthenticated visitor who right-clicks → View Source gets the complete database: uploader IP addresses, internal filenames, SHA-256 content fingerprints, comments, and Argon2ID password-derived key hashes for password-protected uploads. The flaw affects all versions prior to 2.0.2; the fix scopes the query to the current page and strips sensitive columns before serialization.

Vendor (NVD-style) HIGH/7.5 is technically defensible under CVSS — it is genuinely network-reachable, unauthenticated, and high-impact on confidentiality with no integrity or availability touch (C:H/I:N/A:N). But CVSS doesn't price *who runs this software*. phpUploader is a personal/club file-share script with an installed base measured in the low thousands worldwide and effectively zero enterprise footprint. For a defender managing 10,000 hosts, the realistic question is whether this is on any of yours — almost certainly not — and if it is, it's shadow IT, not a tier-1 system.

Why this verdict

• Friction — exposure population is tiny. Shodan shows fewer than ~500 public phpUploader instances worldwide. The CVSS network vector is accurate but the reachable target set is rounding error against the public web.
• Friction — payoff is metadata-only. The leak exposes filenames, IPs, SHA-256 content hashes, and Argon2ID key_hash values. There is no path to RCE, file overwrite, or auth bypass; the most sensitive item (key_hash) is memory-hard and economically uncrackable at scale.
• Role multiplier: low-value role only. phpUploader is by definition a community/personal file-share. It is not deployed as an identity provider, hypervisor, CA, backup admin, kernel-mode agent, or edge appliance. The deployment-role floor does NOT apply — there is no high-value role this component occupies in any real enterprise.
• No KEV, no observed exploitation, expected EPSS <0.5%. The threat-intel signal is consistent with the friction story.

Why not higher?

HIGH (the vendor bucket) would be appropriate if this were a widely-deployed component or if the leaked data enabled lateral movement, credential theft against re-used passwords on other systems, or direct RCE. None of those apply: the data leaks within a closed system, the password material is Argon2ID-protected, and the population is tiny.

Why not lower?

LOW understates a genuine unauthenticated remote confidentiality breach that exposes uploader IP addresses — a real privacy and doxing risk for users of the platform — and password-derived hashes that, while expensive, are not impossible to attack for high-value individual passwords. An operator with this software in production owes their users a patch.

1. Upgrade to phpUploader 2.0.2 — Single-command pull from the upstream GitHub release. This is the actual fix; given MEDIUM verdict, deploy inside the noisgate remediation SLA of 365 days, but since the patch is trivial there is no reason not to do it inside a week.
2. Front the application with HTTP basic auth or an SSO proxy (oauth2-proxy, Authelia, Cloudflare Access) until patched — Cuts the unauthenticated reach entirely. Appropriate for the MEDIUM bucket where there is no mitigation SLA — use this if you cannot patch immediately and the instance is internet-facing.
3. Take the instance off the public internet — If the workload is internal-only file-sharing among known users, bind it to a VPN/Tailscale interface. Eliminates the entire attack class for this CVE and dozens of future ones.
4. Rotate any passwords that uploaders may have reused — Notify users that filenames/IPs were potentially exposed and that upload passwords (though hashed with Argon2ID) should be rotated if reused elsewhere. Standard breach-disclosure hygiene.

Run from any auditor workstation with network reach to the target. No privileges needed — this is an unauthenticated probe of the public response. Example: ./check_cve_2026_56124.sh https://uploader.example.jp

#!/usr/bin/env bash
# check_cve_2026_56124.sh — Detect phpUploader < 2.0.2 unauth info disclosure
# Usage: ./check_cve_2026_56124.sh <base-url>
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 https://host[:port]" >&2
  exit 2
fi

BODY=$(curl -fsSL --max-time 10 -A 'noisgate/1.0 cve-2026-56124-check' "$TARGET/" 2>/dev/null) || {
  echo "UNKNOWN (HTTP fetch failed)"; exit 2; }

# Quick fingerprint — confirm we're hitting phpUploader at all
if ! grep -qi 'phpUploader' <<< "$BODY"; then
  echo "UNKNOWN (target does not appear to be phpUploader)"; exit 2
fi

# Vulnerable signature: inline file-data JSON containing sensitive columns
if grep -Eq 'var[[:space:]]+fileData[[:space:]]*=[[:space:]]*\{' <<< "$BODY" && \
   grep -Eq '"(ip|key_hash)"[[:space:]]*:' <<< "$BODY"; then
  echo "VULNERABLE — inline fileData with ip/key_hash columns present"
  exit 1
fi

# Patched: 2.0.2 still emits a fileData var but without ip/key_hash columns
if grep -Eq 'var[[:space:]]+fileData[[:space:]]*=[[:space:]]*\{' <<< "$BODY"; then
  echo "PATCHED (fileData present but sensitive columns absent)"
  exit 0
fi

echo "UNKNOWN (no fileData bootstrap found — custom theme or non-default config)"
exit 2

Sources

1. shimosyan/phpUploader — upstream repository
2. phpUploader releases page (2.0.2 fix)
3. CWE-359: Exposure of Private Personal Information to an Unauthorized Actor
4. NVD — CVE-2026-56124 record
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS model
7. OWASP — Information Disclosure
8. Argon2 RFC 9106 — parameter guidance