[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
[email protected]	false	0.615s
[email protected]	false	1.165s
[email protected]	false	2.280s
[email protected]	false	4.507s
[email protected]	false	8.964s
[email protected]	false	18.018s
[email protected]	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
[email protected]	false	0.044s
[email protected]	false	0.046s
[email protected]	false	0.044s
[email protected]	false	0.046s
[email protected]	false	0.045s
[email protected]	false	0.045s
[email protected]	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.

[jacob-leger]

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'[email protected] 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
[email protected] false 0.615s
[email protected] false 1.165s
[email protected] false 2.280s
[email protected] false 4.507s
[email protected] false 8.964s
[email protected] false 18.018s
[email protected] 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
[email protected] false 0.044s
[email protected] false 0.046s
[email protected] false 0.044s
[email protected] false 0.046s
[email protected] false 0.045s
[email protected] false 0.045s
[email protected] 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.

[jacob-leger]

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.