Description

N-able Mail Assure through April 2026 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. NOTE: N-able's position is that the behavior is intended functionality of its shared SMTP relay architecture and that the service does not represent that it enforces per-tenant sender-domain binding.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-14T01:16:27.220Z",
  "pubdate": "2026-09-14T01:16:27.220Z",
  "executiveSummary": "N-able Mail Assure contains a design-level authorization vulnerability that permits authenticated SMTP users to perform cross-tenant sender impersonation. The vulnerability stems from a lack of mandatory domain-to-account binding within the SMTP relay architecture, allowing an attacker to utilize any sender domain in the MAIL FROM command while authenticated with valid tenant credentials.\nThe primary impact of this flaw is the potential for successful business email compromise (BEC), phishing, and spoofing attacks that originate from a trusted mail relay. Because the service does not enforce sender domain ownership constraints, outbound messages can be crafted to pass SPF and DMARC validation, effectively bypassing email authentication mechanisms. This vulnerability affects N-able Mail Assure through April 2026. While N-able characterizes this as intended functionality, the security implications are significant, as it enables authenticated users—including malicious actors who have compromised a legitimate tenant account—to masquerade as entities from other, unauthorized tenants. The risk is elevated by the high deliverability reputation inherent in established SMTP relay platforms.",
  "technicalDetails": "The root cause of this vulnerability is the absence of an authorization check at the SMTP submission layer to correlate the authenticated session identity with the permitted sender domains (MAIL FROM) defined in the tenant's configuration. In a secure multi-tenant SMTP relay, the system should validate that the authenticated entity possesses sufficient authorization to send mail on behalf of the domain specified in the MAIL FROM address. Within N-able Mail Assure, the relay architecture accepts any syntactically valid domain without performing a binding verification against the account credentials provided during the SMTP AUTH exchange.\nThe attack flow follows a predictable sequence: First, the attacker establishes a TCP connection to the Mail Assure SMTP submission port. Second, the attacker performs a standard SMTP AUTH sequence using valid credentials belonging to any tenant within the system. Third, upon successful authentication, the attacker initiates a mail transaction. Fourth, the attacker provides a MAIL FROM command specifying a target domain belonging to a different, victim tenant. Finally, the attacker completes the RCPT TO and DATA phases of the SMTP transaction.\nBecause the relay is part of the infrastructure trusted by the victim domain (as defined in their SPF records), the outbound email successfully passes SPF checks. Furthermore, because the relay handles the signing or alignment, the spoofed message can satisfy DMARC requirements, appearing as a legitimate communication from the impersonated entity. This bypass effectively defeats anti-spoofing controls that rely on domain-level authentication.\nThe technical requirements for exploitation include authenticated access to a valid N-able Mail Assure account. No special privileges are required beyond basic tenant access. The vulnerability is network-exposed via the service's SMTP submission interface. Post-exploitation impact includes the ability to conduct highly convincing phishing campaigns, distribute malware with high deliverability, and engage in corporate espionage or financial fraud under the guise of the impersonated tenant's identity. As the service provider categorizes this as architectural design, no standard software patch is expected to enforce strict tenant-to-domain binding at the protocol level."
}