[2609] fix ReDoS vulnerability in email regex

[MacsDickinson]

Fixes #2609

The current regex used for email validation contains "catastrophic backtracking", specifically ([A-Z0-9_+-]+\.?)*. This gets evaluated inefficiently by JS, resulting in an exponential increase in execution time for failed matches.

This can be replicated easily - here's execution time against ^([A-Z0-9_+-]+\.?)*[A-Z0-9_+-]@([A-Z0-9][A-Z0-9\-]*\.)+[A-Z]{2,}$

string	match	execution
aaaaaaaaaaaaaaaaaaaaaaa@test.c	false	0.615s
aaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	1.165s
aaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	2.280s
aaaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	4.507s
aaaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	8.964s
aaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	18.018s
aaaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	💀

This PR provides an alternative regex. Rather that matching on the (aaaaa.)+ we instead do a negative lookahead for the presence of .. or the email starting with a .. This approach isn't susceptible to ReDoS

here's execution time against ^(?!\.)(?!.*\.\.)([A-Z0-9_+-\.]*)[A-Z0-9_+-]@([A-Z0-9][A-Z0-9\-]*\.)+[A-Z]{2,}$

regex	email	match	execution
aaaaaaaaaaaaaaaaaaaaaaa@test.c	false	0.044s
aaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	0.046s
aaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	0.044s
aaaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	0.046s
aaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	0.045s
aaaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	0.045s
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c	false	0.044s

[netlify]

✅ Deploy Preview for guileless-rolypoly-866f8a ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	b1f3cc0
🔍 Latest deploy log	https://app.netlify.com/sites/guileless-rolypoly-866f8a/deploys/6516e56b5e364f00087df9e1
😎 Deploy Preview	https://deploy-preview-2824--guileless-rolypoly-866f8a.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Leiloukou]

I checked it on a popular ReDoS checker... it's completely safe!

[samchungy]

Hey @colinhacks, could we please get a tiny patch release for this one 🙇

https://security.snyk.io/vuln/SNYK-JS-ZOD-5925617

[maietta]

Bump!

[colinhacks]

Thanks @MacsDickinson this is massively appreciated
Landed in Zod 3.22.3

[kurtextrem]

May I ask what speaks against using the HTML5 spec regex instead of a hand rolled one?

An old variant is even already in the source (commented out), and PR #2157 even says:

Nice! I'd missed this. I think it makes sense and seems to be functionally equivalent to mine but with support for "printable characters" in the local part. I'm not convinced emails with those characters should be considered valid, but I like the parity with browsers.

The HTML5 spec regex is not vulnerable: https://stackoverflow.com/a/8829363.

From the previous PR, I also want to mention someone mentioned emails like O'Railey@domain.com return false currently.

[rktyt]

Could you please backport it to 3.21.4?
Because currently our code does not work in 3.22.

[fabian-hiller]

The email regex we plan to use for Valibot is more accurate and twice as fast. If interested, I can provide more details.

1. Open this link: https://esbench.com/bench/6520e66d7ff73700a4deba40
2. Navigate to Results
3. Click RUN BENCHMARK button

[fabian-hiller]

Here ist the final regex, we plan to use for Valibot.

[tjenkinson]

I opened #2849 to add a redos check to eslint

[tgds]

Fixes #2609

The current regex used for email validation contains "catastrophic backtracking", specifically ([A-Z0-9_+-]+\.?)*. This gets evaluated inefficiently by JS, resulting in an exponential increase in execution time for failed matches.

This can be replicated easily - here's execution time against ^([A-Z0-9_+-]+\.?)*[A-Z0-9_+-]@([A-Z0-9][A-Z0-9\-]*\.)+[A-Z]{2,}$

string match execution
aaaaaaaaaaaaaaaaaaaaaaa@test.c false 0.615s
aaaaaaaaaaaaaaaaaaaaaaaa@test.c false 1.165s
aaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 2.280s
aaaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 4.507s
aaaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 8.964s
aaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 18.018s
aaaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 💀
This PR provides an alternative regex. Rather that matching on the (aaaaa.)+ we instead do a negative lookahead for the presence of .. or the email starting with a .. This approach isn't susceptible to ReDoS

here's execution time against ^(?!\.)(?!.*\.\.)([A-Z0-9_+-\.]*)[A-Z0-9_+-]@([A-Z0-9][A-Z0-9\-]*\.)+[A-Z]{2,}$

regex email match execution
aaaaaaaaaaaaaaaaaaaaaaa@test.c false 0.044s
aaaaaaaaaaaaaaaaaaaaaaaa@test.c false 0.046s
aaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 0.044s
aaaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 0.046s
aaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 0.045s
aaaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 0.045s
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa@test.c false 0.044s

may I ask, what environment did you use to test it? I'm trying to replicate the issue, but the vulnerable expression seems to perform well anywhere I test.

[Leiloukou]

It looks safe to me!

I usually use devina when checking for redos vulnerabilities. Anyway, here's what it says:

Btw, I've been looking for the perfect email regex for over 3 years, I'm honestly surprised that this works.