bcsec publishes vulnerability records as GCVE Numbering Authority 128. Records are issued in GCVE-BCP-05 format and served from https://bcsec.io/dumps/gna-128.ndjson, the endpoint declared in the GCVE directory. This page is generated from that same source, so it always reflects what we publish.
Our handling of vulnerabilities, including notification and disclosure timelines, is described in our Vulnerability Disclosure Policy.
| Identifier | Product | Weakness | Severity | Published |
|---|---|---|---|---|
| GCVE-128-2026-0001 CVE-2025-68624 |
N-able Mail Assure | CWE-290 | 7 HIGH | 31 August 2026 |
N-able Mail Assure through 2025-12-09 contains a design-level authorization flaw that allows an authenticated SMTP user to send outbound email using MAIL FROM addresses belonging to other tenants. When connecting to the SMTP TCP port and performing SMTP AUTH with valid credentials, the server accepts arbitrary sender domains without enforcing any domain-to-account binding. As a result, an attacker from any tenant can impersonate other tenant domains, producing messages that pass SPF and DMARC validation, including strict p=reject policies. NOTE: the Supplier disputes this, stating that the reported behavior is intended functionality of its shared SMTP relay service. On 5 May 2026 the MITRE TL-Root, acting as adjudicator under the CVE Record Dispute Policy, determined that the issue meets the criteria for CVE assignment and instructed the MITRE CNA-LR to assign and publish CVE-2025-68624 with the DISPUTED tag. As of the publication date of this GCVE record, CVE-2025-68624 remains in RESERVED state and no CVE Record has been published. This GCVE record is published by GNA 128 (bcsec) to make the vulnerability information publicly available and citable in the meantime. The CVSS 4.0 assessment published in this record uses Attack Requirements: Present (AT:P), applying the Supplier's own stated precondition that the impersonated domain must be an independently onboarded and DNS-verified customer of the platform. That precondition is trivially satisfied in practice, because platform customers can be enumerated from public DNS records. Privileges Required is Low, since valid credentials for any tenant on the shared relay are sufficient. The integrity impact is rated High on both the vulnerable system and the subsequent system, because the sender identity asserted by the relay can be forged at will and the resulting message passes SPF and DMARC validation at the receiving side. Discovery and verification: the finders are customers of the platform and hold a legitimate tenant, and the issue was identified in the course of using the product. Third-party tenants were identified from public DNS records showing that their mail is routed through the platform. Using the finders' own authenticated tenant credentials, test messages were submitted with MAIL FROM addresses belonging to those third-party domains and were delivered to a mailbox hosted on an unrelated provider (Microsoft 365), where they passed SPF and DMARC evaluation at the receiving side. Mail Assure is a hosted multi-tenant service without customer-visible version numbering, so no fixed version boundary can be stated. No further verification testing was carried out after 29 April 2026, when the Supplier confirmed in the dispute correspondence that an authenticated user of one tenant can submit mail using a MAIL FROM address belonging to another tenant's verified domain, and stated that this is intended functionality. The behaviour itself is therefore not in dispute between the parties, only its classification, and on that basis all versions of the service are recorded as affected with no fix known as of the publication date of this record.
Enforce a domain-to-account binding at message submission: restrict the domains usable in the SMTP MAIL FROM to those associated with the authenticated account, instead of accepting any domain that is active on the shared platform. This is a change that only the Supplier can make.
No effective mitigation is available to the domain owner. Hardening DMARC does not help: under RFC 7489 a message passes DMARC when at least one of SPF or DKIM passes with identifier alignment, and the shared relay IP ranges remain authorised in the domain owner's SPF record, so a message submitted from inside the platform still achieves SPF alignment. This was tested by the finders, including DKIM signing performed on the domain owner's own infrastructure rather than on the platform, and with a DMARC policy set to adkim=s: the domain remained spoofable. The exposure is therefore removed only by the Supplier-side change described in the solution.
Send reports to [email protected]. We respond within ten working days. Please read our Vulnerability Disclosure Policy first.