Summary
An authorization bypass in OpenNMS REST API filter chains allows unauthenticated requests using non-canonical HTTP method tokens to avoid authentication checks. An attacker who can reach the API may read monitored inventory, change or delete resources, inject events, manipulate alarms, and infer whether alarms exist.
An authorization bypass in OpenNMS REST API filter chains allows unauthenticated requests using non-canonical HTTP method tokens to avoid authentication checks. An attacker who can reach the API may read monitored inventory, change or delete resources, inject events, manipulate alarms, and infer whether alarms exist.
Affected context
The issue affects OpenNMS Meridian and Horizon deployments where REST API Spring Security filter chains use case-sensitive method rules without a terminal deny rule. It is especially risky when the REST interface is reachable by untrusted networks or when requests can reach the affected chains without an upstream access-control layer.
The issue affects OpenNMS Meridian and Horizon deployments where REST API Spring Security filter chains use case-sensitive method rules without a terminal deny rule. It is especially risky when the REST interface is reachable by untrusted networks or when requests can reach the affected chains without an upstream access-control layer.
Exploit preconditions
- Attack surface: OpenNMS REST API endpoints under
/rest/** - Required access: Network access to the REST API; valid credentials are not necessarily required
- Trigger point: A request using a non-canonical HTTP method token, such as a lowercase method name
- Why exploitation is possible: The method does not match the case-sensitive authorization rules, and the filter chain permits processing because it lacks a final deny rule
- Attack surface: OpenNMS REST API endpoints under
/rest/** - Required access: Network access to the REST API; valid credentials are not necessarily required
- Trigger point: A request using a non-canonical HTTP method token, such as a lowercase method name
- Why exploitation is possible: The method does not match the case-sensitive authorization rules, and the filter chain permits processing because it lacks a final deny rule
Why this happens
The vulnerability results from incomplete authorization logic in Spring Security filter chains. Rules that authorize only uppercase HTTP method tokens are evaluated case-sensitively, while unmatched requests are not explicitly denied. This fail-open behavior maps primarily to CWE-862: Missing Authorization and may also involve CWE-863: Incorrect Authorization, because access-control decisions do not reliably constrain requests to the intended methods. Differences in alarm responses can additionally expose information relevant to CWE-204: Observable Response Discrepancy.
The vulnerability results from incomplete authorization logic in Spring Security filter chains. Rules that authorize only uppercase HTTP method tokens are evaluated case-sensitively, while unmatched requests are not explicitly denied. This fail-open behavior maps primarily to CWE-862: Missing Authorization and may also involve CWE-863: Incorrect Authorization, because access-control decisions do not reliably constrain requests to the intended methods. Differences in alarm responses can additionally expose information relevant to CWE-204: Observable Response Discrepancy.
Potential impact
- An unauthenticated attacker could read monitored inventory
- An attacker could create, modify, or delete REST-managed resources
- Attackers could inject events to fabricate, suppress, or alter alarms
- Alarm existence could be disclosed through response differences
- Monitoring integrity and operational decision-making could be undermined
- A compromised monitoring platform could facilitate further attacks against connected systems
- An unauthenticated attacker could read monitored inventory
- An attacker could create, modify, or delete REST-managed resources
- Attackers could inject events to fabricate, suppress, or alter alarms
- Alarm existence could be disclosed through response differences
- Monitoring integrity and operational decision-making could be undermined
- A compromised monitoring platform could facilitate further attacks against connected systems
General mitigation guidance
Mitigation focuses on making authorization fail closed and reducing exposure of administrative REST interfaces.
Common defensive patterns include:
- Add an explicit terminal deny rule to every REST security filter chain
- Normalize and validate HTTP method handling before authorization decisions
- Treat unmatched, malformed, or non-canonical methods as unauthorized
- Require authentication and least-privilege authorization for every REST operation
- Place management APIs behind private network boundaries or authenticated gateways
- Avoid relying solely on network location as an authorization control
- Review response behavior so resource-existence differences are not unnecessarily exposed
Mitigation focuses on making authorization fail closed and reducing exposure of administrative REST interfaces.
Common defensive patterns include:
- Add an explicit terminal deny rule to every REST security filter chain
- Normalize and validate HTTP method handling before authorization decisions
- Treat unmatched, malformed, or non-canonical methods as unauthorized
- Require authentication and least-privilege authorization for every REST operation
- Place management APIs behind private network boundaries or authenticated gateways
- Avoid relying solely on network location as an authorization control
- Review response behavior so resource-existence differences are not unnecessarily exposed
How teams detect issues like this
Organizations can identify similar weaknesses through:
- Static analysis and configuration review for authorization chains without catch-all deny rules
- Code review checks for case-sensitive method comparisons and fail-open security defaults
- Tests that exercise lowercase, mixed-case, malformed, and unsupported HTTP method tokens
- Integration tests verifying that every REST endpoint requires the intended authentication and permission
- API gateway and web-application-firewall policies that reject non-canonical methods
- Monitoring for unauthenticated REST requests, unexpected method casing, and changes to inventory or alarm state
Organizations can identify similar weaknesses through:
- Static analysis and configuration review for authorization chains without catch-all deny rules
- Code review checks for case-sensitive method comparisons and fail-open security defaults
- Tests that exercise lowercase, mixed-case, malformed, and unsupported HTTP method tokens
- Integration tests verifying that every REST endpoint requires the intended authentication and permission
- API gateway and web-application-firewall policies that reject non-canonical methods
- Monitoring for unauthenticated REST requests, unexpected method casing, and changes to inventory or alarm state
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
