Eladmin CVE-2026-108688

Requires a valid low-privileged authenticated Eladmin account (PR:L) with network access to the application's API; no user interaction or elevated privileges are needed. The specific trigger is a POST request carrying an image-named file to the /api/localStorage/pictures endpoint handled by LocalStorageController's uploadPicture method, which fails to enforce the storage:add permission. Exploitation is limited by the authentication requirement - fully anonymous/unauthenticated exploitation is NOT possible - and is constrained to Eladmin versions through 2.7; impact is bounded to unauthorized file writes into local storage and disclosure of absolute server paths rather than arbitrary code execution.

This is a moderate-severity, authorization-bypass issue that is a secondary-tier priority rather than an emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and 5.3 base score show a network-reachable, low-complexity flaw, but exploitation requires an existing low-privileged authenticated account (PR:L), which meaningfully narrows the attacker population to insiders or already-compromised accounts. Impact is limited (VI:L, with information disclosure of absolute server paths), so this is not a critical RCE or full-takeover bug. Public exploit code exists (GitHub POC plus a VulnCheck advisory), which raises the practical likelihood that it will be used opportunistically against exposed Eladmin instances, but the absence of a CISA KEV listing means there is NO confirmation of active exploitation in the wild. No EPSS score was provided, so widespread-exploitation probability cannot be quantified from the input. Net: prioritize patching for internet-exposed or multi-tenant Eladmin deployments where low-privileged accounts are untrusted, but treat it below unauthenticated or critical-impact CVEs.

A low-privileged authenticated Eladmin user (or an attacker who has obtained any low-level account) sends a crafted POST request with an image-named file to /api/localStorage/pictures, bypassing the storage:add permission check that should gate the operation. The upload succeeds and writes the file to server local storage while the response discloses the absolute server filesystem path, giving the attacker unauthorized write capability and reconnaissance data. A public proof-of-concept script (poc_localStorage_pictures.py) demonstrating this is available on GitHub.