Eclipse Lyo CVE-2026-18918

Exploitation requires that the target server (1) enables/supports the 2-legged OAuth flow, and (2) bases its authorization filters on Lyo's AbstractAdapterCredentialsFilter - both are explicit prerequisites from the description and correspond to the CVSS AT:P attack requirement. Given those conditions, an attacker registers a provisional trusted client and uses it before administrator approval. Limiting factors: the 3-legged OAuth path is NOT vulnerable because it enforces interactive user authorization and rejects provisional clients, so deployments that use only 3-legged auth are not exploitable; environments not using AbstractAdapterCredentialsFilter for authz are also out of scope. No end-user interaction and no pre-existing credentials are needed on the vulnerable 2-legged path (UI:N/PR:N).

The vendor CVSS 4.0 base score is 9.1 (AV:N/AC:L/AT:P/PR:N/UI:N with high confidentiality and integrity impact), reflecting a network-reachable, unauthenticated authorization bypass - a serious combination. The AT:P (attack requirement) and the description's own conditions temper this: exploitation only works where the server enables 2-legged OAuth and relies on AbstractAdapterCredentialsFilter for authz, so it is not universally exploitable across all Lyo deployments. There is no KEV listing and no public PoC, and EPSS data was not provided, so real-world exploitation pressure appears low-to-unproven rather than active; however, the low attack complexity and lack of required privileges mean any exposed vulnerable instance should be patched promptly. Because Lyo is a niche integration framework, blast radius is limited by deployment footprint rather than by exploit difficulty, so organizations running Lyo-based OSLC adapters with 2-legged OAuth should treat this as high priority even though the broader internet-wide risk is modest.

An attacker who can reach a Lyo-based OSLC adapter that supports 2-legged OAuth registers a new trusted client, which is created in provisional (pending-approval) state. Instead of waiting for administrator approval, the attacker immediately issues 2-legged OAuth requests with that client and is treated as fully trusted, gaining access to protected OSLC resources. No public exploit code is currently identified, but the low complexity and lack of required authentication (PR:N) make weaponization straightforward for someone familiar with the API.