CVE-2026-100701 pokazuje nietypową klasę błędu: problem nie musi polegać na braku TLS, lecz na błędnym związaniu parametrów TLS z hostem, gdy stan DNS/cache jest współdzielony pomiędzy transportami. To case o state provenance — poprawny parametr użyty w złym kontekście.
tls.servername między transportami → parametry TLS wiążą się z niewłaściwym hostem.resolved destination + tls.servername + certificate validation muszą dotyczyć tego samego logicznego hosta.Security invariant i provenance
Jeżeli cache przenosi servername pomiędzy transportami, można uzyskać stan, w którym mechanizmy osobno wyglądają poprawnie, ale ich provenance jest błędne — handshake używa SNI z poprzedniego hosta. To ta sama rodzina „name/route mismatch” co w Nodemailer CVE-2026-92598 (IDN) i DBHub (DNS rebinding): kontrola i faktyczna dostawa muszą operować na tym samym obiekcie.
Asset context i verification
Najważniejsze pytania: czy proces tworzy wiele transportów/tenantów, czy cache DNS jest współdzielony, czy hosty mają różne SNI/certyfikaty, czy credentiale SMTP różnią się między tenantami i czy transport jest długo żyjący. Test powinien używać co najmniej dwóch hostów i naprzemiennych połączeń oraz potwierdzić, że każdy handshake używa SNI odpowiadającego aktualnemu hostowi — niezależnie od wcześniejszych wpisów cache. Jeśli błędne związanie mogło skierować credentiale do niewłaściwego endpointu, oceń logi i rozważ rotację poświadczeń SMTP/API (bez zakładania kradzieży bez dowodów).
Powiązane na blogu
- Nodemailer CVE-2026-92598 — inny finding w tej samej bibliotece
- DBHub MCP: DNS rebinding — nazwa vs faktyczny cel
Źródło
- Nodemailer — Security advisories (CVE-2026-100701) — github.com
Nota redakcyjna: stan informacji 29 września 2026. CVE-2026-100701 (Nodemailer, błędne związanie tls.servername przy współdzielonym DNS cache). Ekspozycja zależy od wielotransportowego/wielotenantowego użycia. Brak potwierdzenia active exploitation.