CVE-2025-23206

What it actually does

The flaw is a TLS certificate validation bypass in the AWS CDK IAM OIDC custom resource provider workflow. When the custom resource Lambda retrieves certificate authority thumbprints from a user-specified OIDC issuer URL, the implementation uses `tls.connect` with `rejectUnauthorized: false`, which accepts invalid, self-signed, expired, or attacker-presented certificates instead of validating the server certificate chain. An attacker able to intercept or redirect the outbound TLS connection during deployment could influence the thumbprint that CDK records for the IAM OIDC provider, potentially causing an incorrect trust anchor, failed federation, or in more constrained scenarios weakening the integrity of the identity trust configuration. The issue is low-likelihood because the issuer URL is supplied by the CDK application owner, the code runs during a deployment-time Lambda workflow, and exploitation generally requires a man-in-the-middle position or control over name resolution or routing between the Lambda environment and the OIDC issuer.

Why it matters to the business

Organizations using AWS CDK to create IAM OIDC providers may unknowingly deploy identity federation configuration based on an unverified TLS connection. The most likely business impact is unreliable or broken workload federation, deployment instability, or trust configuration drift. In a more targeted attack where an adversary can intercept deployment-time traffic to the OIDC issuer, the issue could contribute to misconfigured cloud identity trust and increase the risk of unauthorized access paths. This vulnerability is not in CISA KEV, is not reported as ransomware-used, has no known exploit maturity, and has a low EPSS score of 0.00318, so remediation should be prioritized as a hygiene and identity-assurance fix rather than an emergency internet-facing compromise scenario.

How an attack unfolds

An attacker first needs an opportunity to affect the TLS session made by the AWS CDK custom resource Lambda when it contacts the configured OIDC issuer URL to calculate CA thumbprints. This could involve control of a malicious issuer URL, DNS manipulation, proxy or routing control, compromised network infrastructure, or another man-in-the-middle position. During deployment or update of an IAM OIDC provider through CDK, the Lambda connects to the issuer endpoint. Because certificate verification is explicitly disabled, the Lambda accepts the attacker-presented certificate chain and may compute or return a thumbprint based on that chain rather than the legitimate issuer certificate chain. CDK then applies that thumbprint to the IAM OIDC provider configuration. Depending on the surrounding trust policy and issuer configuration, the result may be a broken federation setup, a trust relationship anchored to the wrong certificate material, or a condition that could support further identity abuse if the attacker can also influence later OIDC validation flows.

How to fix it

Upgrade AWS CDK source or packages to a version that includes the fix for the IAM OIDC custom resource handler. The provided fixed Git commit is `b396961272695cd70ac183fdaf842ffb48f5d91f`; ensure consumed CDK packages are built from or include that commit or a later upstream release. Where the fix is exposed through a feature flag, enable the flag that enforces proper TLS certificate validation for OIDC thumbprint retrieval, after testing existing OIDC issuer endpoints for valid certificate chains. Review all CDK-defined IAM OIDC provider issuer URLs and ensure they use expected HTTPS endpoints with publicly trusted, valid, non-expired certificates. If immediate upgrade is not possible, reduce exposure by avoiding creation or update of IAM OIDC providers from untrusted networks, preventing use of untrusted issuer URLs, pinning or manually verifying expected thumbprints, and monitoring for unexpected `CreateOpenIDConnectProvider` or `UpdateOpenIDConnectProviderThumbprint` activity.

How to confirm the fix worked

Confirm that AWS CDK packages or source code include commit `b396961272695cd70ac183fdaf842ffb48f5d91f` or a later fixed release. In source or dependency scans, verify that the IAM OIDC handler no longer calls `tls.connect` with `rejectUnauthorized: false` for issuer thumbprint retrieval, and that no deployment path sets `NODE_TLS_REJECT_UNAUTHORIZED=0`. Run a deployment test against a controlled OIDC issuer with an invalid or self-signed certificate; the fixed behavior should reject the connection unless explicitly allowed through the intended compatibility mechanism. Inventory IAM OIDC providers and compare configured thumbprints against independently obtained thumbprints from trusted tooling and a trusted network path. Review CloudTrail for recent `CreateOpenIDConnectProvider` and `UpdateOpenIDConnectProviderThumbprint` events and validate that changed thumbprints match the legitimate issuer certificate chain.

Typical attack path

1. Identify an environment or project that uses AWS CDK to provision IAM OIDC providers through the IAM OIDC custom resource provider package.
2. Gain influence over the issuer URL path, DNS resolution, proxying, routing, or TLS traffic between the custom resource Lambda and the OIDC issuer during a CDK deployment or update.
3. Wait for or trigger a CDK deployment that creates or updates the IAM OIDC provider and downloads CA thumbprints.
4. Present a certificate chain that would normally fail validation, such as a self-signed or attacker-controlled certificate.
5. Rely on the vulnerable `rejectUnauthorized: false` behavior so the Lambda accepts the invalid TLS connection and derives thumbprint data from the attacker-controlled certificate chain.
6. Cause the resulting IAM OIDC provider to be configured with an incorrect or attacker-influenced thumbprint.
7. Attempt follow-on impact such as federation disruption, identity trust manipulation, or additional attacks requiring control over the OIDC issuer or related validation path.

How to detect it

To determine whether this was already exploited, focus on deployment-time evidence and identity configuration changes rather than endpoint malware artifacts. Review CloudTrail management events for IAM OIDC provider creation or thumbprint modification, especially `CreateOpenIDConnectProvider` and `UpdateOpenIDConnectProviderThumbprint`, and correlate them with CDK deployment times. Investigate any issuer URL that is unfamiliar, misspelled, uses unexpected domains, or had certificate changes that do not match the legitimate provider history. Review CloudWatch Logs for the CDK custom resource Lambda that manages OIDC providers for errors, unexpected issuer endpoints, certificate or thumbprint retrieval messages, retries, or deployment events occurring during network or DNS anomalies. Check VPC Flow Logs, DNS resolver logs, NAT gateway logs, egress proxy logs, and firewall logs for outbound connections from deployment Lambda execution environments to OIDC issuer domains, unexpected IP addresses, unexpected TLS interception infrastructure, or unusual DNS answers. Examine source repositories and packaged Lambda/custom-resource assets for insecure TLS bypass strings. Finally, compare currently configured IAM OIDC provider thumbprints to thumbprints independently fetched from a trusted network path; unexplained mismatches are the strongest practical sign of possible exploitation or misconfiguration.

• rejectUnauthorized: false
• NODE_TLS_REJECT_UNAUTHORIZED=0
• packages/@aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts
• oidc-handler/external.ts
• Custom::AWSCDKOpenIdConnectProvider
• AWSCDKOpenIdConnectProvider
• CreateOpenIDConnectProvider
• UpdateOpenIDConnectProviderThumbprint
• iam.amazonaws.com CreateOpenIDConnectProvider
• iam.amazonaws.com UpdateOpenIDConnectProviderThumbprint
• b396961272695cd70ac183fdaf842ffb48f5d91f

What your security team should do

• Upgrade AWS CDK to a fixed release or source level containing commit `b396961272695cd70ac183fdaf842ffb48f5d91f`, and enable the TLS-validation feature flag if required.
• Inventory IAM OIDC providers created or managed by CDK and verify issuer URLs, client IDs, trust policies, and thumbprints against trusted sources.
• Search repositories and build artifacts for insecure TLS bypass patterns such as `rejectUnauthorized: false` and `NODE_TLS_REJECT_UNAUTHORIZED=0`, especially in deployment automation and custom resource handlers.
• Review CloudTrail for `CreateOpenIDConnectProvider` and `UpdateOpenIDConnectProviderThumbprint` events around CDK deployments, and investigate unexpected issuer URLs or thumbprint changes.
• Require valid publicly trusted certificates for all OIDC issuers used for cloud federation and treat certificate errors as deployment blockers.
• Because public exploitation indicators are limited and EPSS is low, handle this as a prioritized hardening issue for identity infrastructure rather than a broad incident unless suspicious OIDC provider changes or network interception evidence is found.