CVE-2022-43939 is an authorization bypass vulnerability in Hitachi Vantara Pentaho Business Analytics (BA) Server. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 March 2025, which means attackers have used it in real attacks. 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 This Vulnerability Changes in Practice
This CVE is dangerous because the affected server makes authorization decisions on a non-canonical URL path, so a request can be interpreted differently by the application and the access-control logic. In practice, that means a route that appears restricted may still be reachable if the server normalises or resolves the path in a way the authorization layer does not expect.
That class of flaw matters most in products that expose administrative, reporting, or data-access functions through HTTP endpoints, because authorization checks are only as strong as the exact request target they evaluate. When the checked path and the executed path diverge, the control boundary becomes unreliable even if the application seems to be “protecting” the right resource.
How Organisations Confirm Exposure
Exposure checks should start with an accurate asset inventory, because the question is not only whether Pentaho BA Server exists anywhere, but whether the vulnerable server is deployed in a reachable and actively used path. Internet-facing instances deserve priority, followed by internally reachable deployments that may still be accessible to contractors, VPN users, or other authenticated users who should not have broad access.
Version confirmation should come from the vendor advisory for the affected release range and from the CISA KEV catalogue entry, rather than from assumptions based on product naming alone. A practical review also includes reverse proxies, WAF rules, and URL rewriting layers, because intermediary normalisation can hide or alter the paths that the application actually evaluates.
Why Authorization Bypass Is Especially Harmful Here
An authorization bypass is not just a broken permission check, it is a direct failure of trust in the application’s request-routing logic. Once an attacker can reach a protected function without the intended authorization decision, they can often enumerate sensitive endpoints, read reports or data, or pivot into higher-value administrative features.
For a business analytics server, the likely consequences include exposure of dashboards, underlying business data, metadata about users and roles, or operational controls that were expected to remain restricted. The security issue is therefore broader than simple unauthorised viewing, because analytics platforms often concentrate valuable data and serve as a bridge to adjacent systems.
What Remediation and Review Should Focus On
Remediation should begin with the vendor’s fix guidance, then move to compensating controls if patching is delayed. Where immediate patching is not possible, reduce exposure by limiting network reachability, tightening access to administrative interfaces, and monitoring for unusual requests that use path variants, encoded separators, or unexpected traversal patterns.
After remediation, review logs for suspicious requests to protected endpoints and for signs that sensitive content was accessed before the fix was applied. Because the flaw is an authorization bypass, post-patch review should also consider whether accounts, sessions, service integrations, or exported reports were accessed in ways that require follow-up containment or credential rotation.
Risk and Threat Considerations
This vulnerability is attractive to attackers because authorization bypasses often provide a quiet path into high-value application functions without needing valid privileges. In a platform that concentrates business data, even a single path-matching flaw can expose reporting, administration, or data extraction functions that should have remained out of reach.
Failure mechanism: The application and its authorization logic disagree about which URL is being requested, so a crafted non-canonical path slips past the access check.
Impact: Attackers may reach restricted features, disclose sensitive business information, and use the exposed access for follow-on abuse or lateral expansion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Authorization bypass directly concerns enforcing allowed actions on requested resources |
| SI-10 — Information Input Validation | Non-canonical path handling is an input-processing weakness that can subvert authorization | |
| Recommendation — Enforce access decisions on the canonical resource path and block ambiguous request variants. Validate and normalise request paths before authorization checks are applied. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Web application flaws like authorization bypass belong in secure application hardening and testing |
| Recommendation — Test authorization paths and path-normalisation behaviour before release and after change. | ||
| OWASP ASVS | V8 — Authorization | The issue is a broken authorization control at the application layer |
| Recommendation — Verify that authorization decisions are enforced consistently on every protected request path. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Exploited server-side application flaws are a common public-facing application attack path |
| Recommendation — Hunt for exploitation attempts against exposed web application endpoints and restrict unnecessary exposure. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a request-routing and authorization integrity problem, not just a patching item. The safest response is to verify that the fixed version is actually deployed, then confirm that proxies, rewrites, and custom routes are not preserving the same weakness in front of the application.
What to watch for: Unusual access to protected paths, repeated variant URL encodings, and requests that appear to target administrative or reporting functions without the expected privilege pattern are the strongest operational signals. If those patterns appear before remediation is complete, assume the application boundary may already have been crossed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org