lamp-cloud EUVD-2026-58550

Exploitation requires a valid, authenticated user account with access to the Code Generator component of lamp-cloud (confirmed by PR:L in the CVSS 4.0 vector). The specific vulnerable parameters are outputDir, parent, and projectPrefix submitted to DefGenProjectController.java endpoints. The Code Generator is a standard part of lamp-cloud deployments and no non-default configuration is required to expose the vulnerable functionality. Factors limiting exploitation: the attacker must possess valid credentials and be authorized to invoke the Code Generator API - unauthenticated exploitation is not indicated by the CVSS 4.0 vector (PR:L, not PR:N); the maximum confirmed impact per dimension is Low, suggesting the traversal does not grant unrestricted root-level filesystem access; and no scope change (SC:N/SI:N/SA:N) means lateral movement to other systems is not indicated from available data.

The CVSS 4.0 score of 2.1 reflects bounded, low-severity impact across confidentiality, integrity, and availability (VC:L/VI:L/VA:L), with no subsequent-system impact (SC:N/SI:N/SA:N). This score is notably low, but the presence of a public proof-of-concept (E:P) meaningfully shortens the exploitation timeline for any actor already holding credentials. The vulnerability is not listed in CISA's KEV catalog, indicating no confirmed widespread active exploitation at time of analysis - a meaningful risk-reduction signal given the PoC disclosure. The PR:L requirement is the primary limiting factor: an attacker must hold a valid account with Code Generator access, which restricts the exposed population to authenticated insiders, compromised developer accounts, or multi-tenant deployments with insufficiently scoped access controls. In a dedicated internal development environment with strict role separation, risk is low. However, even a mid-sized municipal IT team in walbrzych operating a shared internal DevOps platform should treat the absence of a vendor patch combined with public exploit disclosure as a priority for compensating controls. The low impact ratings per component (L rather than H or N) suggest traversal is somewhat bounded, but the exact ceiling of file access is not confirmed - full filesystem read/write has not been independently demonstrated from available data.

An authenticated user with Code Generator access submits a crafted HTTP request to the DefGenProjectController endpoint with the outputDir parameter set to a traversal sequence such as ../../../../etc/ or a sensitive application configuration path. The server processes the parameter without sanitization, resolving the traversal and performing a read or write operation outside the intended output directory. Because a public proof-of-concept has been disclosed and referenced in the VulDB submission, an attacker with valid credentials faces minimal technical barriers to exploitation.