CVE-2026-19363: oidc-authorizer Information Disclosure Flaw

CVE-2026-19363 Overview

CVE-2026-19363 is an information exposure vulnerability affecting lmammino/oidc-authorizer up to version 0.4.0. The flaw resides in src/handler.rs, the Lambda Authorizer component that validates OpenID Connect (OIDC) tokens on AWS API Gateway. On authentication failure paths, the handler logs raw Authorization header values along with complete bearer tokens and JSON Web Tokens (JWTs). These secrets are written to Amazon CloudWatch Logs, where any principal with log-read access can retrieve them. A separate propagation path in src/models.rs also forwards the full validated JWT claims set into downstream integrations. The issue is tracked under [CWE-200] Information Exposure.

Critical Impact
Bearer tokens and JWTs written to CloudWatch Logs can be replayed by anyone with log-read privileges, enabling account takeover of upstream identity providers and downstream APIs.

Affected Products

lmammino oidc-authorizer versions up to and including 0.4.0
AWS Lambda deployments using the Lambda Authorizer component
Any API Gateway integration relying on context["jwtClaims"] propagation

Discovery Timeline

2026-08-09 - CVE-2026-19363 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-19363

Vulnerability Analysis

The oidc-authorizer project is a Rust-based AWS Lambda Authorizer that validates OIDC-issued JWTs before requests reach protected API Gateway routes. The vulnerability arises in two related code paths within the authenticator.

In src/handler.rs, failure branches emit log records containing the raw Authorization header. Because bearer tokens flow inline within that header, the complete JWT is captured verbatim in CloudWatch Logs. Attackers who can query those logs, including IAM principals with broad logs:FilterLogEvents permissions, obtain reusable credentials.

In src/models.rs, the authorizer serializes the entire validated claims set with serde_json::to_string(token_claims).unwrap() and injects the result into context["jwtClaims"]. Downstream Lambda functions and backend services then receive sensitive identity attributes beyond what the integration requires. This code path performs serialization only and does not process attacker-controlled jwtClaims input.

Root Cause

The root cause is verbose diagnostic logging combined with wholesale claim propagation. The handler treats the raw header as a debuggable value rather than a secret, and the model layer forwards complete claims instead of a minimum-necessary subset.

Attack Vector

The attack is remote and requires no authentication. An attacker with read access to CloudWatch Logs, whether an insider, a compromised low-privilege IAM user, or a third party granted log access for observability, can extract valid JWTs. Recovered tokens can then be replayed against the protected API until they expire.

No verified proof-of-concept code is published. The vulnerability manifests through configuration and log inspection rather than through crafted payloads. See the VulDB entry for CVE-2026-19363 for additional technical details.

Detection Methods for CVE-2026-19363

Indicators of Compromise

CloudWatch Log entries from the authorizer Lambda that contain Bearer eyJ sequences or full Authorization: header values
Unexpected logs:FilterLogEvents or logs:GetLogEvents API calls against the authorizer log group
Downstream service logs referencing jwtClaims fields not required by the business logic

Detection Strategies

Scan CloudWatch Logs for regular expressions matching JWT structure (eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+) within authorizer log groups
Correlate CloudTrail GetLogEvents activity against the authorizer log group with unusual principals, source IPs, or off-hours access
Alert on replays of the same JWT jti claim from divergent IP addresses or user agents within the token validity window

Monitoring Recommendations

Enable CloudTrail data events for CloudWatch Logs and forward them to a centralized data lake for continuous review
Track IAM policies granting logs:* against Lambda authorizer log groups and require just-in-time elevation
Monitor the version of oidc-authorizer deployed across accounts through infrastructure-as-code inventory

How to Mitigate CVE-2026-19363

Immediate Actions Required

Rotate any OIDC signing keys and revoke active refresh tokens that may have transited affected authorizer versions
Restrict IAM permissions on the authorizer Lambda log group to a minimal set of operators
Purge historical log streams that contain captured bearer tokens after evidence preservation

Patch Information

As of publication, the maintainer has not issued a fixed release. VulDB notes the vendor was contacted but did not respond. Track the oidc-authorizer project references for a future patched version above 0.4.0. Until a patch ships, operators should apply the workarounds below.

Workarounds

Fork the project and remove Authorization header values and raw token strings from all log::error!, log::warn!, and println! statements in src/handler.rs
Replace the full serde_json::to_string(token_claims) propagation in src/models.rs with an allowlist of specific claims (for example, sub, aud, exp) required by downstream services
Set the Lambda log retention to the minimum operationally acceptable value and encrypt the log group with a customer-managed KMS key
Deploy an AWS WAF or API Gateway request transformer that strips verbose diagnostic responses before they reach clients

bash

# Configuration example: restrict CloudWatch Logs access and shorten retention
aws logs put-retention-policy \
  --log-group-name /aws/lambda/oidc-authorizer \
  --retention-in-days 1

aws logs associate-kms-key \
  --log-group-name /aws/lambda/oidc-authorizer \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/EXAMPLE-KEY-ID