ZDI discloses four SmarterMail flaws, including authentication bypass
News
Published 14 Nov 2026
Updated 14 Nov 2026
7 min read
Summarize with
Zero Day Initiative (ZDI) publicly disclosed four vulnerabilities in SmarterTools SmarterMail on November 13, 2026, including a CVSS 9.1 authentication bypass involving generated Application Passwords. The other flaws involve authenticated code execution, privilege escalation and attachment-related information disclosure. ZDI credits researcher Shaber Tseng and identifies Build 9735 as the fixed build for all four.
The fixes were already available in August. SmarterTools published its Build 9735 notice on August 27, 2026. The November event is ZDI's coordinated public disclosure, not a new patch release. Administrators should verify that their currently supported release incorporates the fixes and should not downgrade to this historical build.
Four disclosures, with fixes already available
All four official ZDI timelines give the same two dates: the vulnerabilities were reported to SmarterTools on August 20, 2026, and the coordinated public advisories were released on November 13. The August 27 vendor release falls between those events. That chronology matters when checking whether an installation was updated before the technical details became public.
The disclosures are relevant to self-hosted mail administrators, hosting operators and MSPs responsible for affected SmarterMail installations. They describe different security failures with different access requirements. Only the Application Password vulnerability is described as unauthenticated; the other three require authentication.
|
|
|
|
|---|---|---|---|
CVE-2026-126969 | 9.1 | No credentials | Authentication bypass |
CVE-2026-126967 | 8.8 | Authenticated | Code execution |
CVE-2026-126966 | 8.8 | Authenticated | Privilege escalation |
CVE-2026-126968 | 6.5 | Authenticated | Information disclosure |
ZDI identifies SmarterMail Build 9735 as the fix for each vulnerability.
ZDI does not supply a comprehensive affected-version range. Its fixed-build statements do not establish that every earlier build, platform or edition is affected. I would record the installed build and the evidence that its release includes these fixes, rather than infer exposure solely from a build number.
What each vulnerability allows
CVE-2026-126969 has a CVSS score of 9.1. ZDI attributes the authentication bypass to insufficient entropy in generated Application Passwords, meaning the generated credentials lack adequate unpredictability. The advisory describes network exploitation without existing credentials or user interaction. It does not establish that the bypass grants administrative access.
CVE-2026-126967 has a CVSS score of 8.8 and requires authentication. The flaw is in FileStorageController, where a user-supplied path is insufficiently checked before file operations. ZDI says exploitation permits code execution in the SYSTEM security context. That is the code-execution finding; it should not be relabeled as an unauthenticated vulnerability.
CVE-2026-126966 also scores 8.8 and requires authentication. ZDI identifies missing authorization in the svcDomainAdmin.asmx endpoint. An authenticated user can gain access to resources that should be protected from that user. The distinction is between signing in and having permission to use particular functionality.
CVE-2026-126968 scores 6.5 and requires authentication. Missing authorization in email attachment handling can expose sensitive information associated with a target user. This is a disclosed information-access weakness, not a report that specific attachments or mailboxes were stolen.
Separate findings, not a demonstrated chain
The four advisories do not demonstrate an exploit chain connecting the authentication bypass to SYSTEM-level code execution. They also do not establish observed exploitation, victim counts or a zero-day campaign. Exploitation status is not established by these advisories.
Check builds and plan the client changes
Build 9735 is the fixed build named by ZDI, not the latest release or a November release. The operational task is to confirm the fixes are present in the software actually running. For a hosted deployment, ask the operator for the deployed build and remediation confirmation rather than assume a scheduled maintenance window completed successfully.
SmarterTools' 2026 release notes date Build 9735 to August 27 and say App Passwords were regenerated under a changed security scheme. Users of older App Passwords must enter new ones in desktop or mobile clients for 2FA-enabled accounts. The August release notice also flags this client impact.
Preserve two-factor authentication
Plan client reconfiguration alongside the supported upgrade. Keep 2FA enabled and explain how users obtain and enter their replacement App Passwords. Disabling MFA is not a remediation for these vulnerabilities.
My upgrade checklist would include both server verification and the help desk work needed to restore client access:
- Inventory. Record deployed builds across production servers and managed customer installations. Identify the owner of each upgrade and any dependencies that affect the maintenance window.
- Verify. Use official release information and upgrade guidance to confirm the chosen supported release incorporates the fixes. Document the target build, backup arrangements and recovery plan.
- Prepare clients. Notify users whose clients rely on App Passwords about the required re-entry. Prepare support instructions without collecting their replacement secrets in tickets.
- Validate. After maintenance, verify the running build and test normal sign-in, client synchronization and mail delivery. Record completion for each installation rather than close a fleet-wide task on assumption.
Client testing should cover the protocols and devices the organization actually uses. A successful webmail sign-in does not prove every desktop client has accepted its replacement App Password. Give users a clear support route for authentication failures during the change, and distinguish expected configuration problems from unexplained account activity. Ask users to report the client and protocol involved when seeking help, so support can reproduce the problem accurately.
If an upgrade cannot be completed immediately, document the reason and review exposure with the responsible security team. Temporary access restrictions require deployment-specific assessment and do not prove the underlying flaws are fixed. The cited disclosures do not announce a government remediation deadline.
Review evidence without assuming compromise
An installation that needs remediation also needs an evidence review, but a vulnerability disclosure is not an incident finding. Review existing authentication and administrator logs alongside available mailbox-access records. Look for activity inconsistent with the account's expected use, unexpected administrative changes or access patterns that warrant investigation.
These are general defensive checks, not indicators published by ZDI for this disclosure. Preserve relevant records before routine retention removes them, and correlate suspicious events with maintenance activity and user reports. A failed client login after an App Password change has a different explanation from unexplained successful access.
Choose the review period using the installation's upgrade history and available retention. November 13 records when ZDI published the advisories; it does not identify when a particular server became vulnerable or when unauthorized access occurred. Preserve original timestamps and document any timezone conversions so events can be compared consistently. Gaps in retained logs also belong in the investigation record.
For MSPs, keep each customer's findings tied to that customer's server and maintenance history. A shared software version does not establish a shared incident. If evidence suggests unauthorized access, use incident response to determine scope, preserve evidence and decide on credential or session remediation. Installing a fixed release alone does not resolve an established compromise.
Why DMARC has a separate role
These findings concern mailbox and server authentication or authorization. They are not SPF, DKIM or DMARC protocol bypasses. Changing DNS records does not repair weak Application Password generation, unsafe file-path handling or missing permission checks in the mail server.
The distinction matters during validation. A message can pass domain authentication while the server that sent it still needs a security update. Conversely, an authentication failure in a mail report does not establish exploitation of one of these CVEs.
Server security
Software updates correct the disclosed implementation flaws. Access controls and server evidence help administrators assess use of accounts and protected resources.
Domain authentication
SPF checks sending authorization, DKIM verifies signatures, and DMARC relates authentication to the visible From domain and publishes handling policy. These controls do not validate server patch status.
Unauthorized mail sending and damage to sender reputation are general risks of mail-system compromise, not observed consequences established by these advisories. A clean DMARC report cannot rule out mailbox access or attachment disclosure.
Suped's DMARC monitoring helps review reported sending sources and authentication failures alongside the server investigation. After remediation, a legitimate message sent to Suped's email tester can check receiver-side authentication results. Neither workflow certifies that a SmarterMail installation is patched or uncompromised.
Close the change with evidence
For administrators, the useful outcome is a verified supported build with the disclosed fixes, working clients after the App Password changes, and a documented review of suspicious activity. Keep that evidence with the maintenance record. Escalate actual signs of unauthorized access through incident response, and keep the November disclosure date separate from the August fix date when communicating with customers.
Frequency asked questions
No. SmarterTools released Build 9735 on August 27, 2026. November 13 is the coordinated public release date of the four ZDI advisories. Use a currently supported release incorporating the fixes; do not downgrade to the historical fixed build.
No. CVE-2026-126969 is the unauthenticated authentication bypass. The code-execution, privilege-escalation and attachment information-disclosure findings each require authentication. ZDI does not demonstrate a combined unauthenticated code-execution chain.
No. These advisories do not establish exploitation status, stolen mail or victim counts. Assess an installation using its own evidence and investigate suspicious activity through incident response.
Build 9735 regenerated App Passwords using a changed security scheme. Users relying on older App Passwords for 2FA-enabled desktop or mobile access need to enter replacement values. Preserve 2FA while reconfiguring clients.
No comprehensive affected-version range is given. Build 9735 is the fixed build ZDI names for all four flaws. Confirm applicability and fix status for the deployed installation through official release information and vendor guidance.
