https://vulnerability.circl.lu/sightings/feed 2026-05-06T16:17:44.357030+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/88ebfd9a-7f35-4ba3-a542-36b971a0f6fc/export 2026-05-06T16:17:44.931845+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "88ebfd9a-7f35-4ba3-a542-36b971a0f6fc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68624", "type": "seen", "source": "https://gist.github.com/alessandrobertoldi/1ebe0f48aa0119d787ac0ff710057d92", "content": "# CVE-2025-68624 \u2014 Cross-Tenant Authentication Bypass by Spoofing in N-able Mail Assure\n\n**CVE ID:** CVE-2025-68624\n**Status:** DISPUTED\n**CWE:** CWE-290 \u2014 Authentication Bypass by Spoofing\n**Affected Product:** N-able Mail Assure, formerly SolarWinds MSP Mail Assure\n**Affected Service:** N-able Mail Assure cloud-based multi-tenant SMTP relay infrastructure\n**Vendor:** N-able Technologies\n**Initial Discovery:** October 2018\n**Public Disclosure:** November 2025 \u2014 DeepSec Vienna 2025\n**CVE Assignment:** May 2026, following MITRE TL-Root dispute review\n\n---\n\n## Description\n\nN-able Mail Assure contains a design-level authorization flaw that allows an\nauthenticated SMTP user from one tenant to submit outbound email using sender\naddresses belonging to other unrelated tenants hosted on the same platform.\n\nWhen connecting to the N-able Mail Assure SMTP relay and authenticating with\nvalid credentials, the service accepts sender domains that are not bound to,\ndelegated to, or otherwise authorized for the authenticated account. As a\nresult, an authenticated user from Tenant A can submit email using a sender\naddress belonging to Tenant B, despite there being no administrative\nrelationship, consent, or delegation between the two tenants.\n\nIn the observed tests, the SMTP relay verified that the user had valid\ncredentials, but did not verify that the authenticated identity was authorized\nto submit mail for the claimed sender domain.\n\nWhere the claimed sender domain authorizes the Mail Assure relay infrastructure\nin SPF and the message uses an aligned RFC5322.From domain, the resulting\nmessage can pass SPF and DMARC validation at the receiving MTA, including for\ndomains configured with strict DMARC enforcement.\n\nThe root cause is a missing sender-domain authorization check at SMTP\nsubmission time.\n\n---\n\n## Impact\n\nAn authenticated Mail Assure user may be able to impersonate other domains\nhosted on the Mail Assure platform.\n\nIn the observed test case, this produced messages that:\n\n- Passed SPF validation at the receiving MTA\n- Passed DMARC validation\n- Appeared as authenticated mail to the recipient environment\n- Bypassed the protection expected from strict DMARC policies\n\nThis issue may enable phishing, Business Email Compromise (BEC), vendor\nimpersonation, and other social engineering attacks against organizations\nthat believe their domains are protected by correctly configured SPF and\nDMARC policies.\n\nA March 2025 analysis documented in the accompanying technical paper\nidentified approximately 17,000 domains relying on the Mail Assure platform.\n\n---\n\n## Proof of Concept Summary\n\nThe issue was validated using legitimate Mail Assure credentials from a tenant\ncontrolled by the researchers.\n\nA controlled test showed that an authenticated account belonging to one Mail\nAssure tenant could submit an outbound message using a sender address belonging\nto a different, unaffiliated Mail Assure tenant domain.\n\nObserved result:\n\n- Authentication: valid credentials from Tenant A\n- Claimed sender domain: Tenant B, unaffiliated with Tenant A\n- SMTP result: message accepted for delivery\n- Recipient environment: Microsoft 365\n- Authentication result: SPF PASS and DMARC PASS\n- Target domain policy: strict DMARC enforcement\n\nFull SMTP session transcript, screenshots, and supporting evidence are\ndocumented in the technical paper (pages 33-36).\n\nNo credentials, tokens, private user data, or mailbox contents are published\nin this advisory. No harm was caused to any third-party domain or its users.\n\n---\n\n## Disclosure Timeline\n\n| Date | Event |\n|------|-------|\n| October 2018 | Vulnerability discovered during a penetration test and reported to SolarWinds security contacts, including VP Security Timothy Brown and the PSIRT team. |\n| 2018-2024 | Issue remained unresolved despite prior notification. |\n| March 2025 | Retest performed and issue confirmed as still exploitable. |\n| November 2025 | Public disclosure presented at DeepSec Vienna 2025. |\n| December 2025 | CVE request submitted to MITRE under Service Request #1964945. |\n| January 2026 | N-able PSIRT contacted during the CVE request process. N-able disputed the vulnerability classification. |\n| January-April 2026 | CVE dispute process conducted by MITRE TL-Root. |\n| April 2026 | N-able confirmed the cross-tenant sender behavior in correspondence with MITRE TL-Root. |\n| May 2026 | MITRE TL-Root determined that the issue meets CVE assignment criteria. CVE-2025-68624 assigned with the DISPUTED tag. |\n\n---\n\n## Vendor Response\n\nN-able disputes that the reported behavior constitutes a security vulnerability.\n\nN-able's position is that the behavior is intended functionality of its shared\nSMTP relay architecture and that the service does not represent that it\nenforces per-tenant sender-domain binding.\n\nThe CVE record is published with the DISPUTED tag to reflect the vendor's\nposition.\n\n---\n\n## Recommended Mitigation\n\nThe SMTP relay should enforce sender-domain authorization at submission time.\n\nRecommended controls include:\n\n- Bind authenticated accounts to the domains they are authorized to send from\n- Reject outbound messages where the authenticated identity is not authorized\n for the claimed MAIL FROM and RFC5322.From domains\n- Require explicit delegation before allowing cross-domain sending\n- Log and alert on attempted unauthorized cross-tenant sender-domain usage\n- Provide tenant administrators with visibility into authorized sender domains\n and attempted violations\n\n---\n\n## References\n\n- Technical paper \u2014 DeepSec Vienna 2025 \u2014 Infinity-Day at Scale: Hijacking\n Registrars, Defeating 2FA and Spoofing 17,000+ Domains:\n https://github.com/alessandrobertoldi/research/blob/main/infinity-day-at-scale-deepsec2025.pdf\n- N-able Mail Assure product page:\n https://www.n-able.com/products/mail-assure\n- CVE record:\n https://www.cve.org/CVERecord?id=CVE-2025-68624\n\n---\n\n## Credits\n\nDiscovered and reported by:\n\nAlessandro Bertoldi\nBertoldi Cybersecurity\nhttps://bcsec.io/eng.html\nhttps://linkedin.com/in/bertoldicybersecurity\n\nCo-author:\n\nEnrico Bertoldi\nBertoldi Cybersecurity\n\nOriginal 2018 disclosure:\n\nBertoldi Cybersecurity Team", "creation_timestamp": "2026-05-06T13:36:50.000000Z"} 2026-05-06T13:36:50+00:00