CVE-2026-54430: OpenIDC liboauth2 · Server-Side Request Forgery (SSRF)
Affects OpenIDC liboauth2Source CVE Database V5
Not known to be exploited · CVSS 5.1 Medium : upgrade to 2.3.0 when convenient.
Data as of 14 Nov 2026, 20:44 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.3.0
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 2 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 14 Nov 2026.
What to do
Upgrade OpenIDC liboauth2 to 2.3.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| OpenIDCliboauth2 | Affected
| Fixed in
|
GitHubliboauth2pkg:github/liboauth2Other threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A patch is available and the issue is fixed in liboauth2 version 2.3.0. Users should upgrade to version 2.3.0 or later to remediate this vulnerability. Since this is a cloud-hosted service component, the vendor manages remediation for the cloud service; users should verify with the vendor advisory for confirmation of patch deployment. No additional mitigation steps are indicated.
Description
liboauth2 is vulnerable to Server-Side Request Forgery in oauth2_jose_jwks_aws_alb_resolve() function. The AWS ALB verifier reads both signer and kid from the unverified JWT header. If signer matches the configured ARN, kid is appended to alb_base_url without URL encoding or path sanitization, and the HTTP GET is issued before signature verification. This allows an attacker to force the server to send a GET request to an attacker-chosen internal path. This issue was fixed in version 2.3.0