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

[devteamaegis]

Issue # (if applicable)

Closes #38475.

Reason for this change

events.Match.cidr() throws at synth time on any IPv6 range that embeds an IPv4 address, and accepts a nonsense one.

Match.cidr('::ffff:192.168.0.1');      // Error: Invalid IP address range
Match.cidr('64:ff9b::192.0.2.33/96');  // Error (NAT64, RFC 6052)
Match.cidr('::ffff:1dd.1dd.1dd.1dd');  // accepted

IPv4-mapped IPv6 (::ffff:a.b.c.d, RFC 4291 §2.5.5) is a normal way to write these ranges, so an EventBridge rule using one fails to synth at all. Plain IPv4 and plain IPv6 are unaffected.

Description of changes

The IPv6 regex in Match.cidr lost its backslashes in the embedded-IPv4 alternatives. It reads

(25[0-5]|2[0-4]d|1dd|[1-9]?d)(.(25[0-5]|2[0-4]d|1dd|[1-9]?d)){3}

so d matches the literal letter d rather than \d, and the separator . matches any character. 192 cannot match [1-9]?d, which is why every real address is rejected — and 1dd matches literally, which is why the malformed one passes. The leading/trailing s* (for \s*) is wrong the same way.

This restores \d, \. and \s in that group — 14 occurrences, one line, no structural change.

The identical regex is also in aws-ec2/lib/prefix-list.ts; that copy is fixed separately in #38474, since the two modules cannot share a helper.

Describe any new or updated permissions being added

None.

Description of how you validated changes

Two unit tests added in aws-events/test/matchers.test.ts, covering the accepted and rejected cases. Both fail on main:

✕ cidr accepts IPv6 addresses with an embedded IPv4 address
  «InvalidIpAddressRange» Invalid IP address range: ::ffff:192.168.0.1
✕ cidr rejects IPv6 addresses with a malformed embedded IPv4 address
  Expected pattern: /Invalid IP address range/ ... Received function did not throw

and pass with the change. Full module suite jest aws-events/test: 178 passed across 10 suites. ESLint clean.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Fixes must contain a change to an integration test file and the resulting snapshot.

If you believe this pull request should receive an exemption, please comment and provide a justification. A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed, add Clarification Request to a comment.

✅ A exemption request has been requested. Please wait for a maintainer's review.

[devteamaegis]

Exemption Request

This change is confined to a client-side validation regex in Match.cidr. For every input that already synthesized, the emitted output is byte-identical — Match.cidr returns { cidr: <range> } with the range passed through verbatim, so there is no CloudFormation difference for an integration test to observe. The only behavioural change is which strings are allowed past validation, which is fully determined at synth time.

An integ.*.ts here would deploy an EventBridge rule whose template the added unit tests already assert directly, so it would add deployment cost without adding coverage of the thing that changed.

The two unit tests in aws-events/test/matchers.test.ts cover both directions — addresses that were wrongly rejected are now accepted, and a malformed embedded IPv4 address (::ffff:1dd.1dd.1dd.1dd, which the broken regex accepted) is still rejected. Both fail on main and pass with the change.

Happy to add an integration test instead if you'd prefer one; please say so and I'll follow up.

[devteamaegis]

Exemption Request

This is a validation-only change: one line in aws-events/lib/event-pattern.ts broadens the IPv6 CIDR regex in Match.cidr() to accept IPv4-mapped / embedded-IPv4 forms (::ffff:a.b.c.d, 64:ff9b::192.0.2.33/96 — RFC 4291 §2.5.5) and to reject the malformed ::ffff:1dd.1dd.1dd.1dd case it previously accepted.

It only changes which strings are accepted at synth time — for any input that already synthesized, the emitted event pattern is byte-for-byte unchanged. There is no new deployable/runtime behavior for an integration test to exercise; the fix is pure input validation.

It's fully covered by the unit tests added in aws-events/test/matchers.test.ts (accepts ::ffff:192.168.0.1 and 64:ff9b::192.0.2.33/96, rejects ::ffff:1dd.1dd.1dd.1dd). An integ test would deploy an EventBridge rule solely to re-assert that string validation, adding no coverage beyond the unit tests. Happy to add one if you'd prefer.