lamp-cloud CVE-2026-19757

The endpoint FileAnyoneController.java must be reachable from the network; the 'Anyone' naming convention strongly implies it is publicly exposed without authentication by design. No special configuration is required beyond a standard lamp-cloud deployment on an affected version (up to 5.10.0). Exploitation is NOT limited by authentication (PR:N per CVSS vector), user interaction (UI:N), or attack complexity (AC:L). The practical upper bound on impact depends on the server's file system permissions for the running process and whether any web-accessible directories are reachable via traversal - if the application runs with broad write permissions, impact escalates to potential remote code execution via web shell upload.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) indicates fully remote, unauthenticated, low-complexity exploitation with no special attack requirements - the highest-priority exploitation profile. However, impact is rated Low across Confidentiality, Integrity, and Availability (VC:L/VI:L/VA:L), capping the overall score at 5.5. The E:P modifier confirms a public proof-of-concept exists, elevating practical risk above the raw score suggests. No CISA KEV listing means active widespread exploitation is not confirmed, but the combination of unauthenticated access, trivial exploitation, and public PoC makes exploitation plausible in the near term. The absence of vendor response - confirmed by the referenced GitHub issue #412 - means no official patch window exists, making this a live unmitigated risk for all deployments on affected versions. The low impact ratings likely reflect that directory traversal in an upload context provides partial file write/read rather than full RCE, though chaining with other vulnerabilities (e.g., uploading a JSP shell to a web-accessible path) could escalate impact substantially.

An unauthenticated remote attacker submits a crafted HTTP file-upload request to the FileAnyoneController endpoint, injecting path traversal sequences (e.g., '../../webapps/ROOT/') into the bucket or bizType parameter. The server resolves the traversed path and writes the uploaded file outside the intended storage directory - potentially into a web-accessible location, enabling follow-on code execution. A public proof-of-concept exists that likely demonstrates this payload construction.