ICEcoder EUVD-2026-75453

Exploitation requires a valid ICEcoder user account with at least low-privilege access (PR:L per CVSS 4.0 vector). The attacker must be able to reach the ICEcoder web interface over the network. No special configuration, non-default feature flags, or elevated role is needed beyond basic authentication - the broken confinement check affects all authenticated file-control operations regardless of user role. Exploitation is bounded by two factors: (1) the authentication requirement prevents unauthenticated external attackers from exploiting this directly; (2) the OS-level file permissions of the web server process user set an upper bound on which files can be read, written, or deleted.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) scoring 8.7 is well-calibrated to the actual vulnerability mechanics: network-accessible exploitation requiring only low-privilege authentication with no complexity barriers and no additional preconditions. The broken confinement check is a total bypass rather than a weakened mitigation - once authenticated, any ICEcoder user can immediately leverage it. This vulnerability is not listed in the CISA KEV catalog and no standalone exploit tool is publicly known, but a detailed researcher advisory identifying the exact vulnerable source line is publicly available on GitHub, which substantially lowers the bar for exploitation. The C:H/I:H/A:H impact triad is justified: arbitrary file reads expose credentials and application source code, arbitrary writes enable webshell placement escalating to remote code execution, and arbitrary deletes enable service disruption. The primary limiting factor is the authentication requirement - unauthenticated external attackers cannot directly exploit this - and the OS-level file permissions of the web server process user cap what files are ultimately reachable.

An attacker with any valid ICEcoder account submits a POST request to the file-control endpoint with the file parameter set to a traversal string such as ../../../../etc/passwd or an absolute path like /var/www/html/.env; because File::check() always passes due to the realpath() vs. true comparison error, the server resolves and returns the targeted file. The same mechanism permits writing a PHP webshell to a web-accessible directory, escalating from authenticated file-read to full remote code execution on the host.