Drie fouten in Nodemailer's adresparser laten aanvallers e-mail omleiden naar domeinen die hun eigen validatie juist zou moeten blokkeren

Wat is er gebeurd

Beveiligingsonderzoekers hebben drie afzonderlijke parserfouten gevonden in het addressparser-onderdeel van Nodemailer, die allemaal dezelfde oorzaak hebben: addressparser stopt met lezen bij het eerste voorkomen van een structureel teken (een sluithaakje '>', een groep-afsluitende puntkomma ';', of een comment-afsluitend haakje ')'), zelfs wanneer dat teken binnen een aanhalingsteken-string, een comment, of een geneste comment staat. Een standaardconforme RFC 5322-parser houdt correct bij of zulke tekens zich binnen aanhalingstekens of geneste inhoud bevinden en negeert ze daar. GHSA-85x2-q946-cp5h betreft het parsen van hoekadressen: een '>' binnen een geciteerd local-part deel beëindigt het adres te vroeg, waardoor het domein verkeerd wordt gelezen. GHSA-m943-m63m-w62w betreft adresgroepen: een ';' binnen een geciteerde weergavenaam of comment beëindigt de groep te vroeg, waardoor weergavetekst een actief ontvangeradres wordt. GHSA-8c8m-p3m8-cjg8 betreft geneste comments: een genest sluithaakje beëindigt de buitenste comment te vroeg, waardoor tekst die een comment had moeten zijn, als ontvangeradres vrijkomt.

Technische oorzaak

In alle drie de gevallen ontbreekt bij addressparser correcte statusbewaking voor aanhalingsteken-strings, comments en geneste comments tijdens het zoeken naar structurele scheidingstekens. De parser behandelt het eerste voorkomen van een scheidingsteken als betekenisvol, ongeacht de context, terwijl RFC 5322 vereist dat tekens binnen aanhalingstekens of comments (ook geneste) als letterlijke tekst worden behandeld, niet als syntax. Omdat de verkeerd geïnterpreteerde waarden nog altijd syntactisch geldige RFC 5322-adressen zijn, accepteren parsers die de standaard correct implementeren (de adviezen noemen als voorbeeld Python's email._header_value_parser.get_address_list) ze zonder enige melding van een gebrek, terwijl Nodemailer uit dezelfde invoer een ander adres of ontvanger afleidt. De oplossingen voegen expliciete bewaking toe van de status van aanhalingsteken-strings, comments en domain-literals, zodat structurele tekens alleen buiten die status worden gehonoreerd, en er wordt bijgehouden hoe diep comments genest zijn, zodat alleen het buitenste sluithaakje een comment beëindigt.

Waarom dit belangrijk is

Applicaties valideren door gebruikers opgegeven ontvanger- of afzenderadressen vaak met een aparte, standaardconforme parser of een domein-allowlist voordat de waarde aan Nodemailer wordt doorgegeven om te verzenden. Omdat de geprepareerde adressen in deze adviezen geldig zijn volgens RFC 5322, keurt zo'n validatie ze goed. Nodemailer interpreteert dezelfde tekenreeks vervolgens anders en verstuurt het bericht, of bouwt de uitgaande envelop (RCPT TO) op, met een domein of postbus die de header van de applicatie niet bedoelde en die de validatiestap niet heeft opgemerkt. Hierdoor kan een aanvaller een applicatie e-mail laten afleveren — mogelijk met gevoelige inhoud zoals uitnodigingen, meldingen of wachtwoordherstelinformatie — aan een domein of adres van zijn keuze, waarmee de allowlist voor ontvangers van de applicatie wordt omzeild. Aan de inkomende kant kan de losse addressparser-module, zoals gebruikt door mailparser om binnenkomende e-mail te lezen, een andere afzender of ontvanger rapporteren dan een conforme parser uit dezelfde header leest, wat een discrepantie oplevert die bruikbaar is voor afzenderspoofing of misleiding op weergaveniveau.

Wie wordt getroffen

Elke applicatie die door gebruikers beïnvloede e-mailadressen (ontvangerslijsten, afzenderadressen of adresvelden opgebouwd uit gebruikersinvoer) doorgeeft aan Nodemailer voor uitgaande e-mail is getroffen, met name applicaties die domein-allowlists of aparte RFC 5322-validatie gebruiken als beveiligingsgrens. Gebruikers van de losse addressparser-module buiten Nodemailer zelf — de adviezen noemen specifiek mailparser — worden eveneens getroffen bij het verwerken van inkomende e-mailheaders, omdat dezelfde parserlogica wordt gedeeld.

Ontdekking en tijdlijn

Alle drie de problemen zijn gevonden tijdens een interne review van addressparser op 2026-10-18 en geverifieerd tegen Nodemailer-versies 3.0.0, 6.9.16 en 10.1.3. De adviezen merken op dat een van de drie problemen (het geval met geneste comments) structureel verwant is aan een eerder, apart verholpen probleem met een escaped haakje, dat is verholpen in versie 10.1.2, maar hier wordt bereikt via geneste comments in plaats van een quoted-pair. De drie adviezen zijn gepubliceerd op 2026-10-23.

Getroffen versies

Nodemailer-versies 3.0.0 tot en met 10.1.3 zijn getroffen door alle drie de problemen. Versie 10.1.4 bevat oplossingen voor alle drie. Het feitenpakket specificeert niet welke exacte tussenliggende versies tussen 3.0.0 en 10.1.3 afzonderlijk zijn getest, buiten de drie expliciet genoemde geverifieerde versies (3.0.0, 6.9.16 en 10.1.3).

Oplossingen en mitigatie

Nodemailer 10.1.4 verhelpt alle drie de problemen door correcte statusbewaking toe te voegen: aanhalingsteken-strings, comments en domain-literals worden nu bijgehouden binnen een hoekadres, zodat een sluithaakje '>' alleen buiten die status wordt gehonoreerd; aanhalingsteken-strings en comments worden bijgehouden binnen adresgroepen, zodat een puntkomma ';' alleen buiten die status wordt gehonoreerd; en de nestdiepte van comments wordt bijgehouden, zodat alleen het buitenste sluithaakje een comment beëindigt. Applicaties en bibliotheken (waaronder mailparser, dat dezelfde onderliggende parserlogica deelt) die afhankelijk zijn van de adresparsing van Nodemailer, dienen te updaten naar 10.1.4 of nieuwer.

Aanbevolen actie

Update Nodemailer zo snel mogelijk naar versie 10.1.4 of nieuwer. Als uw applicatie domein-allowlists voor ontvangers of andere adresgebaseerde toegangscontroles afdwingt met een aparte validatiebibliotheek, controleer dan na de upgrade opnieuw of die validatielogica overeenkomt met het daadwerkelijke parsegedrag van Nodemailer, aangezien een verschillende interpretatie van hetzelfde adres door beide de kern van dit type probleem is. Als u mailparser of een andere gebruiker van de losse addressparser-module inzet om inkomende e-mail te verwerken, controleer dan of ook deze de bijbehorende fix heeft ontvangen, aangezien dezelfde onderliggende parserlogica wordt getroffen.