hMailServer 6.3.6

Security

Each of these was found by the project's own review, and each is fixed in 6.3.6 unless it says otherwise. The Security section of CHANGELOG.md at the tag and the work items it links give the details; the project's GitLab group is the CVE Numbering Authority's route for them, and several identifiers were still requested when 6.3.6 was published. Upgrade every server running 6.3.5 or earlier.

• CVE-2026-103011: a heap buffer overflow in the encryption routine of the legacy Blowfish code of stored secrets, inherited from the original hMailServer, in every version up to 6.3.5. 6.3.6 replaces that code with the project's own. CVE-2026-103010 is the overflow in the decryption routine of the same code, in every version up to 6.3.3, fixed in 6.3.4, whose notes did not say so.
• CVE-2026-104660: on Windows, COM objects that carry no credential (a message, its attachments or a fetch account that a program creates itself, and the objects an Application handed out once a later Authenticate on it failed) were not refused what only a signed-in caller may do, so with an administrator password set a local Windows user with no hMailServer credential could queue mail, read and write files as the service's account, and attach a fetch account to any account; every version up to 6.3.5.
• CVE-2026-104658: on Linux, the live update's apply step, which runs as root, took the unit to stop and, for an AppImage, the verifying program from the request the service account writes, and wrote its log and its outcome by names through which a symbolic link that account planted could lead them elsewhere; 6.3.4 and 6.3.5.
• CVE requested (work item 71): the commands an administrator runs elevated on Windows wrote by path into folders the service's account can change, and on Linux the store commands run as root followed links that account planted and every command run as root wrote its error reports into that account's log directory by name; on Windows 6.3.4 and 6.3.5, on Linux every version from 6.3.0 to 6.3.5.
• CVE requested (work item 77): on Windows, the installer left the Data, Logs, Temp, Database and Events folders and hMailServer.INI with the permissions Program Files hands down, so every account that could sign in to the computer could read the mail, the logs, the event scripts and the database's password; every version from 6.0.0 to 6.3.5. The installer now makes them private to SYSTEM, the Administrators and the service, and on Linux the AppImage makes its folders 0700.
• CVE-2026-104659: the REST administration listener's loopback port answered a request whatever its Host, so a web page could reach the console through a browser on the same machine, and a wrong administrator password over REST from the loopback address was not slowed down. Such a request is now refused with 421, and a wrong password costs a growing delay of up to ten seconds.
• CVE-2026-103647: the webmail handed the browser an attachment it had decrypted itself (S/MIME or OpenPGP) under the type the message named; 6.3.2 to 6.3.5. It is now always a file the browser only saves.
• CVE-2026-104704: outbound DANE used DANE-EE records alone, so a host whose validated TLSA records were of another kind was delivered to as if it published none; every version up to 6.3.5. DANE-TA is now verified too. CVE requested (work item 64): outbound DANE read a DNS lookup that did not come back whole as unsigned, so whoever could disturb a recipient domain's DNS could take it out of DANE; every version up to 6.3.5.
• CVE requested (work items 62 and 63): the REST listener's table of browser sessions dropped its least recently used session whoever held it, so one account holder signing in over and over signed out every webmail tab on the server that sat idle for a minute (6.2.28 to 6.3.5, and the Control Deck with them from 6.3.0); and the pending halves of single sign-on and passkey sign-ins, which anybody may start, were held the same way, so a client asking for sign-in starts a few times a second made other people's OpenID Connect, SAML and passkey sign-ins fail (6.3.4 and 6.3.5). The browser now carries a pending sign-in, sealed.
• CVE requested (work items 65, 66, 67, 68, 69, 70, 72, 73, 74, 75 and 76): code that took time growing with the square of its input, which one message or one request could use to hold a thread that serves everybody: the webmail's embedded images and a stranger's S/MIME certificate kept without a trust check (6.3.2 to 6.3.5); the server's string replacement, reached by a message with an HTML part full of entities and by the DMARC test verifying a DKIM signature full of spaces (6.0.0 to 6.3.5); parsing one IMAP FETCH (6.0.0 to 6.3.5); a returned bounce or complaint report begun by very many blank lines (6.3.4 and 6.3.5); a header field with very many line breaks, which the DMARC test reads for each received message (6.0.0 to 6.3.5); a MIME header parameter whose value is empty and directly followed by a semicolon, which never ended (6.0.0 to 6.3.5); verifying DKIM or ARC signatures over a very large header (6.0.0 to 6.3.5); expanding a macro in a sender's SPF record into a name too long to look up (6.3.4 and 6.3.5); an account holder's own Sieve filter, whose :matches test backtracked and whose deleteheader erased fields one at a time (6.2.22 to 6.3.5); and the JSON reader, which reads the REST API's bodies and, where domain reports are on, a TLS report of up to 16 MB that anyone may mail in, where a 4 MB report took about 300 seconds (6.3.2 to 6.3.5).
• CVE-2026-103649: on Linux, some network waits had no timeout: the MTA-STS policy fetch, the DANE TLSA query, the OAuth2 token request, the ACME client and its http-01 responder, and the ManageSieve and metrics listeners, and in 6.3.0 to 6.3.2 the server's own DNS resolver; 6.3.0 to 6.3.5.

The same release fixes or hardens more without a CVE request: calendar messages delivered by mail now change a stored event only from a sender the server verified (6.3.4 and 6.3.5 did not check); the Control Deck and the webmail are served under stricter page policies; attachments, files sent as links and contact photos keep their declared type only when no browser runs or renders it; ManageSieve serves its connections side by side and holds each to deadlines; and a mailbox key and the stored-secrets key no longer stay whole in memory freed without being written over, as they could in 6.3.4 and 6.3.5. The Windows installers carry OpenSSL 4.0.3 (CVE-2026-84783 and others) and libpq from PostgreSQL 18.6, and event scripts on Linux run in QuickJS 2026-06-04 (CVE-2025-62494, CVE-2025-62493, CVE-2025-62492).

What changes without a switch

The full list is the 6.3.6 section of CHANGELOG.md, under "What changes on upgrade without a switch". Beside the notices above, in short:

• Spam checks: the MX-record test and the SURBL test cut host names by the Public Suffix List compiled into the server, so a sender at a public suffix itself with no MX (github.io, co.uk) now fails the MX test; the SURBL test reads a link's host as a browser does, asks each list about every domain a message links to (up to 200; more scores the new SurblTooManyDomainsScore, 5 by default), and a list's error answers are never a listing; tlds.txt is removed.
• Port 25 stays as it was: an upgraded server's SMTP listeners still take AUTH on port 25, so nobody is banned on the morning of the upgrade. The setup checklist's new item, No password on port 25, says to move clients that sign in on 25 to 587, then set port 25 to Honeypot or Off. A new installation's port 25 is a Honeypot.
• Backups leave out the live update's Updates folder, and a destination inside the data directory works; up to 6.3.5 it failed every backup. A full restore of messages, which failed on every installation made new with 6.3.4 or 6.3.5, now copies the archive's store in first; it keeps this installation's own self-signed certificate and key when the archive's key is not this installation's.
• More web requests go through HttpProxy when it is set: the OAuth2 token, the MTA-STS policy, ACME, brand logos, Web Key Directory, Web Push, one-click unsubscribe and an inbound webhook route held to public addresses.
• The live update keeps its outcome after the start, tries a failed scheduled check again once ten minutes later, and keeps a verified installer across a restart. Its trust settings (UpdateSigningIdentity, UpdateSigningIssuer, UpdateSourceRepository, UpdateTrustRootsFile, UpdateLogPublicKeyFile) are read from hMailServer.ini alone, and COM and the REST API refuse a change to them.
• Calendars: a cancellation of some occurrences of a series takes those out of a guest's calendar and leaves the rest.
• ManageSieve (off by default) is held to deadlines: a command line within 30 seconds, sign-in within 60, a literal 300; an account has at most four sessions.
• IP addresses written in text are read the same way on Windows as on Linux: four decimal parts, or IPv6 as RFC 4291 writes it. A value kept in an older form (192.168.1, 010.0.0.1, an address with a port) is read the new way from the first start, and an AutoBanNeverBan entry so written protects nothing (HM6524).
• Sign-in limits: an account, or the administrator, holds at most fifty REST browser sessions.
• Webmail S/MIME: a correspondent's certificate is kept for encrypting replies only when its chain is trusted, under the message's From address; review the certificates kept before the upgrade on the webmail's Security page. From 6.2.25 to 6.3.5 an account saved through a webmail's password or out-of-office plugin could have its retention overwritten: check those accounts' retention after upgrading.
• What the auto-ban put below the server (the Linux firewall hook, AutoBanCommand) is lifted after a stop too, and Windows' uninstaller removes the auto-ban's firewall rules.
• On Linux the backup and event logs are UTF-8, converted in place the first time. The .deb and the .rpm require ca-certificates.
• Text in the Control Panel can be selected and copied on every page and dialogue. Scripting off runs no script engine. The project's address is gitlab.com/hmailserver/hmailserver in the Control Panel's links, security.txt, the systemd units and the packages.
• The packaging Compose file runs PostgreSQL 18: if you take the new docker-compose.yml, move the PostgreSQL 16 data once, with a dump and a load. A monitor that matches "The response carried no HTTP headers." needs the new sentence, which says who ended the connection, after how many bytes and seconds.

What is new

• A never-ban list by reverse name: spare a provider whose outbound hosts share a reverse name from every auto-ban, checked forward and back.
• Port 25 takes no password: each SMTP listener's AUTH is On, Off or Honeypot.
• An auto-ban can be widened to its reverse-name neighbours in the same /24, off by default.
• A HELO name or a sender's domain that is not a name can be refused, two settings, off by default.
• One-click install of an update from the Control Panel on a Windows server whose service is not an administrator.
• A Nix flake with a NixOS module, an APKBUILD and an OpenRC service for Alpine Linux, and a snap are in the tree, built without the live update; none is published in a distribution's archive or store yet.

Downloads

The release carries 62 files, each with its Sigstore bundle, <file>.cosign.bundle, beside it, and each file but a compiled file's SBOM has that bundle a second time as <file>.sigstore.json, the name Sigstore's own clients look for.

• Windows: hMailServer-6.3.6-x64.exe, and hMailServer-6.3.6-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, and a silent one is given its database on the command line. 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.6_amd64.deb, hmailserver_6.3.6_arm64.deb, hmailserver-6.3.6-1.x86_64.rpm and hmailserver-6.3.6-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.6-1~<release>_<arch>.deb or hmailserver-6.3.6-1.<release>.<arch>.rpm, each built in that release's own container and installed and run in a clean one. The generic .deb asks for glibc 2.38 or later, so Debian 12 takes its own package, and the generic .rpm does not install on Enterprise Linux 9, which takes its own. Every .rpm requires glibc's extra character-set converters, glibc-gconv-extra (glibc-gconv-modules-extra on openSUSE), which dnf and zypper install with it. The AArch64 files are cross-compiled and tested under emulation: no AArch64 machine has run them.
• The AppImages, hMailServer-6.3.6-x86_64.AppImage and hMailServer-6.3.6-aarch64.AppImage, with the project's own AppImage runtime, and beside them the source of the libraries they carry and of those their runtime links, as their licences ask.
• The source tarball, hmailserver-6.3.6.tar.gz, reproducible and with nothing non-free in it; the Helm chart, hmailserver-chart-6.3.6.tgz; and the PowerShell module, HmailServer.psd1 and HmailServer.psm1, Authenticode-signed.
• An SBOM for each compiled file and the tarball, <file>.cdx.json (CycloneDX 1.6, its subject that file by its SHA-256), and the source tree's two, hmailserver.spdx.json and hmailserver.cyclonedx.json; hmailserver-linux-6.3.6-SHA256SUMS.txt, the SHA-256 of every Linux file, the two AppImage sources files and the chart; and hmailserver-6.3.6.intoto.sigstore.json, SLSA v1 build provenance that names every file by its SHA-256.

The container image, the first the project has published: registry.gitlab.com/hmailserver/hmailserver:6.3.6, also tagged 6.3 and latest, one index over linux/amd64 and linux/arm64, each built from this release's .deb of its architecture and signed with cosign as this release's pipeline, with its SBOM attested to it. In the container the update check names the image to pull and installs nothing. ContainerImage.md in the repository's hmailserver/docs gives the pull, the check of the project's id and the Compose file.

No channel publishes 6.3.6 yet: the apt and dnf repositories, Docker Hub, Quay.io, the AUR, the Ubuntu PPA, Copr, the openSUSE Build Service, Chocolatey, the Snap Store, PyPI and the PowerShell Gallery publish from master once their keys and accounts exist.

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. 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.6, 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.6, its issuer https://gitlab.com, and it carries the project's id, 86730559. With cosign and the file and its bundle beside you, the first command must say Verified OK, and the second must print the project's 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.6-x64.exe.cosign.bundle \
--certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.6' \
--certificate-oidc-issuer https://gitlab.com hMailServer-6.3.6-x64.exe

jq -r .verificationMaterial.certificate.rawBytes hMailServer-6.3.6-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. 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.6.intoto.sigstore.json --type slsaprovenance1 \
--certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.6' \
--certificate-oidc-issuer https://gitlab.com hmailserver_6.3.6_amd64.deb

Then sha256sum -c --ignore-missing hmailserver-linux-6.3.6-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 2f673913e5f127d688090e98f6001ca567cd45560d452aebc74421b5533cfe53 and the ARM64 installer's 59f8edd259bdef2e31dd83da152c3f748d67a27a19e6c3c8f5a2ade2ff84227c. 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.6 must report a good signature by the one key that file lists. The release's own notes, under Verification, give each file's SHA-256 and the certificate the pipeline was given; SECURITY.md's "Verifying a release", "Build provenance" and "Software bills of materials" have the rest.

How it was checked

The tag's pipeline ran every gate before anything was published: the Windows suite on the project's Windows runner, 4,110 tests, 4,031 passed, 0 failed, 78 skipped and 1 inconclusive; the Linux suite on the project's Linux runner, 2,409 tests, 2,066 passed, 0 failed, 343 skipped; the rebuild of the x86-64 .deb and .rpm byte for byte; the install and start of every Linux package in a clean container of its release, the AArch64 ones under emulation; the static analysis, Semgrep and the dependency scan. It then checked every signature with the server's own verifier. The signed installer went through the installer smoke test: an upgrade from 6.3.5 passed 93 checks and a new installation 59, none failed. The server's build stamp is 6.3.6.45.

Known issues

• The ARM64 installer has never run on ARM64 hardware, and no ARM64 Windows server has a live update to 6.3.6, since no release before it carried the ARM64 installer; from 6.3.6 one finds its own installer by name, and an x64 server is never offered it.
• No channel publishes the release yet (above); none is live as this release is made.
• 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.
• A server from 6.2.28 to 6.3.3 pointed at the project's feed with UpdateFeedUrl downloads the installer at every check and refuses it, since it trusts only GitHub's signer: keep UpdateAutoDownload off there until it is upgraded by hand.

Releases pause after this one

6.3.6 is the last release for the time being, by the owner's decision of 28 September 2026, and no feature release follows it until the maintainers say otherwise in SECURITY.md, "While releases pause". A confirmed vulnerability still ships, in a release of its own that is 6.3.6 with fixes (6.3.7, 6.3.8 and so on): a critical or high one as soon as its fix has passed the gates, and none held past 90 days. 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 is written, it ends then. There are still no maintenance branches: an installation of 6.3.5, 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. Report a vulnerability privately, by one of the two routes in SECURITY.md: a confidential GitLab issue with the Security template, or an email to that Service Desk address, which GitLab files as a confidential issue. Never in a forum thread or a public issue.