CVE-2026-7045: Baomidou Dynamic-Datasource RCE Flaw

CVE-2026-7045 Overview

A SpEL (Spring Expression Language) injection vulnerability was discovered in baomidou dynamic-datasource version 2.5.0. This vulnerability affects the DsSpelExpressionProcessor#doDetermineDatasource function within the file dynamic-datasource-spring/src/main/java/com/baomidou/dynamic/datasource/processor/DsSpelExpressionProcessor.java. The flaw exists in the StandardEvaluationContext and SpelExpressionParser components, allowing an attacker to inject malicious SpEL expressions that could lead to remote code execution.

Critical Impact

Attackers can exploit this SpEL injection vulnerability to execute arbitrary code on the server by injecting malicious expressions through the datasource key resolution mechanism, potentially leading to complete system compromise.

Affected Products

• baomidou dynamic-datasource 2.5.0
• Applications using DsSpelExpressionProcessor with unrestricted SpEL type access
• Spring Boot applications leveraging dynamic-datasource for multi-datasource switching

Discovery Timeline

• April 26, 2026 - CVE-2026-7045 published to NVD
• April 27, 2026 - Last updated in NVD database

Technical Details for CVE-2026-7045

Vulnerability Analysis

This vulnerability is classified under CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component). The core issue lies in how the DsSpelExpressionProcessor handles SpEL expressions when resolving datasource keys. The vulnerable implementation uses StandardEvaluationContext which, by default, allows full access to Java type references and constructors within SpEL expressions.

When processing datasource key expressions, the application fails to restrict dangerous SpEL constructs such as T(java.lang.Runtime).getRuntime().exec() or similar type reference expressions. This allows authenticated attackers with the ability to influence datasource key expressions to inject arbitrary SpEL payloads that execute Java code on the server.

The vulnerability is remotely exploitable over the network and requires low privileges to execute. While the impact on confidentiality, integrity, and availability is limited in scope, successful exploitation could allow attackers to read sensitive data, modify application behavior, or cause denial of service conditions.

Root Cause

The root cause is the unrestricted use of StandardEvaluationContext combined with SpelExpressionParser in the DsSpelExpressionProcessor class. The StandardEvaluationContext provides full access to the SpEL language features, including type references (T(...) expressions) and constructor calls that can instantiate arbitrary Java classes. Without proper restrictions, user-controlled input that flows into SpEL expression evaluation becomes a code injection vector.

Attack Vector

The attack leverages the network-accessible SpEL expression processor in the dynamic-datasource component. An authenticated attacker can craft malicious SpEL expressions containing Java type references to execute arbitrary system commands. The attack requires the ability to influence datasource key expressions, which may be possible through application-specific input vectors such as request parameters, headers, or session attributes that are used in datasource routing logic.

The following patch demonstrates the security fix that introduces restricted SpEL type access:

      * aop allowedPublicOnly
      */
     private Boolean allowedPublicOnly = true;
+    /**
+     * Whether to allow SpEL type references (e.g. T(java.lang.Runtime)) and constructor
+     * expressions in datasource key expressions resolved by DsSpelExpressionProcessor.
+     * Defaults to false (restricted / safe mode) to prevent SpEL injection attacks.
+     * Set to true only if your application genuinely requires such expressions and you
+     * fully understand the security risk.
+     */
+    private Boolean allowedSpelTypeAccess = false;
 }

Source: GitHub Commit Details

Detection Methods for CVE-2026-7045

Indicators of Compromise

• Unusual SpEL expressions in application logs containing T(java.lang.Runtime) or similar type references
• Unexpected process spawning from Java application processes
• Network connections to external hosts from the application server that don't match normal behavior
• Error logs showing SpEL parsing failures with suspicious expression patterns

Detection Strategies

• Monitor application logs for SpEL expression evaluation errors or suspicious patterns in datasource key resolution
• Implement Web Application Firewall (WAF) rules to detect and block requests containing SpEL type reference syntax
• Deploy runtime application self-protection (RASP) solutions to detect SpEL injection attempts
• Review audit logs for authentication events followed by unusual datasource switching patterns

Monitoring Recommendations

• Enable verbose logging for the com.baomidou.dynamic.datasource package to capture SpEL expression processing
• Set up alerts for process creation events originating from Java application processes
• Monitor for outbound network connections from application servers to unexpected destinations
• Implement file integrity monitoring on critical system files and directories

How to Mitigate CVE-2026-7045

Immediate Actions Required

• Apply the security patch identified by commit 273fcedaee984c08197c0890f14190b86ab7e0b8 immediately
• Review application code for any usage of DsSpelExpressionProcessor with user-controlled input
• Ensure allowedSpelTypeAccess is set to false (default) in your configuration
• Audit datasource routing logic to identify potential injection points

Patch Information

The vulnerability has been addressed in the official patch available through the GitHub Pull Request. The fix introduces a new configuration property allowedSpelTypeAccess that defaults to false, restricting SpEL type references and constructor expressions in datasource key expressions.

The configuration change is applied to the DsSpelExpressionProcessor as shown:

         DsProcessor sessionProcessor = new DsSessionProcessor();
         DsSpelExpressionProcessor spelExpressionProcessor = new DsSpelExpressionProcessor();
         spelExpressionProcessor.setBeanResolver(new BeanFactoryResolver(beanFactory));
+        spelExpressionProcessor.setAllowedSpelTypeAccess(properties.getAop().getAllowedSpelTypeAccess());
         headerProcessor.setNextProcessor(sessionProcessor);
         sessionProcessor.setNextProcessor(spelExpressionProcessor);
         return headerProcessor;

Source: GitHub Commit Details

Workarounds

• If immediate patching is not possible, implement input validation to reject SpEL expressions containing type references (T(...)) or constructor calls
• Deploy a WAF rule to filter requests containing SpEL injection patterns
• Restrict network access from the application server to limit the impact of potential code execution

# Configuration example - Ensure restricted SpEL type access in application.yml
spring:
  datasource:
    dynamic:
      aop:
        allowed-spel-type-access: false