CVE-2022-43939

What it actually does

Hitachi Vantara Pentaho Business Analytics Server performs access-control checks against URL forms that may differ from the canonical path ultimately handled by the application. By sending specially crafted non-canonical URLs, an unauthenticated remote attacker can bypass intended security restrictions and reach resources or functions that should require authentication or authorization. Because the product is a business analytics platform that can expose reports, data sources, repository content, schedules, and administrative interfaces, successful exploitation can result in unauthorized data access, data manipulation, service disruption, and potentially further compromise depending on the exposed endpoint and server configuration.

Why it matters to the business

An exposed vulnerable Pentaho Business Analytics Server can allow outsiders to access or alter analytics content and potentially disrupt reporting services without logging in. This creates risk of sensitive business data exposure, tampered reports or dashboards, interrupted analytics operations, and follow-on compromise of connected systems or credentials stored by the platform. The vulnerability is in CISA KEV, has active exploitation in the wild, and has a very high EPSS score, so internet-facing deployments should be treated as urgent even though the KEV remediation deadline of 2025-03-24 has passed.

How an attack unfolds

An attacker first identifies a reachable Pentaho Business Analytics Server, commonly by probing for the /pentaho application context and related API or plugin paths. They then send requests using non-canonical URL forms, such as encoded path traversal, path parameters, double encoding, duplicate slashes, or other malformed path variants, that cause the security layer and the application router to interpret the request differently. If vulnerable, the security filter allows the request while the backend resolves it to a protected resource. The attacker can then enumerate accessible reports, repository objects, APIs, plugins, schedules, or administrative functions. Depending on what functions are exposed, the attacker may download sensitive analytics data, modify content, create persistence through scheduled jobs or repository artifacts, abuse stored data-source credentials, or degrade service availability. Public exploitation is known, so attempts may be automated and may be mixed with broader scanning and post-exploitation activity.

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, and 9.3.0.2 or later for the 9.3 branch. Versions before those releases, including 8.3.x, should be considered vulnerable and should be upgraded or retired. If immediate upgrade is not possible, restrict network access to the Pentaho application, place it behind authenticated access controls, block direct internet exposure, enforce allowlisted reverse-proxy paths, normalize and reject suspicious encoded or malformed URLs at the proxy/WAF layer, and closely monitor for bypass attempts. Mitigations should be treated as temporary because the flaw is actively exploited and access-control fixes belong in the application itself.

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, depending on the branch in use. Verify no vulnerable 8.3.x or pre-fixed 9.x servers remain exposed. Review package manifests, application banners, administrative version pages, deployment artifacts, and change records to ensure all nodes in a cluster or load-balanced pool were upgraded. From an unauthenticated test session, verify that protected /pentaho resources and APIs redirect to login or return an authorization failure when requested through normal and malformed path variants, including encoded traversal, semicolon path parameters, duplicate slashes, and double-encoded characters. Confirm reverse proxies, WAFs, and load balancers preserve safe normalization behavior and do not forward ambiguous paths that the application could interpret differently.

Typical attack path

1. Scan for internet-facing Hitachi Vantara Pentaho Business Analytics Server instances, commonly under the /pentaho web context.
2. Fingerprint the server version or behavior using unauthenticated requests to known Pentaho paths.
3. Send crafted non-canonical URL requests containing encoded traversal, path parameters, double-encoded characters, duplicate separators, or similar path-normalization tricks.
4. Confirm authorization bypass by receiving successful responses from resources that normally require login or elevated privileges.
5. Enumerate accessible API, plugin, repository, report, scheduler, or administrative endpoints.
6. Exfiltrate analytics content, reports, configuration data, or data-source information where accessible.
7. Attempt follow-on actions such as modifying repository content, abusing scheduled jobs, using exposed credentials, or disrupting the analytics service.

How to detect it

Review historical web, reverse-proxy, WAF, load-balancer, Tomcat, and Pentaho application logs for requests to /pentaho containing non-canonical path patterns such as encoded dot-dot traversal, semicolon path parameters, duplicate slashes, encoded slashes, encoded backslashes, or double-encoded characters. Focus on unauthenticated requests that returned HTTP 200, 201, 204, 302 to unexpected internal resources, or large response sizes from protected API, plugin, repository, report, scheduler, or administrative paths. Correlate suspicious requests with absent or new session cookies, unusual user agents, scanner-like request bursts, source IPs not normally associated with users, and subsequent authenticated-looking activity from the same source. In Pentaho logs, look for unexpected access to repository objects, report execution, scheduler changes, user or role changes, plugin access, or data-source interactions without a corresponding legitimate login event. If exploitation is suspected, examine repository content, plugin directories, scheduled jobs, audit records, and data-source configuration for unauthorized additions or modifications, and check for downstream database access using credentials managed by Pentaho during the same time window.

• GET /pentaho/..;/
• POST /pentaho/..;/
• GET /pentaho/%2e%2e
• POST /pentaho/%2e%2e
• GET /pentaho/%2e%2e%2f
• POST /pentaho/%2e%2e%2f
• GET /pentaho/..%2f
• POST /pentaho/..%2f
• GET /pentaho/%252e%252e
• POST /pentaho/%252e%252e
• GET /pentaho/%2f
• POST /pentaho/%2f
• GET /pentaho/%5c
• POST /pentaho/%5c
• GET /pentaho//
• POST /pentaho//
• /pentaho/..;/api/
• /pentaho/..;/plugin/
• /pentaho/..;/content/
• /pentaho/..;/kettle/
• /pentaho/..;/api/repos/
• /pentaho/..;/api/scheduler/
• /pentaho/..;/api/userrolelist/
• /pentaho/%2e%2e/api/
• /pentaho/%252e%252e/api/

What your security team should do

• Immediately inventory all Pentaho Business Analytics Server deployments, prioritizing internet-facing and partner-accessible systems.
• Upgrade affected servers to 9.4.0.1 or later, or 9.3.0.2 or later, and retire unsupported 8.3.x deployments where upgrade is not feasible.
• Because this vulnerability is in CISA KEV and actively exploited, treat unpatched exposed instances as potentially compromised and perform retrospective log review.
• Temporarily restrict access to Pentaho to trusted networks, VPNs, or authenticated reverse proxies until patching is complete.
• Add WAF or reverse-proxy rules to reject non-canonical /pentaho requests containing encoded traversal, semicolon path parameters, double encoding, backslashes, or excessive slash normalization patterns.
• Review Pentaho repository content, scheduled jobs, user accounts, roles, data-source definitions, and plugin directories for unauthorized changes.
• Rotate credentials stored in or used by Pentaho if exploitation is suspected, especially database, LDAP, service, and integration credentials.
• Monitor access logs for unauthenticated successful responses to protected /pentaho/api, /pentaho/plugin, repository, scheduler, and administrative paths.
• Preserve logs before remediation where compromise is suspected, including web access logs, application logs, Tomcat logs, reverse-proxy logs, WAF events, and authentication logs.