CVE-2025-68624 jest ciekawsze od wielu „Critical 9.8”, bo spór nie dotyczy severity — strony nie zgadzają się, czy zachowanie w ogóle narusza granicę bezpieczeństwa. Badacz opisuje scenariusz, w którym uwierzytelniony użytkownik SMTP jednego tenanta może użyć w MAIL FROM domeny innego tenanta, a wiadomość może przejść SPF i DMARC, bo domena autoryzuje infrastrukturę Mail Assure jako nadawcę. N-able kwestionuje kwalifikację jako vulnerability: to element zamierzonego modelu shared SMTP relay, a usługa nie obiecuje per-tenant sender-domain binding. MITRE po procesie spornym przypisał CVE, ale oznaczył je jako DISPUTED.
authenticated account → authorized sender domains.Dlaczego SPF i DMARC nie rozwiązują tego automatycznie
SPF odpowiada „czy ten serwer może wysyłać dla tej domeny?” — jeśli właściciel domeny świadomie autoryzuje Mail Assure, odpowiedź brzmi „tak”. DMARC dodaje alignment między From a domeną uwierzytelnioną SPF/DKIM. Ale jeśli wspólna infrastruktura może wygenerować wiadomość z odpowiednio ustawioną tożsamością domeny, mechanizmy antyspoofingowe mogą nie odróżnić legalnej wiadomości Tenant B od wiadomości Tenant A używającej domeny Tenant B w obrębie tej samej platformy. Bezpieczeństwo multi-tenant SaaS nie może więc opierać się wyłącznie na tym, że wspólna infrastruktura jest „trusted by DNS”.
DISPUTED ≠ ignorować
DISPUTED nie oznacza „false positive” — oznacza istotny spór co do klasyfikacji. VE rozdziela trzy pytania: (1) czy zachowanie jest reprodukowalne (techniczne); (2) czy narusza security contract produktu (dokumentacja, oczekiwania, architektura, gwarancje vendora); (3) czy tworzy ryzyko dla naszej organizacji (lokalne). Nawet jeśli vendor uważa funkcję za „by design”, klient może uznać ją za nieakceptowalną dla swojego modelu zagrożeń. To pozorny paradoks: zachowanie może być „not a vulnerability” i jednocześnie realnym ryzykiem — jeśli organizacja regulowana ma politykę „żaden tenant nie może użyć domeny innego tenanta do wiadomości przechodzącej DMARC”, ten sam fakt techniczny staje się architektonicznym ryzykiem. To różnica między vulnerability taxonomy a security requirement.
Zapis, weryfikacja, remediation
Dojrzały system VM zapisuje nie CVE-2025-68624 = vulnerable, lecz: status CVE (DISPUTED), researcher claim, vendor claim, reproduction status, tenant configuration, SPF/DMARC setup, security requirement (czy per-tenant sender-domain isolation jest wymagana), local risk decision (accept/mitigate/escalate). Weryfikacja bezpiecznie: nie testuj spoofingu na cudzych domenach — w kontrolowanym środowisku z dwiema własnymi domenami/tenantami uwierzytelnij się jako Tenant A, spróbuj wysłać z envelope sender domeny Tenant B, sprawdź Authentication-Results, SPF, DKIM/alignment, DMARC, zachowaj nagłówki. Remediation (jeśli vendor nie uznaje problemu) zależy od wymagań: osobny relay dla domen o wysokiej wartości, dodatkowe kontrole nadawcy, ograniczenie poświadczeń SMTP, monitoring nietypowych MAIL FROM, reguły BEC, ewentualnie alternatywna usługa albo formalne risk acceptance. Nie wymyślaj fixed version, jeśli vendor nie publikuje poprawki. Active exploitation: publiczne disclosure ≠ obserwowana kampania — pola: public reproduction tak, CVE assigned tak, disputed tak, vendor-confirmed vulnerability nie, exploitation in the wild brak dowodu.
Powiązane na blogu
- SuperTokens: granica tenantów — cross-tenant jako security requirement
- Redis: provenance CVSS — kto policzył i co dokładnie twierdzi rekord
Źródła
- Researcher disclosure — gist.github.com
- CVE-2025-68624 — cve.org
Nota redakcyjna: stan informacji 14 września 2026. CVE-2025-68624 (N-able Mail Assure) ma status DISPUTED — researcher opisuje cross-tenant sender-domain use, vendor traktuje to jako intended shared-relay model. Brak potwierdzenia exploitation in the wild. Artykuł omawia data provenance i security-contract engineering; nie sugeruje testów na cudzych domenach.