CVE-2022-43769

What it actually does

CVE-2022-43769 is a remote code execution vulnerability in Hitachi Vantara Pentaho Business Analytics Server. Authenticated users with high privileges can use certain web services to write property values containing Spring template or expression language content. Those values are later interpreted by server-side components instead of being treated as inert data, allowing attacker-controlled expressions to execute in the context of the Pentaho application server. Successful exploitation can provide full confidentiality, integrity, and availability impact, including command execution under the operating-system account running the Pentaho/Tomcat service.

Why it matters to the business

A successful attack can let an intruder take control of a Pentaho Business Analytics Server, steal analytics data and credentials, alter reports or jobs, disrupt BI operations, and use the server as a foothold into connected databases and internal systems. The risk is elevated because exploitation is listed in CISA KEV, active in the wild, and has a very high EPSS score of 0.9767, indicating broad attacker interest. Organizations subject to CISA KEV timelines were expected to remediate by 2025-03-24.

How an attack unfolds

An attacker first obtains valid high-privilege access to the Pentaho Business Analytics Server, such as an administrative or otherwise privileged account capable of invoking the vulnerable web services. The attacker then submits a crafted property value containing Spring template or expression language syntax rather than ordinary configuration data. The vulnerable server stores or accepts the value without sufficient validation or escaping. When another Pentaho component later processes that property, the embedded template expression is evaluated server-side. The expression can invoke Java classes such as Runtime or ProcessBuilder to execute operating-system commands as the Pentaho application service account. From there, an attacker may download tooling, establish persistence, read or modify BI content, access configured data sources, pivot to connected systems, or disrupt the analytics platform.

How to fix it

Upgrade Hitachi Vantara Pentaho Business Analytics Server to a fixed release: 9.4.0.1 or later for the 9.4 branch, or 9.3.0.2 or later for the 9.3 branch. Systems on 8.3.x or other unsupported/vulnerable branches should be upgraded to a supported fixed branch rather than left in place. If immediate patching is not possible, restrict network access to the Pentaho application, limit access to administrative and web service endpoints, enforce strong authentication and MFA for privileged users, remove unnecessary privileged accounts, review role assignments, and monitor for Spring expression payloads in submitted properties. Treat mitigation as temporary; the durable fix is applying the vendor update.

How to confirm the fix worked

Confirm the deployed Pentaho Business Analytics Server version is 9.4.0.1 or later, or 9.3.0.2 or later, and verify that no vulnerable 8.3.x or earlier instances remain. Check both application UI version information and filesystem/package metadata because stale web applications or parallel deployments can remain after upgrades. Validate that exposed web service/API endpoints require authentication and are not reachable from untrusted networks. Review recent configuration/property changes for embedded Spring expression syntax such as #{...}, T(java.lang.Runtime), or ProcessBuilder. After upgrade, perform a controlled negative test in a non-production environment to ensure submitted template expressions are stored or rejected as data and are not evaluated by downstream processing.

Typical attack path

1. Identify an exposed Hitachi Vantara Pentaho Business Analytics Server instance.
2. Obtain or reuse credentials for a high-privilege Pentaho account.
3. Authenticate to the Pentaho web interface or API/web service endpoints.
4. Submit a crafted property value containing Spring template or expression language payloads.
5. Trigger or wait for downstream processing that evaluates the malicious property.
6. Execute commands under the Pentaho/Tomcat service account.
7. Perform post-exploitation actions such as data theft, credential harvesting, web shell deployment, lateral movement, or service disruption.

How to detect it

Investigate Pentaho application logs, Tomcat/catalina logs, web server or reverse proxy access logs, authentication/audit logs, EDR telemetry, and operating-system process creation logs. Look for privileged users invoking API or web service endpoints followed by property updates containing Spring expression syntax, especially values with #{...}, ${...}, T(java.lang.Runtime), getRuntime().exec, or java.lang.ProcessBuilder. Correlate suspicious requests with Java/Tomcat spawning operating-system shells or utilities such as sh, bash, cmd.exe, powershell.exe, curl, wget, certutil, nc, or python. Review Pentaho repository/configuration changes made shortly before suspicious process execution. Also hunt for application errors indicating Spring expression parsing or evaluation failures, as failed exploitation attempts may leave SpEL-related exceptions in logs. Because this vulnerability requires high privileges, pay special attention to anomalous administrative logins, new privileged users, unusual source IPs, impossible travel, and service account activity around the time of suspicious property changes.

• #{T(java.lang.Runtime).getRuntime().exec(
• #{T(java.lang.ProcessBuilder)
• T(java.lang.Runtime).getRuntime().exec
• java.lang.ProcessBuilder
• getRuntime().exec(
• org.springframework.expression
• SpelEvaluationException
• EL1004E
• EL1011E
• %23%7BT%28java.lang.Runtime%29
• %23%7BT%28java.lang.ProcessBuilder%29
• .getRuntime%28%29.exec%28
• /pentaho/api/
• /pentaho/webservices/
• catalina.out
• pentaho.log

What your security team should do

• Prioritize patching immediately because the vulnerability is in CISA KEV, has active in-the-wild exploitation, and has a very high EPSS score.
• Inventory all Pentaho Business Analytics Server deployments, including legacy 8.3.x systems, test systems, and internet-facing instances.
• Upgrade to 9.4.0.1 or later, or 9.3.0.2 or later, and retire unsupported vulnerable branches.
• Restrict Pentaho administrative and web service access to trusted networks and require MFA for privileged accounts.
• Audit Pentaho privileged users, remove stale accounts, rotate credentials for administrative users, and review connected data source credentials if exploitation is suspected.
• Search application, access, Tomcat, reverse proxy, EDR, and OS process logs for Spring expression payloads and suspicious child processes spawned by the Java/Tomcat service.
• If indicators of exploitation are found, isolate the server, preserve logs and disk artifacts, rotate secrets used by Pentaho, and investigate connected databases and downstream systems for follow-on access.