CVE-2025-11165: dotCMS Velocity Engine RCE Vulnerability

CVE-2025-11165 Overview

A sandbox escape vulnerability exists in dotCMS's Velocity scripting engine (VTools) that allows authenticated users with scripting privileges to bypass class and package restrictions enforced by SecureUberspectorImpl. By dynamically modifying the Velocity engine's runtime configuration and reinitializing its Uberspect, a malicious actor can remove the introspector.restrict.classes and introspector.restrict.packages protections.

Once these restrictions are cleared, the attacker can access arbitrary Java classes, including java.lang.Runtime, and execute arbitrary system commands under the privileges of the application process (e.g., dotCMS or Tomcat user).

Critical Impact

Authenticated attackers with scripting privileges can escape the Velocity sandbox to achieve full remote code execution on the underlying server, potentially compromising the entire dotCMS deployment and any connected systems.

Affected Products

• dotCMS versions with Velocity scripting engine (VTools)
• Systems running dotCMS on Tomcat application server
• Any dotCMS deployment with user scripting privileges enabled

Discovery Timeline

• 2026-02-24 - CVE CVE-2025-11165 published to NVD
• 2026-02-24 - Last updated in NVD database

Technical Details for CVE-2025-11165

Vulnerability Analysis

This vulnerability represents a critical sandbox escape flaw within the Apache Velocity templating engine as implemented in dotCMS. The Velocity engine uses an introspection mechanism called Uberspect to control which Java classes and methods are accessible from within Velocity templates. The SecureUberspectorImpl class is designed to enforce restrictions by maintaining blacklists of prohibited classes and packages through the introspector.restrict.classes and introspector.restrict.packages configuration properties.

The fundamental weakness lies in the ability for authenticated users with scripting privileges to dynamically modify the Velocity engine's runtime configuration. By manipulating these configuration settings at runtime and reinitializing the Uberspect component, an attacker can effectively clear or bypass the security restrictions intended to prevent access to dangerous Java classes.

Root Cause

The root cause stems from insufficient access controls on the Velocity engine's runtime configuration modification capabilities. The security architecture fails to prevent authenticated users with scripting privileges from altering the introspector restriction settings. When the Uberspect is reinitialized after these modifications, it loads the new (empty or modified) restriction lists, effectively disabling the sandbox protections. This design flaw allows the sandbox escape by treating configuration changes as legitimate operations rather than security-sensitive modifications requiring elevated privileges.

Attack Vector

The attack is network-accessible and requires low-privilege authentication (scripting privileges). An attacker with valid credentials and scripting access can exploit this vulnerability through the following mechanism:

1. The attacker authenticates to the dotCMS instance and accesses the Velocity scripting functionality
2. Through the scripting interface, the attacker dynamically modifies the Velocity runtime configuration to clear or modify the introspector.restrict.classes and introspector.restrict.packages properties
3. The attacker triggers a reinitialization of the Uberspect component, which reloads with the modified (unrestricted) configuration
4. With restrictions removed, the attacker can now access previously blocked Java classes such as java.lang.Runtime
5. Using Runtime.getRuntime().exec() or similar methods, the attacker executes arbitrary system commands with the privileges of the dotCMS/Tomcat process

This attack requires no user interaction and can be performed remotely over the network. For detailed technical information, refer to the dotCMS Known Security Issue SI-74.

Detection Methods for CVE-2025-11165

Indicators of Compromise

• Unexpected modifications to Velocity engine runtime configuration, particularly introspector.restrict.classes or introspector.restrict.packages properties
• Log entries showing Uberspect reinitialization events outside normal application startup
• Evidence of java.lang.Runtime, java.lang.ProcessBuilder, or similar dangerous class invocations in Velocity templates
• Unusual process spawning from the dotCMS or Tomcat process with unexpected command-line arguments
• Template or script modifications containing references to Java reflection APIs or restricted class access

Detection Strategies

• Implement application-level logging for all Velocity configuration changes and Uberspect initialization events
• Monitor for script content containing patterns like Runtime.getRuntime(), ProcessBuilder, or introspector configuration manipulation
• Deploy file integrity monitoring on Velocity template directories and configuration files
• Use endpoint detection to identify child processes spawned by the Java/Tomcat process that deviate from normal behavior

Monitoring Recommendations

• Enable verbose logging for the dotCMS Velocity scripting engine and review logs for suspicious activity patterns
• Configure SIEM rules to alert on Velocity introspector configuration changes or unusual Uberspect reinitialization events
• Implement behavioral analysis for the dotCMS application process to detect anomalous system command execution
• Regularly audit user accounts with scripting privileges and review their template/script activities

How to Mitigate CVE-2025-11165

Immediate Actions Required

• Review and audit all user accounts with Velocity scripting privileges, restricting access to only essential personnel
• Disable or limit Velocity scripting functionality until patches can be applied
• Monitor for indicators of compromise as described above
• Consider implementing network segmentation to limit the blast radius of potential compromise
• Apply vendor patches as soon as they become available

Patch Information

Refer to the dotCMS Known Security Issue SI-74 for official patch information and updated versions that address this vulnerability. Organizations should upgrade to the latest patched version of dotCMS as soon as possible.

Workarounds

• Remove or strictly limit Velocity scripting privileges to only trusted administrators who require this functionality
• Implement additional access controls at the application or network layer to restrict access to scripting interfaces
• Deploy a Web Application Firewall (WAF) with rules to detect and block attempts to manipulate Velocity configuration
• Consider running dotCMS in a containerized environment with reduced privileges to limit the impact of potential exploitation
• Enable additional logging and monitoring as a compensating control until patches are applied

# Example: Restrict scripting user permissions (consult dotCMS documentation for exact commands)
# Review users with scripting privileges
# Disable scripting access for non-essential accounts
# Enable enhanced logging for Velocity engine activity