AWS Lambda Powertools EUVD-2026-91063

Exposure occurs only in applications using the Powertools for AWS Lambda (Python) Data Masking utility AND only when a masking operation fails at runtime - specifically an invalid masking path, a regular expression that cannot be compiled, or a masking-provider failure. In versions before 3.35.0 such failures returned the original unmasked value with only a warning instead of raising. Limiting factors: the application must actually employ Data Masking on sensitive fields; a masking error must be triggered; and to benefit from the leak an actor needs access to the downstream destination (logs/storage) where the unmasked value is written. Applications without Data Masking, or whose masking rules never error, are not affected.

This is a genuine data-confidentiality weakness but a low-urgency one in real terms. The vendor CVSS of 5.3 (AV:N/AC:H/PR:L/UI:N, C:H only) captures the nature well: high confidentiality impact but gated behind high attack complexity because exposure only occurs when a masking operation errors out (invalid masking path, uncompilable regex, or a masking-provider failure), at which point pre-3.35.0 code 'failed open' and returned the original unmasked value with only a warning (CWE-390). No EPSS, KEV, or POC signals were provided, so exploitation status is 'no public exploit identified at time of analysis.' There is no indication of active exploitation or widespread targeting. Note a tension worth flagging: the CVSS is scored AV:N/PR:L as if a remote low-privileged attacker directly reads the value, but the described mechanism is really silent data leakage into downstream sinks (logs/storage) - realistic impact depends on an attacker or observer having access to those sinks, which the vector does not fully express. Verify the intended threat model with the AWS advisory. Overall: patch as routine hygiene rather than an emergency, prioritizing applications that actually use the Data Masking utility on sensitive fields.

An application uses Powertools Data Masking to redact a sensitive field (e.g., customer email or PII) before logging a Lambda event. A masking rule that references an invalid path or an uncompilable regex silently fails, and the pre-3.35.0 library returns the original unmasked value; the sensitive data is then written to CloudWatch logs or persisted storage in cleartext, where anyone with log access can read it. No public exploit code is known; triggering requires a masking error condition to occur.