Is CVE-2022-43939 (Hitachi Vantara Pentaho BA Server Authorization Bypass) being exploited in the wild?

Yes. CISA added CVE-2022-43939 to its Known Exploited Vulnerabilities catalogue on 3 March 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Hitachi Vantara Pentaho BA Server contains a use of non-canonical URL paths for authorization decisions vulnerability that enables an attacker to bypass authorization.

What “exploited in the wild” means for this CVE

For this question, the practical answer is binary: CISA has added CVE-2022-43939 to KEV, which is strong evidence that exploitation is no longer hypothetical. That matters because KEV is not a broad risk score, it is an active exploitation signal that should move the issue from routine backlog handling into urgent exposure review and remediation planning.

Because the flaw is an authorization bypass in Pentaho BA Server, the first question is not only whether the product is installed, but whether it is reachable by untrusted users or exposed through internal trust boundaries that attackers can reach after initial access. A bypass condition often becomes most dangerous where the application is used as a gateway to data, reporting functions, or administrative actions.

When a vulnerability is already in KEV, the operational question changes from “Is this interesting?” to “Where can an attacker still reach it, and what could they do next?” That is especially true for authorization flaws, where a successful exploit can expose business data or privileged application functions without needing valid permissions.

How to confirm exposure and reduce the attack surface

The fastest way to triage this issue is to confirm whether any Pentaho BA Server deployment is present, whether it is internet-facing, and whether it is reachable from user segments that should not have direct access. If the affected application is part of a larger analytics or reporting stack, verify every exposed entry point, reverse proxy, and legacy path that could still route requests to it.

Use the vendor advisory and the CISA KEV catalogue for version and fix guidance rather than relying on secondary summaries. For a KEV-listed issue, patching or vendor-directed mitigation should be treated as a time-bound action, not a discretionary hardening task, because known exploitation changes the response standard.

If immediate remediation is not possible, reduce exposure first. That usually means restricting access to trusted networks, tightening authentication boundaries around the server, and monitoring for any request patterns that suggest unauthorized access to protected report content or administrative functionality. For this class of flaw, limiting reachability often buys more risk reduction than passive alerting alone.

What to check for signs of prior compromise

Once a CVE reaches KEV status, organizations should assume the product may already have been probed. Review logs for unusual paths, repeated authorization failures, unexpected successful access to protected resources, new accounts or role changes, and any anomalous report exports or configuration changes that do not match normal administrative activity.

If Pentaho BA Server was exposed during the exploitation window, investigate whether the attacker could have accessed reports, datasets, tokens, integration credentials, or adjacent systems reachable from the server. The blast radius is not limited to the application itself when it is connected to internal data sources or service accounts.

Where logs are thin or retention is short, treat the absence of evidence cautiously. In that situation, prioritize containment, credential review, and targeted hunting over assuming the environment is clean simply because no clear alert fired.

Risk and Threat Considerations

An authorization bypass can be materially worse than a simple crash or denial of service because it undermines the trust model of the application itself. If attackers can skip authorization checks, they may reach data or functions that defenders assumed were protected, especially in reporting platforms that aggregate sensitive internal information.

Failure mechanism: The application makes access decisions using non-canonical URL paths, so a crafted request can be evaluated differently by the server than by the security controls surrounding it. That mismatch can let an attacker reach protected resources without the intended permission check.

Impact: Successful exploitation can expose confidential reports, enable unauthorized action inside the platform, and create a pivot point into connected internal data sources or administrative workflows. In a KEV-listed flaw, that impact is no longer theoretical, it is an active defensive priority.

Practitioner Guidance

What to prioritise: Confirm every live Pentaho BA Server instance, then rank them by exposure, business criticality, and whether they can reach sensitive data or backend systems. Internet-facing or broadly reachable deployments should move first.

Decision rule: If you cannot patch immediately, treat the server as exposed rather than safe and apply compensating controls that reduce reachability and observe use of protected paths. If you find suspicious access patterns or unexplained privileged activity, escalate to compromise assessment rather than waiting for a full remediation cycle.

What to verify: Verify the installed version against the vendor advisory, confirm whether the KEV-listed condition is present in your exact deployment, and retain evidence of remediation, access restriction, and log review in case you need to prove response timing later.

Practitioner takeaway: A KEV-listed authorization bypass should be handled as an exposure-and-hunt problem, not just a patch ticket, because the real question is what access may already have been abused before remediation completed.