CVE-2021-31602

What it actually does

CVE-2021-31602 is an unauthenticated information disclosure issue in Hitachi Vantara Pentaho through 9.1 and Pentaho Business Intelligence Server through 7.x. Pentaho’s security model includes application-context access controls defined in applicationContext-spring-security.xml; the default configuration exposes certain application endpoints or resources without requiring authentication. A remote network attacker can query the affected service and extract sensitive configuration or platform information without valid credentials. The primary impact is confidentiality loss; the CVSS vector indicates no direct integrity or availability impact, but disclosed information may support follow-on attacks such as credential targeting, endpoint discovery, or exploitation of other exposed Pentaho functions.

Why it matters to the business

Organizations running affected Pentaho deployments may unintentionally expose internal business intelligence platform details to unauthenticated internet or network users. Because Pentaho often connects to data warehouses, reporting systems, ETL jobs, and sensitive analytics workflows, leaked configuration or platform information can help attackers map the environment and plan deeper compromise. The vulnerability is rated high severity, has a high EPSS likelihood score, and is described as weaponized, so exposed instances should be treated as materially risky even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies an exposed Pentaho or Pentaho Business Intelligence Server instance, typically through internet scanning, asset discovery, or fingerprinting of web application responses. The attacker then sends unauthenticated HTTP requests to application paths governed by the default applicationContext Spring Security configuration. Because the vulnerable default access-control layer does not require credentials for certain resources, the server returns information that should not be available to anonymous users. The attacker reviews the disclosed data for version details, configuration clues, service paths, plugin information, integration details, or other reconnaissance value. That information may then be used to refine attacks against the same Pentaho deployment, identify known vulnerable versions, craft password-spraying or phishing themes, or target connected analytics and data-processing infrastructure.

How to fix it

Upgrade affected Pentaho deployments to a vendor-supported release that contains the corrected security configuration. The provided advisory data does not include exact fixed versions, so administrators should consult Hitachi Vantara security advisories and release notes for the applicable Pentaho and Pentaho Business Intelligence Server branch. As a mitigation, review and harden applicationContext-spring-security.xml and related Spring Security configuration to ensure sensitive endpoints require authentication and appropriate authorization. Restrict network access to Pentaho administrative and BI interfaces using VPN, private network placement, reverse-proxy authentication, allowlists, or zero-trust access controls. Remove public internet exposure where not strictly required, disable unused plugins or endpoints, and ensure secrets, data-source credentials, and connection strings are not exposed in application responses or downloadable configuration artifacts.

How to confirm the fix worked

Confirm the deployed Pentaho version is newer than the affected ranges: Pentaho through 9.1 and Pentaho Business Intelligence Server through 7.x are affected. Review vendor release notes to verify the installed version includes the fix for this issue. From an unauthenticated client, test known Pentaho web paths and any historically exposed endpoints to ensure sensitive application, configuration, version, plugin, or platform information is no longer returned without login. Review applicationContext-spring-security.xml and related security mappings to confirm anonymous access is not granted to sensitive resources. Validate that external scanners and asset inventories no longer identify the instance as an affected Pentaho version and that the service is not reachable from untrusted networks unless intentionally exposed behind compensating controls.

Typical attack path

1. Discover an exposed Hitachi Vantara Pentaho or Pentaho Business Intelligence Server web interface.
2. Fingerprint the application and version using HTTP response headers, page content, redirects, or known Pentaho paths.
3. Send unauthenticated requests to endpoints or resources affected by the default applicationContext Spring Security configuration.
4. Collect information returned without authentication, such as platform, configuration, path, version, or component details where exposed.
5. Use the disclosed information to support additional reconnaissance, credential attacks, or exploitation of other Pentaho weaknesses.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs, reverse-proxy logs, WAF logs, application server logs, and Pentaho application logs for unauthenticated requests to Pentaho-specific endpoints followed by successful information-bearing responses. Focus on requests from external or unusual IP addresses, high-volume enumeration of application paths, repeated 200 responses before any authenticated session is established, and requests for configuration, plugin, API, or system paths. Correlate suspicious reconnaissance with later authentication attempts, password spraying, administrative page access, plugin uploads, data-source changes, scheduled job changes, or unusual report/export activity. Because this issue is primarily information disclosure, there may be no server-side error or file artifact; evidence is most likely in web request logs and downstream activity that used the disclosed information. If logs include session identifiers or usernames, distinguish anonymous requests from authenticated user activity and investigate anonymous access that returned HTTP 200 or 302 responses to sensitive Pentaho paths.

• /pentaho/
• /pentaho/Login
• /pentaho/Home
• /pentaho/api/
• /pentaho/plugin/
• /pentaho/content/
• /pentaho/Xmla
• /pentaho/api/system
• /pentaho/api/repos
• /pentaho/api/userrolelist
• /pentaho/api/session
• applicationContext-spring-security.xml
• User-Agent: curl
• User-Agent: python-requests
• User-Agent: wget
• GET /pentaho/
• GET /pentaho/api/
• GET /pentaho/plugin/
• GET /pentaho/content/
• GET /pentaho/Xmla
• HTTP 200

What your security team should do

• Immediately inventory all Hitachi Vantara Pentaho and Pentaho Business Intelligence Server deployments, including internal, partner-facing, and internet-facing instances.
• Prioritize remediation for any internet-accessible or unauthenticated network-accessible Pentaho instances because exploitation is weaponized and EPSS likelihood is high.
• Upgrade to a supported fixed vendor release; if exact fixed-version mapping is unclear, open a vendor support case or use the latest supported Pentaho release available for the deployment branch.
• Restrict access to Pentaho web interfaces with network controls and strong upstream authentication, especially for administrative, API, plugin, and configuration-related paths.
• Review Spring Security configuration, particularly applicationContext-spring-security.xml, for permissive anonymous access rules.
• Rotate exposed or potentially exposed credentials if logs or testing indicate configuration data, data-source information, or connection details may have been disclosed.
• Search historical web access logs for unauthenticated requests to Pentaho-specific paths and unusual enumeration activity.
• Monitor for follow-on activity such as login attempts, password spraying, plugin probing, suspicious API calls, or access to data-source administration functions after reconnaissance requests.