The management console sat in front of an enterprise financial planning and analytics engine, brokering access to budgeting, forecasting and actuals data. The important result was not one isolated flaw. It was an unauthenticated route from the web console to command execution on the analytics host.
The assessment produced three material findings: a pre-authentication access-control bypass, a chained pre-authentication remote-code-execution path, and an authenticated fail-open condition that exposed backend data and credential material despite the feature being disabled.
Prove the chain, not just the component
Testing combined request-and-response analysis with active exploitation. Each step was reproduced to a standard suitable for vendor and customer review. Benign commands, out-of-band evidence and a complete artifact inventory kept the work auditable and bounded.
Finding 1: authorization before normalization
The application’s authorization filter made its decision against the raw request URI. The application server normalized traversal segments only after that filter had run. A guest-accessible prefix could therefore be placed before a protected route: the filter saw the permitted prefix while the server ultimately dispatched the request to the protected handler.
Literal and URL-encoded forms worked, and the route accepted state-changing requests as well as reads. The resulting unauthenticated access exposed administrative configuration, unmasked secrets, users and permissions, live sessions, logs and instance topology.
Root cause: authorization was decided on untrusted, pre-normalized input.
Finding 2: reconstructing the route to execution
The platform included a legitimate migration-package feature for promoting content between environments. Its undocumented package format described objects to import and backend processes to execute.
Observed traffic was used to reconstruct the archive layout, manifest, file descriptors, dependency map and multi-stage workflow. A minimal package then invoked the analytics engine’s native command-execution function. Reached through the first finding, the entire import-and-execute path operated without authentication.
The proof distinguished command execution from a forged server-side request. Because outbound HTTP was filtered, a controlled DNS callback included a machine-local value expanded by the host. Backend execution logs independently confirmed that the supplied process was deployed and run.
The demonstrated impact was operating-system command execution on the analytics host as its service account. The behavior appeared rooted in the tested product rather than a deployment-only setting; applicability to other versions or deployments requires version-specific validation.
Finding 3: disabled did not mean stopped
A REST API proxy feature was disabled in configuration. The servlet wrote a disabled notice to the response but continued executing and forwarded the request to the live backend API. The notice was immediately followed by real backend data.
The endpoint remained correctly restricted to administrators, so the issue was assessed separately from the unauthenticated chain. For an administrator, however, the disabled tool operated as a service-account proxy into cubes, dimensions, the security model and stored data-source credential material.
Root cause: a disabled control continued processing instead of failing closed.
Techniques that made the evidence defensible
- Vulnerability chaining. An authorization bypass and a legitimate import workflow became a no-credentials host compromise when connected.
- Format reverse-engineering. The execution vehicle was rebuilt from observed behavior rather than relying on public tooling.
- Proof engineering. Host-attributable DNS evidence and backend logs separated command execution from SSRF.
- Safe exploitation. Benign commands, bounded signalling and an artifact inventory preserved the engagement boundary.
The controls that held still mattered
The environment was not uniformly weak. Direct endpoints enforced role authorization, the REST proxy was confined to the target instance, state-changing proxy calls were blocked by a server-side payload store, outbound HTTP was filtered, sessions were short-lived and protected, and standard security headers were consistently applied.
Documenting those boundaries prevented the report from overstating what had actually been demonstrated.
A remediation path across three control layers
- Make access control canonical and fail closed. Authorize the fully decoded and normalized path at one checkpoint, deny by default and stop processing disabled functionality.
- Harden and contain the analytics backend. Restrict native command execution, gate executable packages, reduce service-account privilege and retain egress controls.
- Fix upstream, rotate and monitor. Coordinate version-specific remediation, rotate exposed secrets and monitor traversal, import and proxy activity while fixes are applied.
Low-profile management surfaces can hold high-impact routes.
The assessment’s value was not the number of findings. It was the reproducible demonstration that an unauthenticated user could connect individually modest behaviors into a route to host compromise, together with an honest account of the controls that already worked.