Security
Each of these was found by the project's own review, and each is fixed in 6.3.7, unless it says otherwise. Among them are a way for any account that could sign in to a Windows computer to replace the programs of an hMailServer installed at the root of a drive, the DKIM signing of mail from outside in a hosted domain's name, and any sender's way past the rule loop limit. The Security section of CHANGELOG.md at the tag says what changed, and the work items it names give the details; several identifiers were still requested when 6.3.7 was published. Upgrade every server running 6.3.6 or earlier.
- CVE-2026-107571 (work item 78): on Windows, where hMailServer was installed in a folder that took its permissions from the root of a drive, any account that could sign in to the computer could replace the programs the service runs; every version from 6.0.0 to 6.3.6. The default folder under Program Files was never affected.
hMailServer.exe /ProtectFolders, which setup runs at every installation and upgrade, now hardens the program folder, Bin and ControlPanel. Four narrower cases are not fixed in 6.3.7 (Known issues, below). - CVE-2026-107567 (work item 84): mail from outside whose From named a domain hosted here was signed with that domain's DKIM key, and so was every forward and copy of it, so that it passed DMARC for that domain elsewhere; and an authenticated submission was signed as whatever hosted domain its From named, which 6.3.7 does only where the account may send as that address; every version from 6.0.0 to 6.3.6 that signs. An upgrade stops the signing; only rotating a domain's key ends the signatures already made.
- CVE requested (work items 90 and 91): a forward, a redirect, a list's copy or an alias's copy of mail from outside, a forward of a message downloaded from an external account among them, was given an envelope sender, or for a null one was sent under a host name, in the organisation of a domain its From names, so that it could pass that domain's DMARC policy through SPF; every version from 6.0.0 to 6.3.6. 6.3.7 does so only when the message passed DMARC for it on arrival.
- CVE-2026-107568 (work item 82): an account's Sieve notify was sent from whatever its :from said, and signed as that address's domain where the server signs for it; 6.2.22 to 6.3.6.
- CVE-2026-107566 (work item 83): an account's Sieve editheader could rewrite From, Sender or DKIM-Signature ahead of a redirect, which the server then sent and signed in that name; 6.2.22 to 6.3.6. A domain's or an account's rule had the same gap, in every version (a Reply from an address its owner may not send as, a Set header value of From, Sender, the Resent- pair or DKIM-Signature), and is held the same way, under work items 82 and 83.
- CVE-2026-107569 (work item 81): any sender could lift the rule loop limit off a message, an account's own Sieve script or rule could reset it, and a Sieve notify did not consult it, so that a loop of generated mail could run without bound; every version from 6.0.0 to 6.3.6.
- CVE requested (work item 86): on a server with several tenants, a credential confined to named domains (a domain administrator, an account or API key given another role that manages accounts in named domains, or a full-scope API key issued for named domains) could rename a domain, create a domain alias, set on a domain's or an account's rule an action that reaches the server's own addresses, a configured route's stored credentials or a function of the event script, and point its domain's relay host at the server's own network, over the REST and the COM APIs; every version from 6.0.0 to 6.3.6.
- CVE requested (work item 89): such a credential, a full-scope API key issued for named domains or the serveradmin role given with a list of domains, could rewrite over the REST API a custom role that accounts in other domains hold, and create custom roles or delete one that no account holds; 6.3.4 to 6.3.6.
- CVE requested (work item 96): a credential confined to named domains that may read their configuration, such as a domain administrator, the auditor role given a list of domains or an API key issued for named domains, could read the server-wide metric history over the REST API; 6.2.25 to 6.3.6.
- CVE requested (work item 87): over COM, an account given the serveradmin role with a list of domains was the server's administrator, its list aside, and one given domainadmin with a list that leaves out its own domain administered that domain's ordinary accounts, where the REST API refused both; 6.3.4 to 6.3.6, on Windows.
- CVE requested (work item 88): over the REST API, a credential that holds manage_roles in named domains could take a role away from an account in those domains whose admin level is the server administrator's, and so hand that account the server administrator's authority; 6.3.4 to 6.3.6.
- CVE requested (work item 93): a page on another site could make a browser that held a REST API credential from HTTP Basic send a state-changing request to the server, a cross-site request forgery; every version from 6.0.0 to 6.3.6.
- CVE requested (work item 97): the ACME HTTP-01 challenge responder served one connection at a time, so idle clients could make a certificate's issuance or renewal fail; every version from 6.0.0 to 6.3.6. It now serves up to 64 connections at once and closes one past that; a client that holds 64 idle connections open through a whole validation can still make it fail (the work item says what remains).
- CVE requested (work item 92): with the anti-virus action that removes attachments (AVAction 1: Delete infected attachments only in 6.3.6's Control Panel, Remove all attachments and deliver the text in 6.3.7's), a message whose one part is an attachment, and an S/MIME message signed as one part, were delivered as they arrived, with what the scanner had found in them; every version from 6.0.0 to 6.3.6. The default action, which deletes the message, was never affected.
- CVE requested (work item 94): with SRS on, which it is not by default, mail to an SRS address this server had handed out was not held to the relay rules; 6.2.1 to 6.3.6. Found by upstream hMailServer's review of its own SRS (upstream PR 649).
- CVE requested (work item 95): with SMTP logging on, which it is not by default, the SMTP log wrote some credentials in the clear (an AUTH PLAIN sent before EHLO or not in its one exact form, the bearer token of AUTH XOAUTH2 and AUTH OAUTHBEARER, and the lines of SCRAM-SHA-256, OAUTHBEARER and GSSAPI); every version from 6.0.0 to 6.3.6, each mechanism from the version that brought it. Found by upstream hMailServer (upstream issue 654).
The same release fixes or hardens more without a CVE request: the ARC seals this server makes attest its own SPF result, are made by the domain that relayed the message and name the domains their results are for; the stored-secrets key is no longer left in memory freed without being written over, nor a mailbox key encrypted at rest open past its idle minutes (both from 6.3.4); and, found by upstream hMailServer in code this project shares with it, an SRS address or a BATV tag almost a whole cycle old is no longer taken for fresh (upstream PR 649), and a SASL PLAIN client that asks SMTP, POP3 or ManageSieve to act as another account is refused, where it was signed in as itself (upstream issue 652). The Windows installers carry the .NET Desktop Runtime 10.0.13 (Microsoft's security release of 13 October 2026, where 6.3.4 to 6.3.6 carried 10.0.12), and the x64 installer MariaDB Connector/C 3.4.11, the first release of Connector/C with the fix of CVE-2026-107819, a flaw of the Connector/C 3.4.9 that 6.2.3 to 6.3.6 carried; the ARM64 installer carries no MySQL or MariaDB client.
Five of these fixes, those of work items 78 and 81 to 84, and their descriptions in CHANGELOG.md, were public in the project's repository before this release: on GitLab from 6 and 7 October 2026, and on master from 7 and 9 October 2026. That was the owner's decision, and an exception: the rule, which holds again after 6.3.7, is that a security fix becomes public about a day before the release that ships it (SECURITY.md, "What gets a release").
What changes without a switch
The full list is the 6.3.7 section of CHANGELOG.md, under "What changes on upgrade without a switch". Beside the notices above, in short:
- Database errors: on MySQL, MariaDB, SQL Server and SQL Server Compact an insert that forgives a duplicate key forgives that alone, and any other failure is reported (HM5032), where it was taken as done with no row written; on MySQL and MariaDB a lost connection is reconnected and the statement run again, so the statement after a database restart, a failover or wait_timeout no longer fails. An error log that was quiet may now name failures that were hidden.
- IMAP: COPY and MOVE by message number read their set in the client's numbering, and a set that names a message another session has just expunged is refused, NO [EXPUNGEISSUED], for the client to send again; a COPY or MOVE that fails part way leaves the destination as it was; SEARCH, SORT and THREAD ask a criterion named again beside itself once; FETCH BODY[N.MIME], and BODY[N] of a multipart, are the stored octets.
- POP3: classic Outlook for Windows, Outlook 2016 to 2024, downloads its mail again: the server accepts the UTF8 it sends after the login, until the session's first STAT, LIST, UIDL, RETR, TOP, DELE or RSET.
- DNS: a DNS lookup that fails is a failure, not a name with no addresses (upstream PR 640). The HELO and PTR tests no longer score a name they could not look up, a DNS blacklist and SURBL no longer read a failed lookup as "not listed", and delivery whose mail servers' lookup failed tells the sender that the DNS query failed (4.4.4) and retries.
- Anti-spam: a link's host that is not ASCII is read by UTS 46, and an HTML part's character references as a browser reads them, for the SURBL test and the sender lists' URL entries; and SpamAssassin is sent a collected message's own Return-Path, so its SPF and envelope rules may score such mail differently.
- Large messages: a message over 80 MB goes through the rules, the forwards, a bounce and the spam headers by its header alone, where it went through them as if it had no header; the rule conditions that need the body do not match, each with a line in the application log.
- Stops: setup, the live update's silent install and the uninstaller wait ShutdownDrainSeconds plus 90 seconds for the service's stop, where they waited plus 30; on Windows a stop no longer waits past a work queue's ten seconds for a thread held by a host or a database that has stopped answering; and scheduled tasks run in the second they are due, and no longer wait an hour when the clocks go back.
- Rules: a rule's Run function is refused when it is saved unless it names a plain function, for a rule of every owner, over COM and REST.
- The quarantine: a quarantined copy's file name carries where the message came from, its SPF result and the relaying domain (<GUID>.spf-fail.outside.eml, .relay-<id>); a tool that reads the quarantine folder by name meets the longer names.
- The Control Panel: Updates is a page of its own under Maintenance; the sidebar has Compliance and Virus scanning groups; API & monitoring is Monitoring & alerts; the PROXY protocol and XCLIENT are a card on Incoming relays; and Ctrl+K takes every old title and route to its page. A Control Panel signed in to a server on another computer shows and saves the server's
hMailServer.ini [Settings] values.
Reported from outside and fixed besides: the Control Panel's IP ranges page, which could show no list of ranges at all (work item 79, ThiagoES84); mail to a DNSSEC-signed domain whose MX answer came compressed, live.com among them, which DANE enforcement deferred (work item 80, ThiagoES84); and classic Outlook's POP3 downloads, which stopped at the UTF8 it sends after the login (work item 85, ciprianbalus). Thank you.
What is new
- The IMAP and POP3 listeners take the client's address from a PROXY protocol header, as the SMTP listener does, each from the peers on a list of its own; both are off by default.
- The first units of the active-active work, which is still not built (
ActiveActive.md). - The first step of the Control Deck's and the webmail's rebuild, with no product code:
ControlDeckFramework.md, WebThreatModel.md and WebAuthorisationMatrix.md, the matrix written from the code by build/generate-auth-matrix.py and held to it in CI.
Downloads
The release carries 62 files, each with its Sigstore bundle, <file>.cosign.bundle, beside it, and each file but a <file>.cdx.json SBOM has that bundle a second time as <file>.sigstore.json, the name Sigstore's own clients look for; with the bundles and the provenance, 160 files.
- Windows:
hMailServer-6.3.7-x64.exe, and hMailServer-6.3.7-arm64.exe for Windows on ARM, both Authenticode-signed by Progressive Robot Ltd. The ARM64 installer is a preview: it is cross-compiled on the project's x64 Windows runner and has never run on ARM64 hardware. SQL Server Compact has no ARM64 build, so a new ARM64 installation is set up against SQL Server or PostgreSQL (WindowsOnArm.md). If you install it on an ARM64 machine, please say how it went, working or not, in an issue on GitLab. - Linux, x86-64 and AArch64: the generic
hmailserver_6.3.7_amd64.deb, hmailserver_6.3.7_arm64.deb, hmailserver-6.3.7-1.x86_64.rpm and hmailserver-6.3.7-1.aarch64.rpm, the names an installed server's update check asks for; and each Debian 12 and 13, Ubuntu 24.04, Fedora 44 and 43, Enterprise Linux 10 and 9, openSUSE Leap 16.0 and Tumbleweed release's own package for both architectures, named hmailserver_6.3.7-1~<release>_<arch>.deb or hmailserver-6.3.7-1.<release>.<arch>.rpm. The generic .deb does not install on Debian 12, nor the generic .rpm on Enterprise Linux 9: each takes its own release's package. The AArch64 files are cross-compiled and tested under emulation: no AArch64 machine has run them. - The AppImages,
hMailServer-6.3.7-x86_64.AppImage and hMailServer-6.3.7-aarch64.AppImage, and beside them the source of the libraries they carry and of those their runtime links, hmailserver-6.3.7-appimage-bundled-sources.tar.gz and hmailserver-6.3.7-appimage-runtime-sources.tar.gz. - The source tarball, hmailserver-6.3.7.tar.gz; the Helm chart, hmailserver-chart-6.3.7.tgz; and the PowerShell module, HmailServer.psd1 and HmailServer.psm1, Authenticode-signed.
- An SBOM for each compiled file and the tarball, <file>.cdx.json, and the source tree's two,
hmailserver.spdx.json and hmailserver.cyclonedx.json; hmailserver-linux-6.3.7-SHA256SUMS.txt, the SHA-256 of every Linux file; and, beside the 62, hmailserver-6.3.7.intoto.sigstore.json, SLSA v1 build provenance that names each of them by its SHA-256.
The container image, registry.gitlab.com/hmailserver/hmailserver:6.3.7, also tagged 6.3 and latest, for linux/amd64 and linux/arm64, is pushed from this release's own pipeline once the release is published, by a job started by hand, as 6.3.6's was. In the container the update check names the image to pull and installs nothing. ContainerImage.md, "Checking an image", gives the cosign verify command and the check of the project's id.
No channel publishes 6.3.7 yet: the apt and dnf repositories, Docker Hub, Quay.io, the AUR, the Ubuntu PPA, Copr, the openSUSE Build Service, Chocolatey, PyPI and the PowerShell Gallery publish from master once their keys and accounts exist, and none is live as this release is made (Channels.md). The Snap Store's name is registered, and the job that would have put 6.3.7 on its edge and candidate channels once the release was published failed on 18 October 2026, on a tool missing from its image, with the two snaps built and checked: 6.3.7 is not on the Snap Store (Snap.md).
The newest stable release's files are also at fixed addresses that never lead to a pre-release: updates.progressiverobot.com/download/hMailServer-x64.exe, /download/hMailServer-arm64.exe, /download/hmailserver_amd64.deb, /download/hmailserver_arm64.deb, /download/hmailserver.x86_64.rpm, /download/hmailserver.aarch64.rpm, /download/hMailServer-x86_64.AppImage and /download/hMailServer-aarch64.AppImage; add .cosign.bundle for the bundle. https://updates.progressiverobot.com/download/ leads to that release's page.
Verification
Every file is signed with Sigstore by the project's GitLab CI pipeline for the tag v6.3.7, and was checked before publication with hmailserver --verify-update, built from the same commit. The certificate's identity is https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7, its issuer https://gitlab.com, and it carries the project's id, 86730559. With cosign and OpenSSL, and the file and its bundle beside you, the first command must say Verified OK, and the second must print ..86730559, the project's own id, which cosign does not check, since the identity is a path and a path could pass to another project were the group or the project renamed:
cosign verify-blob --bundle hMailServer-6.3.7-x64.exe.cosign.bundle \
--certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7' \
--certificate-oidc-issuer https://gitlab.com hMailServer-6.3.7-x64.exe
jq -r .verificationMaterial.certificate.rawBytes hMailServer-6.3.7-x64.exe.cosign.bundle \
| base64 -d | openssl x509 -inform DER -noout -text | grep -A1 1.3.6.1.4.1.57264.1.15
If your cosign has the --new-bundle-format option and does not use it by default, add it. Each file but a <file>.cdx.json SBOM also has its bundle a second time as <file>.sigstore.json; either name verifies the same way. 6.3.5, signed before the project moved into the group hmailserver on 29 September 2026, names https://gitlab.com/Progressiverobot/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.5 instead. To check that a file is one this release's pipeline built, against its build provenance, which says Verified OK only when the file's SHA-256 is one the provenance names:
cosign verify-blob-attestation --new-bundle-format \
--bundle hmailserver-6.3.7.intoto.sigstore.json --type slsaprovenance1 \
--certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7' \
--certificate-oidc-issuer https://gitlab.com hmailserver_6.3.7_amd64.deb
Then sha256sum -c --ignore-missing hmailserver-linux-6.3.7-SHA256SUMS.txt must say OK for each Linux file you downloaded. On Windows, Get-AuthenticodeSignature on either installer must answer Valid, with a signer certificate for CN=Progressive Robot Ltd; the x64 installer's published SHA-256 is dcae96bd75d6cae8e5a910d15940567067539ed99db5aeed40a815added4d85f and the ARM64 installer's 56a5425bd4e50e6dc79a02c6b79ff0f6bcc4e88ef59d457652efcaaac67601dd. On Linux a server from 6.3.4 on makes the same check its live update makes, hmailserver --verify-update <file>, with the bundle beside the file. In a clone, git -c gpg.ssh.allowedSignersFile=.gitlab/allowed_signers verify-tag v6.3.7 must report a good signature by the one key that file lists. For the image, ContainerImage.md, "Checking an image", gives the cosign verify command and the check of the project's id. The release's own notes, under Verification, give each file's SHA-256 and the certificate the pipeline was given; SECURITY.md, "Verifying a release", has the rest.
How it was checked
The tag's pipeline, https://gitlab.com/hmailserver/hmailserver/-/pipelines/2958958332, ran every gate before anything was published: the Windows suite, in two halves on the project's two Windows benches, 4,446 tests, 4,366 passed, 0 failed, 80 skipped; the Linux suite on one of the project's Linux runners, 2,652 tests, 2,284 passed, 0 failed, 368 skipped; the rebuild of the x86-64 server, .deb and .rpm byte for byte; the install of every Linux package in a clean container of its release, by that release's own package manager, the AArch64 ones under emulation, but for the generic x86-64 .rpm, which is built on Ubuntu and was installed on Fedora 44 with rpm --nodeps, its dependencies not resolved; the generic x86-64 .deb configured and started against a database; the static analysis, Semgrep and the dependency scan. It then checked every signature with the server's own verifier, hmailserver --verify-update, built from the same commit. The signed installer went through the installer smoke test: an upgrade from 6.3.6 passed 98 checks and a new installation 64, none failed.
Known issues
- Four narrower cases of work item 78 are not fixed in 6.3.7, by the owner's decision, and stay open: setup hardens a program folder before it copies anything into it only when setup makes the folder, and then just after making it; a folder that is already there is hardened in place, before the copy, only for an installation of the Control Panel alone, while for a server installation, and at every upgrade, the program folder, Bin and ControlPanel are hardened by /ProtectFolders at the end of setup; a link or a junction in the program folder's path is named in setup's log as not hardened, and not refused; and the files in Bin and ControlPanel are not listed by their owners. None of them reaches an installation in a folder only the administrators may change (the default under Program Files is one) unless a link that another account controls is on its path. Before upgrading an installation at the root of a drive, follow
ServiceAccount.md's steps (the notices above). - The ARM64 installer has never run on ARM64 hardware, and no AArch64 machine has run the AArch64 Linux files. If you install either, please say how it went, working or not, in an issue.
- No channel publishes the release yet (above); none is live as this release is made, and 6.3.7 is not on the Snap Store.
- An AppImage on Fedora, Enterprise Linux or openSUSE runs on the host's glibc and cannot require its extra character-set converters: install glibc-gconv-extra (Fedora, EL) or glibc-gconv-modules-extra (openSUSE) by hand; the server says when they are missing.
- An upgraded server keeps the .NET 10 Desktop Runtime it had (the notices above).
While releases pause
6.3.6 was the last release planned by date, by the owner's decision of 28 September 2026; the releases since are security releases, each cut from master with whatever finished work master holds then, until the maintainers say otherwise in SECURITY.md, "While releases pause". A confirmed vulnerability still ships in a release: a critical or high one as soon as its fix has passed the gates, and none held past 90 days from its acknowledgement. Other defects are fixed on master and ship with the next security release, or when releases resume. The 6.3 line receives security fixes until 30 September 2027; before that date the maintainers write in SECURITY.md whether support continues, and if nothing has been written, the 6.3 line is not supported from 1 October 2027. Nothing is back-ported: an installation of 6.3.6, 6.2 or anything older is upgraded in place to the newest release. To hear of a security release, switch the server's update check on (UpdateCheckEnabled), or follow the releases' feed at updates.progressiverobot.com/releases.atom.
The project, and reporting a vulnerability
The project's home is GitLab, at gitlab.com/hmailserver/hmailserver, where it moved from gitlab.com/Progressiverobot/hmailserver on 29 September 2026, with issue templates for a bug, a feature, a question and a security report, and a Service Desk address for anyone without a GitLab account: a bug report or a question for the maintainers emailed to contact-project+hmailserver-hmailserver-86730559-issue-@incoming.gitlab.com becomes a confidential issue, which only the maintainers see. The release is also mirrored on GitHub, at https://github.com/RainbowWizard-coder/hMailServer, re-published on 18 October 2026 from the GitLab release with each file checked against the SHA-256 GitLab's package registry records for it, where the per-release Debian packages are named with a dot in place of the tilde; issues and merge requests stay on GitLab. Report a vulnerability privately, by one of the two routes in SECURITY.md: a confidential GitLab issue with the Security template (check that it is still marked confidential before you submit it), or an email to that Service Desk address, which GitLab files as a confidential issue. Never in a forum thread or a public issue.
