Security: Please DO NOT use this library for email validity or domain validation

[eternal-flame-AD]

I sent @mfbx9da4 a notification of misuse of this library, possibly due to confusion in the design goal of this library despite the 'validator' in the package name. I received an acknowledgement in 12/4/2024 and opened PR #92 for a patch as we discussed in the email but it has not been reviewed yet.

Here is a reminder that please only use this library as a hint (in other words, frontend validation only), and do not base any critical decision on the behavior of this library nor pass sensitive information to it (because it may send network requests to unintended locations, the lack of rigorous validation could also potentially cause unintended SMTP command injection).

Original email to owner (reply not disclosed for privacy reasons, but gist was the owner would like to accept a PR):

Date: Mon, 25 Nov 2024 20:12:44 -0600
To: hiredavidadler@gmail.com
Content-Language: en-US
From: Yumechi <security@yumechi.jp>

Hi David,

(Sorry I this is the only email I can find of you that does not require a login.)

[redacted] I stumbled across a security issue in a project using your "deep-email-validator" library and although it might not be directly a vulnerability in your code depending on your intentions designing this library but I think is important to bring it to your attention.

[redacted]

However the check actually performed regarding the validity of address is lax and it seems like the library is more for validating genuine mistakes not maliciously crafted inputs, for example if you give the library [me@gmail.com@](mailto:me@gmail.com@) [<me@bad.com>](mailto:me@bad.com): the "regex" check will pass because (1) the address has at least one @ (2) the last @ has a suffix string with at least one dot. Then there is an inconsistency where in index.ts .split('@')[1] was used to re-extract the domain for MX and disposable validation as opposed to the last @, which in this case will split into "gmail.com" and thus perform all the rest of the checks on an attacker-controlled input.

Then if your user see the check passes and plug this straight into an email transport, it will be interpreted as RFC5322 angle-addr to me@bad.com leading to likely unintended behavior and can be a security threat if used for things like signup form validation.

I recommend this issue be fixed by (1) extracting the domain once and reusing across all checks to eliminate the inconsistency exploited here (2) clearly document that this package expect an already canonicalized address or add a strict checking mode which disallow things like angle-addr and subaddressing and only accept RFC5322 3.4.1 Addr-Spec addresses (https://www.rfc-editor.org/rfc/rfc5322#section-3.4.1) for things where normalized addresses are a must.

Thanks for your attention,

Yumechi