EUVD-2026-52741
GHSA-g2rg-5634-4c27
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable via template API (AV:N, AC:L), low-privilege session required (PR:L), no scope change as impact is confined to the vulnerable server process (S:U).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
3DescriptionCVE.org
LAMP Rapid Development Platform through 5.6.2, fixed in commit 84b0c27, contains a remote code execution vulnerability in GlueFactory that executes unsandboxed Groovy scripts from database template fields without compilation restrictions or whitelisting. Attackers can write or influence the script field via message template endpoints to execute arbitrary Groovy code and OS commands on the backend server.
AnalysisAI
Remote code execution in LAMP Rapid Development Platform (dromara lamp-cloud) through version 5.6.2 allows low-privileged authenticated attackers to inject arbitrary Groovy code into message template script fields processed by the GlueFactory component, resulting in OS command execution on the backend server with the privileges of the Java process. The GlueFactory compiled and ran these scripts via GroovyClassLoader with no sandboxing, AST restrictions, or class whitelisting in place. A publicly available exploit exists via GitHub issue #408, and CVSS 4.0 rates this 8.7 with full confidentiality, integrity, and availability impact on the vulnerable system.
Technical ContextAI
The vulnerability is rooted in GlueFactory.java (lamp-base/lamp-base-biz/src/main/java/top/tangyh/lamp/msg/glue/GlueFactory.java) within the dromara lamp-cloud platform (CPE: cpe:2.3:a:dromara:lamp-cloud:*:*:*:*:*:*:*:*). The component exists to support dynamic message templating - Groovy scripts are persisted in database template fields, then loaded and compiled at runtime via Apache Groovy's GroovyClassLoader. CWE-94 (Improper Control of Generation of Code) is the root cause: user-controllable script content was passed directly to GroovyClassLoader.parseClass() without any sanitization, compilation-time restrictions, SecureASTCustomizer configuration, or runtime sandbox. The commit diff for fix 84b0c27 reveals the maintainers explicitly noted that SecureASTCustomizer.setDisallowedReceiversClasses was ineffective against dynamic Groovy due to Meta-Object Protocol dispatch, and instead implemented a multi-layer source-level defense: a DANGEROUS_TOKENS blacklist (blocking Runtime, ProcessBuilder, File I/O classes, reflection APIs, ClassLoader variants, GroovyShell, System.exit, sockets, and serialization), DANGEROUS_CALL_PATTERNS regex matching (covering .execute(), .exec(), .forName(), @ASTTest, @Grab, and string-interpolated dynamic references), and a stripStringLiterals() preprocessor to prevent false positives. The attack surface is the message template management API endpoints that write to the script database field.
RemediationAI
Apply the upstream fix at commit 84b0c27d3693e468c2c690d9fbc8ea9c22cd34e3 (https://github.com/dromara/lamp-cloud/commit/84b0c27d3693e468c2c690d9fbc8ea9c22cd34e3), which introduces multi-layer Groovy script safety validation including a dangerous token blacklist, regex-based dangerous call pattern detection, and string-literal stripping to reduce bypass surface. A specifically tagged patched release version has not been independently confirmed - verify with the upstream dromara project (https://github.com/dromara/lamp-cloud) whether a release after 5.6.2 incorporates this commit before deploying. As an interim compensating control, restrict access to the message template management endpoints to the smallest possible set of trusted administrative users via application-level role controls or network ACLs, directly reducing the pool of principals who can inject into the script field. Note that the fix itself uses a blacklist approach, which the commit's own comments acknowledge has inherent bypass risks for dynamic Groovy - this should be treated as a strong mitigation layer rather than an absolute sandbox boundary, and a defense-in-depth posture (process isolation, least-privilege OS user for the Java process, egress filtering) is advisable even post-patch.
More in Lamp Cloud
View allUnauthenticated information disclosure in Dromara lamp-cloud through 5.10.0 stems from an overly broad anonymous-access
Dromara Lamp-Cloud before v3.8.1 was discovered to use a hardcoded cryptographic key when creating and verifying a Json
Server-side template injection (SSTI) in Dromara lamp-cloud versions 5.6.0 through 5.6.2 exposes the Message Template Ha
Improper authorization in Dromara lamp-cloud up to version 5.8.1 allows authenticated remote attackers to bypass access
Same weakness CWE-94 – Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today