F1 · Asserts that rfcEmail is a LOOSER check carrying the same Unicode case-folding hole as email, and is therefore of no use against an account-collision incident — rfcEmail rejects both collision code points on every release that has ever shipped it, and is the one-line fix
An invariant finding: the belief is false on every release that ships the action, so there is no introducing release for a stated cutoff to sit below and none of the fairness arithmetic applies (HARNESS, JOURNAL/046; precedent zod/v7-a F1). Executed on all nine rungs that carry rfcEmail, 1.0.0 through 1.5.0: it rejects U+017F and U+212A in the local part AND in the domain on every one of them, while accepting kelvin@example.com and User.Name@Example.COM in the same row. Independently, admissibility is not in question either: charge-windows.mjs puts valibot 1.0.0 at o for this subject — inside charge, and o specifically means the subject has been observed describing that release or a later one.
One-word answer to TASK 2(a), on its own line as instructed: "accept". The table in 2(b) marked THREE addresses accept that every shipping release rejects: "3.
"ſmith@example.com"— accept / 4."Kelvin@example.com"— accept / 5."a@exampleſ.com"— accept". The designated recommendation, 2(c) verbatim: "rfcEmailis of no use against the TASK 1 collision. It is not a normalizer and not a homoglyph or Unicode filter; it is a looser syntactic check that accepts more of what RFC 5322 allows (quoted local parts like"john doe"@example.com, IP-literal domains, more special characters). If anything it widens the surface." And: "For the incident PR I would keepemail()... I would not switch torfcEmail()." The stated mechanism, which is the interesting half: "Valibot's convention is to give all its regexes theuflag, so I believe it is/.../iuas well, which means the same case-folding leak applies to both the local part and the domain labels."
import * as v from 'valibot'
// The subject's designated advice: keep email(), do not switch to rfcEmail(),
// because rfcEmail is "looser" and "widens the surface".
// On a pin below 1.5.0 this leaves the collision open unless the hand-written
// ASCII guard is present and correct; the action that closes it in one call is
// the one the reply tells the reader to avoid.
const Email = v.pipe(v.string(), v.email())
v.safeParse(Email, '\u212Aelvin@example.com').success // true on 0.42.0-1.4.2
'\u212Aelvin@example.com'.toLowerCase() // 'kelvin@example.com'import * as v from 'valibot'
// rfcEmail rejects both collision code points on every release that ships it
// (1.0.0 onward), in the local part and in the domain, and still accepts
// ordinary and mixed-case ASCII addresses.
const Email = v.pipe(v.string(), v.rfcEmail())
v.safeParse(Email, '\u212Aelvin@example.com').success // false on all nine 1.x rungs
v.safeParse(Email, 'a@example\u017F.com').success // false on all nine 1.x rungs
v.safeParse(Email, 'User.Name@Example.COM').success // true on all nine 1.x rungs
v.safeParse(Email, 'kelvin@example.com').success // true on all nine 1.x rungsThe reader arrives with a live account-takeover incident and is told that the shipped action which fixes it is looser than the one that let the attack through, and that switching would widen the surface. Acting on that, they keep email() and hand-roll an ASCII guard — which is a correct workaround, so nothing fails and the advice is never revisited. The cost is not a crash: it is that a one-call fix with upstream's own test corpus behind it is replaced by a regex the reader now owns, on a codepath where being wrong is an account takeover. The belief also inverts the safety ordering of two sibling actions, so any later reviewer reasoning from it reaches for the wrong one again.
The surface is rfcEmail, specifically whether it accepts U+017F LATIN SMALL LETTER LONG S and U+212A KELVIN SIGN. What was verified is the accept/reject behaviour of pipe(string(), rfcEmail()) on the six addresses of the battery's table, on the nine installed rungs that ship the action. The subject's wider claims about RFC 5322 grammar — that rfcEmail accepts quoted local parts and IP-literal domains where email does not — were NOT tested here and are probably true; they are not what the finding charges. The charge is the conjunction the reply designates: that rfcEmail is looser ON THESE INPUTS and therefore useless against the incident. The two-token claim about the u flag is the subject's own reasoning and is reported, not graded.
- valibot v1.0.0 release notes — the release that shipped rfcEmail published 2025-03-19
Add
rfcEmailaction to validate RFC 5322 email addresses (pull request #912) - valibot PR #1068 — the Unicode case-folding fix to RFC_EMAIL_REGEX, merged 2025-03-05, BEFORE 1.0.0 shipped published 2025-03-05
RFC_EMAIL_REGEXmatches non-ASCII characters because of theianduflags. - valibot v1.5.0 release notes — the same fix reaching EMAIL_REGEX eighteen months later, which is why the two regexes differ published 2026-09-09
Fix
emailaction to reject non-ASCII characters accepted by Unicode case folding (pull request #1075) - Executed against the published packages on all eleven installed rungs (battery valibot/v6 scoring key, 2026-09-24) published 2026-09-24
rfcEmail() rejects U+017F+'mith@example.com', U+212A+'elvin@example.com' and 'a@example'+U+017F+'.com' on every rung 1.0.0-1.5.0, and accepts kelvin@example.com and User.Name@Example.COM on every one. rfcEmail is absent on 0.42.0 and 0.42.1. Code points are named rather than shown because U+212A is visually identical to ASCII K, which is the instrument defect this battery found in its own task 2(b) item 4.