EUVD-2026-41276
GHSA-qrcr-3862-9f4c
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
JWT submitted over network pre-verification requires no privileges; scope changes as SSRF reaches internal systems; no integrity or availability impact on the vulnerable system itself.
Primary rating from Vendor (CERT-PL).
CVSS VectorVendor: CERT-PL
Lifecycle Timeline
2DescriptionCVE.org
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
AnalysisAI
Server-Side Request Forgery in liboauth2 prior to version 2.3.0 allows an unauthenticated attacker to force any application using the AWS ALB JWT verification path to issue GET requests to arbitrary internal network paths. The vulnerability exists because the oauth2_jose_jwks_aws_alb_resolve() function reads the unverified kid JWT header field and appends it directly to the configured alb_base_url - without URL encoding or path sanitization - before any cryptographic signature check occurs. No public exploit code has been identified at time of analysis, but the low attack complexity and zero privilege requirement make this a meaningful risk for AWS-integrated deployments where liboauth2 handles ALB token verification.
Technical ContextAI
liboauth2 (CPE: cpe:2.3:a:openidc:liboauth2:*:*:*:*:*:*:*:*) is an open-source C library maintained by the OpenIDC project, used primarily by Apache HTTP Server and nginx modules (such as mod_auth_openidc) to perform OAuth2 and OpenID Connect token validation. The vulnerable function oauth2_jose_jwks_aws_alb_resolve() implements key resolution for JWTs issued by AWS Application Load Balancers. The root cause is CWE-918 (Server-Side Request Forgery): the function reads both signer and kid from the JWT header before verifying the token's signature. If signer matches the operator-configured ARN, the raw kid value is concatenated onto alb_base_url and an HTTP GET is dispatched immediately - violating the fundamental security invariant that JWT header fields must be treated as untrusted input until signature verification completes. Because kid is not URL-encoded or path-sanitized, an attacker who controls the JWT can steer the server's outbound request to any internal path reachable from the application host. The fix is confirmed in commit 347507ac5b51f48c2933bbe49b2ee07c2af4712b and released as version 2.3.0.
RemediationAI
Upgrade liboauth2 to version 2.3.0 or later, which resolves the issue via commit 347507ac5b51f48c2933bbe49b2ee07c2af4712b (https://github.com/OpenIDC/liboauth2/commit/347507ac5b51f48c2933bbe49b2ee07c2af4712b). If an immediate upgrade is not possible, restrict the application's outbound HTTP connectivity using host-based firewall rules or security group policies to block requests to sensitive internal endpoints such as the AWS Instance Metadata Service (169.254.169.254), internal VPC services, and non-ALB endpoints - this limits the SSRF blast radius but does not eliminate the vulnerability. Additionally, deploying a WAF or API gateway that validates JWT structure before forwarding to liboauth2-protected services can reduce exposure, though this does not substitute for patching since the bypass occurs within the library itself. Both workarounds carry operational trade-offs: firewall rules require ongoing maintenance as internal topology changes, and WAF-based mitigations may introduce latency or false positives.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today