**Confidential until the fixed release is published.** ## Summary The REST listener (`RestApiPort`, 0, off, by default) serves the API, the Control Deck, and from 6.2.28 the self-service portal and webmail at `/portal`. An account signs in there with HTTP Basic, with any user name but the administrator's: at `POST /api/v1/session`, the portal's and the webmail's sign-in (the portal's script, `Portal.js` from 6.3.3), or on any other route that takes a credential. Without a certificate of its own the listener runs only on the loopback address (`RestApiBindAddress`, 127.0.0.1 by default; it refuses to start on any other address without TLS), and browsers reach it through a reverse proxy on the same machine - the arrangement `DevicesAndSessions.md` (from 6.3.4) calls the usual proxy, and from 6.3.4 the one peer whose `X-Forwarded-Proto` the listener believes (`BrowserCameOverTls_`). A proxy on the same machine that connects over loopback to a listener with its own certificate arrives from loopback too. The listener believes no `X-Forwarded-For` and reads no PROXY header, so behind such a proxy every browser reaches it from 127.0.0.1 (or ::1). The sign-in (`RestApiServer::AuthenticateAccount_`) passed the socket's peer to `AccountLogon::Logon`, and `AccountLogon::RegisterFailedLogin` counted every failure towards the auto-ban against that address, with no exemption for loopback but `AutoBanNeverBan` (from 6.3.2, empty by default). The listener's own accounting, `RestApiServer::RegisterAuthenticationFailure_`, called after it, leaves 127.0.0.1 and ::1 out on purpose - its comment calls a range covering 127.0.0.1 "a self-inflicted outage far worse than the brute-force attempt it was reacting to" - but the charge had already been made. So behind such a proxy, failed sign-ins from anybody, under any user name but the administrator's, reaching `MaxInvalidLogonAttempts` (3 within 30 minutes by default) wrote an auto-ban for 127.0.0.1 - an IP range at priority 100, above "My computer", that allows nothing - and the SMTP, POP3, IMAP and ManageSieve listeners refused 127.0.0.1 for `AutoBanMinutes` (60 by default); the ban could be written again each time it lapsed. With it every client on that machine that connects to those listeners from 127.0.0.1 was shut out: another webmail there that signs in over IMAP, local scripts and programs that submit mail over SMTP, and the local clients of ManageSieve (off by default; once on, it listens on 127.0.0.1 unless its bind address is changed). The REST listener itself, which asks no IP range, went on answering loopback, so the server's own portal and webmail went on working. This is the flaw of #106 at the server's own portal and webmail: there the web services listener charged its trusted proxy's address for the proxy's clients. It is another caller of `Logon`, fixed by its own change in the same release. 6.3.7's comment on the per-name lockout in `AccountLogon::Logon` names the hazard ("the loopback address of a co-hosted webmail front end, banned from SMTP, IMAP and POP3 for everybody behind it"), and the README's portal paragraph said the sign-in has "the same checks as an IMAP logon, lockout and auto-ban included", but nothing said that behind a proxy on the machine the auto-ban counts every browser's failures against 127.0.0.1. Measured on 27 October 2026 on the Linux build of 6.3.7 with PostgreSQL 18: three wrong passwords for an account at `GET /api/v1/me` from 127.0.0.1 were answered 401 and wrote an auto-ban (`Auto-ban: ` and the user name) for 127.0.0.1, after which SMTP's greeting to 127.0.0.1 went from "220 ..." to nothing and IMAP's from "* OK ..." to nothing, while the REST listener still answered loopback; with `127.0.0.1, ::1` in `AutoBanNeverBan` the same failures wrote no range and SMTP still greeted. On the fix's base with the regression fixture (its REST listener and sign-in code 6.3.7's, with #102's change to the auto-ban and the web services listener's fixes for #105 and #106 under it), on Linux with PostgreSQL 18, MySQL 8.4 and MariaDB 11.8 and on a Windows test server with SQL Server Compact, three failed account sign-ins from 127.0.0.1 at `GET /api/v1/me` and three at `POST /api/v1/session` each wrote an auto-ban for 127.0.0.1, under the account's name. On the same base on Linux with PostgreSQL 18: the server's log had "Auto-ban: logon failure 1 of 3 from 127.0.0.1" to "3 of 3" under the account's name; with `X-Forwarded-For`, `X-Real-IP` and `Forwarded` naming another address on every request the ban was still for 127.0.0.1; and failures from a client bound to 127.0.0.2 wrote a ban for 127.0.0.2, counted under the account's name and under "REST API", after which the listener refused 127.0.0.2 (the listener's own accounting, below under Fix). POP3 and ManageSieve, IPv6 loopback, and the versions before 6.3.7 were read from the code. Found by the project, 27 October 2026, while checking #106 against the other callers of `AccountLogon::Logon`. Proposed CVSS 3.1 5.3 (`AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L`); CWE-645 (Overly Restrictive Account Lockout Mechanism). ## Who can reach it, and what they gain Anybody who can reach the reverse proxy in front of the REST listener - the portal's and the webmail's address, where the listener is turned on behind one; no credential and no real account name. Three wrong passwords through the proxy within 30 minutes deny 127.0.0.1 the server's mail listeners for an hour, renewably, so that every client on the machine that connects to them from 127.0.0.1 - another webmail signing in over IMAP, local scripts that submit mail, local ManageSieve clients - cannot connect. Connections already open are not closed, unless `AutoBanFirewall` (from 6.3.2, off by default) is on, whose packaged hook on Linux drops the address's packets to the mail ports, open connections included (read from the code); the server goes on serving every other address, mail from the Internet that does not reach the server through a filter or relay on the machine goes on arriving, and, for a proxy on 127.0.0.1 or ::1, the portal and webmail go on working. The configuration it needs, from the code and the measurement above: the REST listener on (`RestApiPort` above 0) with a reverse proxy on the same machine forwarding sign-ins to it over loopback, to the plain loopback listener or to one with its own certificate; the auto-ban on failed logons on (the default); and, from 6.3.2, the proxy's loopback address not covered by `AutoBanNeverBan` (empty by default). ## Affected versions 6.2.28 through 6.3.7: `AuthenticateAccount_`, and with it any account's sign-in at the REST listener, first appears in 6.2.28, and the listener's `POST /api/v1/session` and portal with it. Windows from 6.2.28; Linux from 6.3.0, the first release with Linux builds, which build the same listener. `DevicesAndSessions.md`, which describes the proxy, and the listener's belief of `X-Forwarded-Proto` from loopback date from 6.3.4; a proxy on the machine was charged in the same way before them. The never-ban list by reverse name (from 6.3.6) cannot name loopback, since `localhost` cannot be a pattern. The original hMailServer: its 5.7.0 sources have no REST API, HTTP server, portal or webmail, so 5.7.0 is not affected; 5.7.1 and 5.7.2 were not checked. ## Workaround - On 6.3.2 to 6.3.7, put `127.0.0.0/8, ::1` in `AutoBanNeverBan` (it takes CIDR blocks). No loopback address is then counted towards an auto-ban, on any protocol, and its failures count against the name alone; nor does the REST listener then refuse one. - 6.2.28 to 6.3.1 have no `AutoBanNeverBan`. There, of the auto-ban's settings, only the auto-ban on failed logons turned off (`AutoBanOnLogonFailure` false, or `MaxInvalidLogonAttempts` 0) or `AutoBanMinutes` 0, which disconnects without writing a range, avoids it; each of these for every address. For a proxy that reaches the listener from another loopback address `AutoBanMinutes` 0 still lets the listener refuse it for five minutes, which turning the auto-ban on failed logons off does not. - Or let browsers reach the listener directly over its own TLS (`RestApiCertificateFile` and `RestApiPrivateKeyFile`, or the ACME certificate, with `RestApiBindAddress` an address they reach), with no proxy on the machine in front of it: each browser's own address is then the one counted. - Where loopback's failures are no longer counted towards a ban, turn on the per-name lockout (`AccountLockoutThreshold` above 0): it is then what limits the guesses at one account through the proxy, within its separate defect (#104, gitlab-org/cves#2566), fixed in the same release. ## Fix (6.3.8) On `master` in 6.3.8: `a6138dad28` - "An account's failed sign-in at the REST listener from loopback is counted against the name alone and never towards a ban of the address, as the commit before last made it for the web services listener's CardDAV, CalDAV and Autodiscover sign-in." Two commits follow it: `fcb538bd46` - "The texts on the REST listener's loopback ban give the remedy for older versions by the version that has it, and say what the commit before this one does in three more places" - and `d001d036d3` - "The regression fixture Security.RestApiLoopbackBan holds the REST listener's forwarder rule beyond 127.0.0.1, and the texts that speak of the listener's past name the two addresses it spared." They change comments, the documentation and the regression fixture, no behaviour. It ships in 6.3.8. - **What 6.3.8 does.** Every browser behind a reverse proxy on the same machine reaches the REST listener from loopback, the one peer whose `X-Forwarded-Proto` it believes. Up to 6.3.7 an account's failed HTTP Basic sign-in - on any route, `POST /api/v1/session`, the webmail's and the portal's sign-in among them - was counted towards the auto-ban against the connection's address, so a ban could be written that refused 127.0.0.1 at the SMTP, POP3, IMAP and ManageSieve listeners, while the REST listener, which asks no range, went on answering. A failed account sign-in from loopback is now counted against the name alone (`AccountLockoutThreshold`, off by default, which is the limit on the guesses at one account through such a proxy, as it already was), never towards a ban of the address, and no `Auto-ban: logon failure` line is written for it; a failure from any other address counts as before. - **The listener's own accounting** - of the administrator password, API keys, passkeys and the codes and passwords it checks itself - now spares all of 127.0.0.0/8, the peers it takes `X-Forwarded-Proto` from, where it spared 127.0.0.1 and ::1 alone. - **Older versions.** On 6.3.2 to 6.3.7, `AutoBanNeverBan` with `127.0.0.0/8, ::1` avoids it; 6.2.28 to 6.3.1 have no `AutoBanNeverBan`, and there only the auto-ban on failed logons switched off (`AutoBanOnLogonFailure` false, or `MaxInvalidLogonAttempts` 0) or `AutoBanMinutes` 0, which disconnects without writing a range, avoids it, each for every address. - **Not changed:** a ban of 127.0.0.1 written for failures on another protocol, such as a webmail on the machine signing in over IMAP; `AutoBanNeverBan` is the remedy there. A proxy on another machine in front of a listener with its own certificate is not taken for a proxy - the REST listener has no trusted-proxy setting - and its address is charged for its clients as before; `AutoBanNeverBan` with its address spares it. The fix is covered by the regression fixture `Security.RestApiLoopbackBan` on both suites: three failed sign-ins at `GET /api/v1/me` and at `POST /api/v1/session` from loopback write no ban and no such line, SMTP and IMAP still greet loopback, and the name is locked; failed account sign-ins, a wrong administrator password and a wrong API key from 127.0.0.2 (and on the Windows suite over ::1) are charged to nothing and the listener still answers; on the Windows suite, three from another address are still charged to it (`docs/AutoBan.md`, `docs/DevicesAndSessions.md`).