GCVE-128-2026-0001 (CVE-2025-68624)

Vulnerability from gna-128 – Published: 2026-08-31 00:00 – Updated: 2026-11-10 00:00 Disputed Exclusively Hosted Service
VLAI
Title
Cross-Tenant Authentication Bypass by Spoofing in N-able Mail Assure
Summary
N-able Mail Assure 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. This GCVE record was published by GNA 128 (bcsec) on 31 August 2026, while CVE-2025-68624 was still in RESERVED state, to make the vulnerability information publicly available and citable in the meantime. The CVE Record was published on 14 September 2026 with the DISPUTED and exclusively-hosted-service tags. 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. UPDATE (10 November 2026): the Supplier stated, through its distributor, that it has developed a change to Mail Assure that validates the MAIL FROM domain against the account submitting the message and rejects attempts to send using a domain belonging to another Mail Assure customer, and on 10 November 2026 that "the enforcement is now active for all Mail Assure customers", with no action required by customers. The Supplier also stated that the change was communicated to customers in a notice sent in September 2026, and that no separate security advisory or release note is planned. The Mail Assure documentation now states that the Enforce Sender Domain setting is mandatory on all accounts. The fix is declared by the Supplier and has not been independently verified by the finders.
Severity
7.0 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N
CWE
  • CWE-290 - Authentication Bypass by Spoofing
Assigner
bcsec GNA GNA-128
GNA scorecard – unranked: 1 record in the last 180 days, 10 needed details
References
Impacted products
Vendor Product Version CPE status
N-able Mail Assure Affected: 0 (custom)
guessed Create a notification for this product.
Credits
Alessandro Bertoldi, Bertoldi Cybersecurity (bcsec.io) Enrico Bertoldi, Bertoldi Cybersecurity (bcsec.io)
Relationships
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "affected",
          "product": "Mail Assure",
          "vendor": "N-able",
          "versions": [
            {
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Alessandro Bertoldi, Bertoldi Cybersecurity (bcsec.io)"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "Enrico Bertoldi, Bertoldi Cybersecurity (bcsec.io)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "N-able Mail Assure 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. This GCVE record was published by GNA 128 (bcsec) on 31 August 2026, while CVE-2025-68624 was still in RESERVED state, to make the vulnerability information publicly available and citable in the meantime. The CVE Record was published on 14 September 2026 with the DISPUTED and exclusively-hosted-service tags. The CVSS 4.0 assessment published in this record uses Attack Requirements: Present (AT:P), applying the Supplier\u0027s 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\u0027 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\u0027s 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. UPDATE (10 November 2026): the Supplier stated, through its distributor, that it has developed a change to Mail Assure that validates the MAIL FROM domain against the account submitting the message and rejects attempts to send using a domain belonging to another Mail Assure customer, and on 10 November 2026 that \"the enforcement is now active for all Mail Assure customers\", with no action required by customers. The Supplier also stated that the change was communicated to customers in a notice sent in September 2026, and that no separate security advisory or release note is planned. The Mail Assure documentation now states that the Enforce Sender Domain setting is mandatory on all accounts. The fix is declared by the Supplier and has not been independently verified by the finders."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.0,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290 Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "orgId": "f067779a-4f52-4938-9371-21316297cc51",
        "shortName": "bcsec"
      },
      "references": [
        {
          "name": "bcsec security advisories",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://bcsec.io/advisories.php"
        },
        {
          "name": "Full Disclosure advisory, 15 June 2026",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jun/10"
        },
        {
          "name": "Public reference advisory, 6 May 2026",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://gist.github.com/alessandrobertoldi/1ebe0f48aa0119d787ac0ff710057d92"
        },
        {
          "name": "DeepSec Vienna 2025 presentation",
          "tags": [
            "media-coverage"
          ],
          "url": "https://deepsec.net/archive/2025.deepsec.net/speaker.html#PSLOT782"
        },
        {
          "name": "bcsec vulnerability disclosure policy",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://bcsec.io/vulnerability-disclosure-policy.html"
        },
        {
          "name": "N-able Mail Assure documentation, Configuration tab (Enforce Sender Domain: mandatory on all accounts)",
          "tags": [
            "product"
          ],
          "url": "https://documentation.n-able.com/mail-assure/userguide/Content/C_Domain%20Level/domains/configuration.htm"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "value": "The Supplier declared on 10 November 2026 that a domain-to-account binding at message submission is now enforced for all Mail Assure customers: the MAIL FROM domain is validated against the authenticated account, and domains belonging to other Mail Assure customers are rejected. No action is required by customers, according to the Supplier. This fix is declared by the Supplier and has not been independently verified by the finders."
        }
      ],
      "source": {
        "discovery": "USER"
      },
      "tags": [
        "disputed",
        "exclusively-hosted-service"
      ],
      "timeline": [
        {
          "lang": "en",
          "time": "2025-08-26T00:00:00.000Z",
          "value": "Reported to N-able PSIRT (ticket REQ 6678)."
        },
        {
          "lang": "en",
          "time": "2025-11-21T13:00:00.000Z",
          "value": "Research publicly presented at DeepSec Vienna 2025, 21 November 2025 at 14:00 local time, in the talk \"Infinity Day at Scale: Hijacking Registrars, Defeating 2FA and Spoofing 17,000+ Domains Even with DMARC\" by Alessandro Bertoldi (Bertoldi Cybersecurity / Independent Security Researcher)."
        },
        {
          "lang": "en",
          "time": "2025-12-09T00:00:00.000Z",
          "value": "CVE ID request submitted to MITRE (CVE service request 1964945)."
        },
        {
          "lang": "en",
          "time": "2026-01-27T00:00:00.000Z",
          "value": "The CVE Program initiated the CVE Record Dispute Policy procedure and asked the N-able CNA for its rationale for not assigning a CVE ID, under CVE Program Rules 4.1."
        },
        {
          "lang": "en",
          "time": "2026-01-30T00:00:00.000Z",
          "value": "N-able declined to assign a CVE ID, stating that the reported behaviour is intended functionality of its shared SMTP relay service."
        },
        {
          "lang": "en",
          "time": "2026-05-05T00:00:00.000Z",
          "value": "MITRE TL-Root determination: the issue meets the criteria for CVE assignment; the MITRE CNA-LR is instructed to assign and publish CVE-2025-68624 with the DISPUTED tag. The determination states that the CVE Team still needs a publicly available reference URL before publishing the record."
        },
        {
          "lang": "en",
          "time": "2026-05-06T00:00:00.000Z",
          "value": "First public reference provided to the CVE Team (GitHub Gist), the day after the determination."
        },
        {
          "lang": "en",
          "time": "2026-06-15T00:00:00.000Z",
          "value": "Advisory published on the Full Disclosure mailing list, one of the hosting resources named as acceptable in the determination of 5 May 2026."
        },
        {
          "lang": "en",
          "time": "2026-07-07T00:00:00.000Z",
          "value": "CVE service request 1964945 was closed by the CVE Team for lack of a response, with an invitation to submit a notification of CVE publication request together with the reference URL."
        },
        {
          "lang": "en",
          "time": "2026-08-31T00:00:00.000Z",
          "value": "CVE-2025-68624 still in RESERVED state and no CVE Record published; this GCVE record published by GNA 128 (bcsec)."
        },
        {
          "lang": "en",
          "time": "2026-09-14T00:00:00.000Z",
          "value": "CVE-2025-68624 published by the MITRE CNA-LR with the DISPUTED and exclusively-hosted-service tags. The CVE Record carries a CVSS 3.1 base score of 4.3 (Medium); the CVSS 4.0 assessment of 7.0 (High) in this record is unchanged."
        },
        {
          "lang": "en",
          "time": "2026-10-27T00:00:00.000Z",
          "value": "Status request sent to N-able PSIRT on the original thread (REQ 6678); only an automatic reply was received. The request was then pursued through the N-able distributor."
        },
        {
          "lang": "en",
          "time": "2026-11-06T00:00:00.000Z",
          "value": "The Supplier stated, through its distributor, that it has developed a change validating the MAIL FROM domain against the submitting account and rejecting domains of other Mail Assure customers, to be enabled from November 2026."
        },
        {
          "lang": "en",
          "time": "2026-11-10T00:00:00.000Z",
          "value": "The Supplier stated, through its distributor, that the enforcement is active for all Mail Assure customers. Fix declared by the Supplier, not independently verified by the finders."
        }
      ],
      "title": "Cross-Tenant Authentication Bypass by Spoofing in N-able Mail Assure",
      "workarounds": [
        {
          "lang": "en",
          "value": "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\u0027s 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\u0027s 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."
        }
      ],
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [
            {
              "destId": "GCVE-0-2025-68624",
              "type": "equal"
            },
            {
              "destId": "CVE-2025-68624",
              "type": "equal"
            }
          ],
          "vulnId": "GCVE-128-2026-0001"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f067779a-4f52-4938-9371-21316297cc51",
    "assignerShortName": "bcsec",
    "cveId": "CVE-2025-68624",
    "datePublished": "2026-08-31T00:00:00.000Z",
    "dateReserved": "2025-12-19T00:00:00.000Z",
    "dateUpdated": "2026-11-10T00:00:00.000Z",
    "serial": 1,
    "state": "PUBLISHED",
    "vulnId": "GCVE-128-2026-0001"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.