CVE-2026-18918: Eclipse Lyo OAuth Authorization Bypass

CVE-2026-18918 Overview

CVE-2026-18918 is an authorization bypass in Eclipse Lyo versions 2.0.0 through 7.0.0. The flaw allows attackers to bypass OAuth server authorization checks when the server supports 2-legged authentication. Applications that build their authorization filters on the Lyo-provided AbstractAdapterCredentialsFilter class inherit the weakness.

An attacker can register a provisional trusted client through a legitimate flow. The provisional client is then accepted immediately as a fully trusted client without requiring administrator approval. The 3-legged OAuth flow, which requires user interaction, correctly rejects provisional clients and is not affected. The issue is tracked as CWE-863: Incorrect Authorization.

Critical Impact

Remote, unauthenticated attackers can act as trusted OAuth clients against Eclipse Lyo adapters, exposing high-value application data and integration endpoints.

Affected Products

• Eclipse Lyo 2.0.0 through 6.0.0 (fixed in 6.0.1.Final)
• Eclipse Lyo 7.0.0 pre-release (fixed in 7.0.0.Beta3)
• Applications extending AbstractAdapterCredentialsFilter with 2-legged OAuth enabled

Discovery Timeline

• 2026-08-28 - CVE-2026-18918 published to NVD
• 2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-18918

Vulnerability Analysis

Eclipse Lyo implements Open Services for Lifecycle Collaboration (OSLC) adapters and provides OAuth 1.0a server components for authenticating client applications. The AbstractAdapterCredentialsFilter class centralizes authorization checks that many downstream adapters depend on to gate access to protected resources.

When 2-legged OAuth is enabled, the filter fails to enforce the provisional state of a newly registered client. Provisional clients are intended to require explicit administrator approval before they can perform trusted operations. The filter treats them as approved as soon as they authenticate through the 2-legged path, granting access to resources that should remain protected.

Because OSLC adapters commonly proxy application lifecycle data such as requirements, defects, and change requests, a bypass at the authorization layer exposes confidentiality and integrity of that data across integrated tools.

Root Cause

The root cause is missing state validation in the 2-legged authorization path. The filter checks that a client key and signature are valid, but does not verify that the associated client record has been cleared out of provisional status. This is a classic CWE-863 Incorrect Authorization pattern, where an authentication check is treated as sufficient for authorization.

Attack Vector

An attacker with network access to a vulnerable Lyo adapter registers a new client through the provisional client endpoint, which is a supported use case. The attacker then immediately issues 2-legged OAuth requests using the newly issued credentials. The filter accepts the requests as if the administrator had approved the client, granting access to protected OSLC resources.

No user interaction is required. The 3-legged flow, which requires a resource owner to approve the client through a browser, correctly rejects provisional clients and is not exploitable.

No public exploit code is currently indexed. See the Eclipse CVE Assignment #221 entry and the release notes for the Lyo v6.0.1.Final release and Lyo v7.0.0.Beta3 release for the technical fix details.

Detection Methods for CVE-2026-18918

Indicators of Compromise

• New OAuth consumer registrations followed within seconds by successful 2-legged token requests from the same client key.
• Successful OSLC API access from client identifiers that were never approved through the administrator console.
• Repeated provisional client creation from a single source IP or user agent.
• OAuth activity outside normal integration windows or from IP ranges not associated with known partner systems.

Detection Strategies

• Correlate application logs from AbstractAdapterCredentialsFilter with the administrator approval audit trail. Any client that authenticates before being approved is a candidate for compromise.
• Add web server rules that flag POST requests to the provisional client registration endpoint followed by 2-legged OAuth traffic from the same key within a short window.
• Review Java application stack traces and access logs for OSLC resource access tied to unknown or unexpected consumer keys.

Monitoring Recommendations

• Enable verbose logging on Lyo OAuth endpoints and forward logs to a centralized SIEM for correlation.
• Track the count of provisional clients over time and alert on abnormal creation rates.
• Monitor privileged OSLC operations, such as data export or bulk queries, and require review when initiated by recently created client keys.

How to Mitigate CVE-2026-18918

Immediate Actions Required

• Upgrade Eclipse Lyo to 6.0.1.Final or 7.0.0.Beta3 or later.
• Audit the OAuth consumer store and remove any provisional clients that were not explicitly approved by an administrator.
• Rotate credentials for any client that was created during the exposure window and revalidate its trust status.
• Review OSLC resource access logs for suspicious activity performed by newly created clients.

Patch Information

The Eclipse Lyo project addressed the flaw in the v6.0.1.Final release and the v7.0.0.Beta3 release. The fix enforces the provisional state check in the 2-legged OAuth path so that provisional clients cannot be used until an administrator clears their status. See the Eclipse CVE Assignment #221 record for the official coordination notes.

Workarounds

• Disable 2-legged OAuth on affected Lyo adapters if the deployment can operate on the 3-legged flow, which is not vulnerable.
• Override AbstractAdapterCredentialsFilter in downstream applications to explicitly reject clients whose provisional flag is still set.
• Restrict network access to Lyo OAuth endpoints so that only known integration hosts can reach the provisional client registration and token endpoints.
• Require manual administrator approval as an out-of-band step before any new client is permitted to call production APIs.

# Verify installed Eclipse Lyo version in a Maven project
mvn dependency:tree | grep -i "org.eclipse.lyo"

# Upgrade to the fixed release in pom.xml, then rebuild
# <dependency>
#   <groupId>org.eclipse.lyo</groupId>
#   <artifactId>oauth-core</artifactId>
#   <version>6.0.1.Final</version>
# </dependency>
mvn clean install