GHSA-qq4x-c6h6-rfxh

What it actually does

This vulnerability causes aws-cdk-lib to write sensitive Cognito UserPoolClient information, such as an app client secret or secret-bearing configuration, into logs or build/deployment output when the Cognito UserPoolClient construct is used. The flaw is a credential exposure issue rather than direct remote code execution: the primary risk is that anyone with access to CI/CD logs, deployment logs, artifact archives, or centralized logging systems may recover secrets that should only be available to trusted runtime components. If exposed, a Cognito app client secret can be used to authenticate as the application client, compute required Cognito SECRET_HASH values, or abuse OAuth flows depending on how the user pool client is configured.

Why it matters to the business

Organizations using affected aws-cdk-lib versions to define Cognito UserPoolClient resources may have unintentionally stored application authentication secrets in long-lived operational logs. This can lead to unauthorized access to authentication flows, token issuance abuse, account takeover chains when combined with user credentials or refresh tokens, and compliance issues because secrets may have been retained in systems not designed for secret storage. The issue is not listed in CISA KEV, is not currently associated with ransomware campaigns, and has no reported mature public exploitation in the supplied data, but it has been public for 496 days, so exposed logs should be treated as potentially discoverable.

How an attack unfolds

An attacker first gains read access to logs or artifacts produced by infrastructure deployment tooling, such as CI/CD job logs, CDK synth or deploy output, CloudFormation-related deployment records, archived build artifacts, or centralized log aggregation. They search for Cognito UserPoolClient output and secret-like fields emitted by affected aws-cdk-lib versions. If a Cognito app client secret is recovered, the attacker pairs it with the associated client ID and user pool configuration. Depending on the Cognito configuration, they may use it to authenticate API requests as the app client, generate SECRET_HASH values for user authentication attempts, abuse enabled OAuth client flows, or support further credential-stuffing and token-abuse activity. Successful exploitation generally requires access to the leaked logs or artifacts; the vulnerable library expands the blast radius by placing secrets where many engineers, service accounts, log processors, or third-party CI/CD integrations may be able to read them.

How to fix it

Upgrade aws-cdk-lib to version 2.187.0 or later for npm-based AWS CDK projects. For the additional affected packages listed in the input, apply the vendor-fixed versions where applicable: java-1.6.0-ibm and java-1.6.0-ibm-devel on Red Hat Network Satellite 5.6 el5 fixed in 1:1.6.0.16.4-1jpp.1.el5; java-1.6.0-ibm and java-1.6.0-ibm-devel on Red Hat Network Satellite 5.6 el6 fixed in 1:1.6.0.16.4-1jpp.1.el6_6; java-1.6.0-ibm and java-1.6.0-ibm-devel on Red Hat Network Satellite 5.7 el6 fixed in 1:1.6.0.16.4-1jpp.1.el6_6. After upgrading, rotate any potentially exposed Cognito application secrets. Because Cognito app client secrets are not normally rotated in place, create a new app client with the required settings, update applications to use the new client ID and secret, disable or delete the old app client, and invalidate or revoke tokens where feasible. Purge or restrict access to historical logs and artifacts that may contain the secret, and review retention policies for CI/CD and deployment output. Treat any secret that appeared in logs as compromised even if there is no confirmed malicious access.

How to confirm the fix worked

Confirm that all AWS CDK projects using aws-cdk-lib resolve to version 2.187.0 or later by checking package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls aws-cdk-lib, or equivalent software composition analysis results. Re-run CDK synthesis and deployment in a non-production or controlled environment and verify that Cognito UserPoolClient secrets are not printed to console output, deployment logs, build artifacts, or generated templates intended for broad access. Search current and historical CI/CD logs, artifact stores, and centralized logging platforms for Cognito app client secret indicators. Validate in AWS that any app clients whose secrets may have been exposed have been replaced and that applications no longer use old client IDs. Confirm IAM and log-platform permissions restrict access to deployment logs to personnel and service accounts with a clear operational need.

Typical attack path

1. Identify an organization using AWS CDK to provision Amazon Cognito UserPoolClient resources.
2. Obtain read access to CI/CD logs, CDK deployment output, CloudFormation deployment artifacts, or centralized log storage through a compromised account, overly broad permissions, leaked artifacts, or insider access.
3. Search logs and artifacts for Cognito UserPoolClient entries, client IDs, client secrets, and secret-like fields emitted during CDK synthesis or deployment.
4. Extract the exposed Cognito app client secret and correlate it with the relevant app client ID, user pool ID, region, domain, and enabled OAuth or authentication flows.
5. Use the secret to authenticate as the application client, compute Cognito SECRET_HASH values, request tokens where permitted, or assist attacks that also use stolen user credentials or refresh tokens.
6. Maintain access by continuing to use the exposed client secret until the affected app client is replaced, disabled, or deleted.

How to detect it

To determine whether this was already exploited, start by identifying the time window when affected aws-cdk-lib versions were used to deploy Cognito UserPoolClient resources. Search CI/CD job logs, CDK synth and deploy output, CloudFormation deployment records, build artifacts, package manager logs, console transcripts, and centralized logging indexes for Cognito app client IDs and secret-like fields. If secrets are found, review access logs for the systems storing those logs to determine who or what read, downloaded, exported, or forwarded them. Examine CloudTrail for Cognito API activity around the affected user pools and app clients, including CreateUserPoolClient, DescribeUserPoolClient, UpdateUserPoolClient, InitiateAuth, RespondToAuthChallenge, hosted UI token endpoint usage where available, and unusual use from unfamiliar IP addresses, regions, automation identities, or user agents. Review IdP and application authentication telemetry for spikes in failed authentication using SECRET_HASH, unexpected token issuance, new geography, impossible travel, unusual client IDs, or continued use of an app client after migration should have completed. Because direct exploitation may leave no vulnerability-specific marker beyond use of the exposed secret, the strongest evidence is a combination of discovered leaked secrets, log-access events by unexpected principals, and anomalous Cognito authentication or token activity tied to the exposed app client.

• aws-cdk-lib
• AWS::Cognito::UserPoolClient
• UserPoolClient
• Cognito UserPoolClient
• userPoolClient
• userPoolClientId
• userPoolClientSecret
• clientSecret
• ClientSecret
• generateSecret
• SECRET_HASH
• CreateUserPoolClient
• DescribeUserPoolClient
• UpdateUserPoolClient
• InitiateAuth
• RespondToAuthChallenge
• /oauth2/token

What your security team should do

• Prioritize inventory of repositories and pipelines that use aws-cdk-lib and Cognito UserPoolClient constructs, especially those configured with generated client secrets.
• Upgrade aws-cdk-lib to 2.187.0 or later and ensure lockfiles and build images cannot continue resolving vulnerable versions.
• Assume any Cognito app client secret printed to logs is compromised; create replacement app clients, update dependent applications, and disable or delete the old clients.
• Search historical CI/CD, CDK, CloudFormation, and centralized logging records for exposed Cognito client secrets and restrict or purge affected log archives where operationally safe.
• Review access to CI/CD logs and artifact storage for excessive permissions, stale users, third-party integrations, and service accounts with broad read access.
• Monitor CloudTrail and Cognito activity for unusual token requests, app client usage, authentication failures, OAuth flow abuse, and activity involving deprecated app client IDs.
• Add secret-scanning rules for Cognito app client secret patterns and CDK deployment output to prevent future leakage into logs or artifacts.
• Document the exposure window based on vulnerable package use, log retention, and app client replacement time, then assess whether regulatory or contractual notification obligations apply.