CVE-2026-80515 in Arrowhead
Summary
by MITRE • 09/03/2026
In Eclipse Arrowhead versions from 5.0.0 to 5.2.1 the management-authorization gate that protects every /…/mgmt/… REST endpoint decides whether to apply its check by calling request.getRequestURL().toString().contains("/mgmt/"). Tomcat returns getRequestURL() un-decoded, while Spring MVC's DispatcherServlet routes on the decoded path. Requesting /serviceregistry/%6Dgmt/systems (%6D == m) therefore fails the substring check — the filter falls through without authorising — yet is decoded to /serviceregistry/mgmt/systems and dispatched to the management controller. Spring Security's StrictHttpFirewall (active via spring-boot-starter-security in arrowhead-common) only rejects encoded / \ . % ; and null bytes, so percent-encoded ASCII letters pass through. Any authenticated system — regardless of privilege — can reach every management operation, including POST /authentication/mgmt/identities which creates new sysop accounts, yielding full administrative takeover of the local cloud.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability in Eclipse Arrowhead versions 5.0.0 through 5.2.1 represents a critical authorization bypass rooted in a fundamental mismatch between how the web server and the application framework process URL paths. The management-authorization gate, which is designed to protect all REST endpoints under the /mgmt/ path hierarchy, relies on checking if the request URL contains the string "/mgmt/" using the Java Servlet API method getRequestURL().toString(). This approach assumes that the raw URL returned by the servlet container matches the logical path used for routing decisions within the application. However, Apache Tomcat returns the getRequestURL() value in its original, un-decoded form as received from the client. In contrast, Spring MVC's DispatcherServlet performs route matching based on the decoded URI path. This discrepancy creates a logic flaw where an attacker can manipulate the URL encoding to evade security checks while still reaching the intended protected endpoints.
Specifically, by utilizing percent-encoding for characters within the target path segment, such as replacing the letter 'm' with its hexadecimal representation %6D in /serviceregistry/%6Dgmt/systems, the request bypasses the substring check performed by the authorization filter. The filter sees "%6Dgmt" and determines that "/mgmt/" is not present, thus allowing the request to proceed without applying any authentication or authorization checks. Meanwhile, Spring MVC decodes %6D back into 'm' during the routing phase, correctly identifying the path as /serviceregistry/mgmt/systems and dispatching it to the appropriate management controller. This mechanism effectively renders the security filter inert for requests employing specific encoding techniques that alter the byte representation of critical path segments without changing their semantic meaning in a decoded context.
The exploitation potential is significantly amplified by the configuration of Spring Security's StrictHttpFirewall, which is active via spring-boot-starter-security in arrowhead-common. This firewall is configured to reject only dangerous characters such as encoded slashes, backslashes, dots, semicolons, and null bytes. It does not block percent-encoded ASCII letters like %6D for 'm'. Consequently, the application accepts these encoded requests as valid HTTP traffic rather than rejecting them outright due to malformed syntax. This permissive validation allows authenticated systems, regardless of their assigned privilege levels or roles, to access every management operation exposed by the framework. The lack of strict input sanitization at the firewall level ensures that the encoding trick is not intercepted before it reaches the authorization logic layer where the flaw resides.
The operational impact of this vulnerability is severe, leading to a complete compromise of administrative controls within the local cloud environment. An authenticated attacker can exploit this bypass to execute any management operation available in the system. Most critically, this includes access to POST /authentication/mgmt/identities, an endpoint that allows for the creation of new user identities with elevated privileges. By leveraging this capability, an adversary can create a new superuser account (sysop) and subsequently take full administrative control over the Eclipse Arrowhead instance. This results in unauthorized modification of system configurations, potential data exfiltration, and complete loss of integrity and availability for services managed by the platform.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves failing to enforce proper restrictions on authenticated users regarding access to specific resources or functions. It also maps closely to CWE-697 Incorrect Comparison During Authorization Check, highlighting the failure in comparing request attributes against security policies due to encoding discrepancies. In terms of attack vectors and tactics, this behavior is consistent with ATT&CK technique T1059 Command and Scripting Interpreter if used for further exploitation, but more directly relates to privilege escalation via improper access control mechanisms. The specific method of bypassing filters through URL manipulation can be categorized under evasion techniques that exploit differences in parsing logic between components.
To mitigate this vulnerability, developers must ensure consistency between the security filter's path checking mechanism and the application framework's routing logic. One effective solution is to utilize getRequestURI() instead of getRequestURL(), or to explicitly decode the URI before performing substring checks within the authorization gate. Alternatively, configuring Spring Security's StrictHttpFirewall to reject percent-encoded characters that could alter path semantics would prevent such bypasses at an earlier stage in the request processing pipeline. Upgrading to a patched version of Eclipse Arrowhead where this logic has been corrected is essential for restoring proper access control boundaries and preventing unauthorized administrative actions within the cloud infrastructure.