---
id: CVE-2026-107569
title: Unchecked Input for Loop Condition in hMailServer
summary: >-
  Unchecked input for a loop condition in Progressive Robot hMailServer 6.0.0
  through 6.3.6 allows a remote unauthenticated attacker to stop the server
  carrying mail. The server bounds the mail it generates in response to a
  message - a rul…
severity: high
cvss: 7.5
cvssVector: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'
cvssSource: cna
cwe:
  - CWE-606
vendor: Progressive Robot Ltd
product: hMailServer
affected:
  - hMailServer >= 6.0.0 <= 6.3.6
published: '2026-10-19'
updated: '2026-10-19'
sourceUpdated: '2026-10-19T15:34:37.492Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-107569'
references:
  - url: 'https://gitlab.com/hmailserver/hmailserver/-/work_items/81'
  - url: 'https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7'
tags:
  - cve.org
ingestedAt: '2026-10-19T16:32:30.077Z'
---

## Overview

Unchecked input for a loop condition in Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to stop the server carrying mail. The server bounds the mail it generates in response to a message - a rule forward, reply or copy, an account forward, a Sieve redirect, vacation or notify, a bounce, an out-of-office reply - by a counter it carries in the message's X-hMailServer-LoopCount header, and makes no more once the counter reaches the configured rule loop limit (5 by default); that is what ends a forwarding or auto-reply cycle in a bounded number of hops. X-hMailServer-LoopCount is an ordinary header that is not stripped from mail arriving from outside, and the server read it with a signed conversion and no validation, so a count below zero passed every test against the limit: a sender who sets X-hMailServer-LoopCount to a negative value, or on the Linux builds to a value above the 32-bit signed range that the conversion wraps to a negative one, lifts the bound, and a message that enters a generated-mail cycle then loops up to about two thousand million times, each hop a queued message and a delivery, filling the queue and disk and stopping mail service. The Sieve notify action (from 6.2.22) consulted no limit at all, and its increment of the count could overflow a signed integer; and an account could reset the counter on its own mail through a Sieve editheader of the header (from 6.2.22) or a rule Set header value action (all versions) ahead of a forward or redirect.

## Affected

- `hMailServer >= 6.0.0 <= 6.3.6`

## Remediation

Upgrade to hMailServer 6.3.7, which reads X-hMailServer-LoopCount in one validated place (a count only when it is digits and never above the limit; anything else is read as the limit so no generated mail is made from it), holds a Sieve notify to the same limit, and refuses an account Sieve script or rule that edits the counter, and writes a line break in a header value as spaces unless it folds the line, so that no value a generated message is built from writes a field of its own. Until then there is no setting that stops the header being read or that turns Sieve off: reduce forwarding and auto-reply arrangements that can feed one another, keep the Sieve script surfaces closed to accounts (ManageSieveServerPort=0, the default, and the REST API off where it is not needed, RestApiPort=0, the default), review active Sieve scripts and account rules for a notify of the account's own address and for an edit of X-hMailServer-LoopCount, and watch the queue for a message generated far past the loop limit.