(events): Match.cidr rejects IPv6 addresses with an embedded IPv4 address

[devteamaegis]

Describe the bug

events.Match.cidr() throws Invalid IP address range at synth time for any IPv6 range that embeds an IPv4 address, and accepts a malformed one.

Regression?

No

Last known working version

n/a

Expected Behavior

Match.cidr('::ffff:192.168.0.1') and Match.cidr('64:ff9b::192.0.2.33/96') should be accepted — both are valid CIDR ranges (RFC 4291 §2.5.5 IPv4-mapped, RFC 6052 NAT64). Match.cidr('::ffff:1dd.1dd.1dd.1dd') should be rejected.

Current Behavior

Error: Invalid IP address range: ::ffff:192.168.0.1
Error: Invalid IP address range: 64:ff9b::192.0.2.33/96

and ::ffff:1dd.1dd.1dd.1dd is accepted.

Reproduction Steps

import { Match } from 'aws-cdk-lib/aws-events';

Match.cidr('2001:db8::/32');        // ok
Match.cidr('::ffff:192.168.0.1');   // throws

Possible Solution

The IPv6 regex in aws-events/lib/event-pattern.ts lost its backslashes in the embedded-IPv4 alternatives — (25[0-5]|2[0-4]d|1dd|[1-9]?d) matches the literal letter d rather than \d, and the . separator matches any character. Restoring \d, \. and \s fixes it.

Additional Information/Context

The same regex is duplicated in aws-ec2/lib/prefix-list.ts and has the same defect.

CDK CLI Version

n/a (synth-time validation)

Framework Version

aws-cdk-lib (current main)

Node.js Version

20.x

OS

macOS

Language

TypeScript

[pahud]

Hi @devteamaegis,

Thanks for the thorough report — nice work catching the false-accept side too.

Reproduced on aws-cdk-lib 2.262.0. Match.cidr correctly rejects pure IPv4 and IPv6, but rejects valid IPv4-mapped/NAT64 ranges and accepts malformed ones like ::ffff:1dd.1dd.1dd.1dd. Marking as p2 — synth-time validation bug with a workaround, no deployment blockage.

The false-accept is worth calling out: an invalid event pattern deploys silently and never matches, so a rule looks healthy while dropping every event. Good argument for explicit test coverage on the malformed case in #38473.

Workaround: use hex-only notation — Match.cidr('64:ff9b::c000:221/96') instead of 64:ff9b::192.0.2.33/96.

One small note for #38473: the /igm flags on the regexes can be trimmed to /i — harmless now, but the g flag is a footgun if the regex ever gets hoisted to module scope.

This and #38476 are siblings, not duplicates — same regex text, different modules, each needs its own fix. Tracking separately is right.