librest EUVD-2026-47742

Exploitation requires that the target application uses librest's built-in PKCE implementation for OAuth 2.0 authorization flows - specifically the GRand-based code verifier generation path. A legitimate user must actively initiate the OAuth authorization flow (UI:R per CVSS), providing the attacker with the authorization code and the window to act. The attacker must be positioned to observe PRNG-derived output (e.g., the code challenge or correlated GRand outputs) in order to recover the seed. Limiting factors: high attack complexity (AC:H) requiring PRNG seed reconstruction; exploitation is time-bounded by the authorization server's code expiry; the attacker cannot exploit this passively without an active user-initiated authorization event; applications using custom or alternative PKCE implementations unaffected. No special server-side configuration is required - the weakness exists in any librest OAuth client using the built-in PKCE flow.

The CVSS 3.1 vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N scores 6.8, reflecting meaningful but non-trivial exploitation: the attacker must successfully recover GRand's PRNG seed (AC:H) within the bounded lifetime of an OAuth authorization code, and a legitimate user must first initiate the flow (UI:R). The high C and I scores are well-calibrated - successful client impersonation grants the attacker full access to OAuth-protected resources and the ability to perform actions as the victim client. No EPSS score was provided in the input data; exploitation likelihood cannot be quantified from available signals. The absence of a KEV listing and no confirmed POC means this is not known to be actively exploited. Real-world risk is bounded by the AC:H requirement: recovering a GRand seed is technically feasible given the small seed space, but requires the attacker to be positioned to observe PRNG-derived outputs and act within the authorization window. Applications using librest's PKCE flow in sensitive OAuth contexts (e.g., accessing protected GNOME Online Accounts or enterprise APIs) carry higher practical risk than those in low-sensitivity deployments.

An attacker positioned to monitor or interfere with a target user's OAuth authorization flow - for example, via a network vantage point or a malicious application on the same host - observes the code challenge derived from librest's GRand-generated code verifier. The attacker brute-forces or reconstructs the 32-bit GRand seed from observed outputs, predicts the code verifier, and submits it to the OAuth token endpoint alongside the intercepted authorization code, obtaining a valid access token as the legitimate client. No public POC has been identified at time of analysis.