YunoHost SOGo package auth bypass lets attackers log in as any user (CVE-2026-74864)

CVE-2026-74864 and CVE-2026-74865 are CWE-639 authorization bypasses in YunoHost-Apps sogo_ynh, the package that deploys the SOGo groupware on YunoHost, and every version before 5.8.0~ynh9 is affected. CVE-2026-74864, CVSS 4.0 9.3 with the vector AV:N/AC:L/AT:N/PR:N/UI:N, abuses a packaging decision that treats any request carrying the x-webobjects-remote-user header as already verified; the Nginx front end never strips that header from client traffic, so anyone with network reach to the SOGo endpoint names any account, administrators included, and is logged in with no password. CVE-2026-74865, CVSS 4.0 9.2, comes from the same package setting SOGoTrustProxyAuthentication=YES, which skips password verification on HTTP Basic auth, so a known username plus any arbitrary password authenticates. CERT Polska coordinated the disclosure published 2026-09-30, crediting researcher Przemysław Knycz of WeKrwi.IT; the flaws are not in CISA KEV, carry no EPSS score, and no public PoC or in-the-wild exploitation has been reported.

The CVSS numbers understate the operational story, which is the two months the vendor spent sitting on the mechanics. The patch commit landed 2026-07-28 and the YunoHost forum announced a critical fix on 2026-07-29 with technical detail withheld under embargo, so for sixty days defenders patched blind while attackers had only the version number to go on. Publication on 2026-09-30 removed the last barrier: this bug needs no tooling, one header or one Basic-auth attempt against a known username, so the exploitation status of theoretical expired the moment the advisory made the recipe public. The population least able to respond is also the largest exposure: 5.8.0~ynh9 requires YunoHost 12.1.38 or newer, maintainers stated no package fix is planned for YunoHost 11, and those operators were left with a manual commit backport and a hand-edited /etc/sogo/sogo.conf. A successful hit is full read and write on the victim's mail, calendar and contacts, admin functions included, and it produces no failed-login noise, nothing but one ordinary 200 in an access log.

Upgrade to 5.8.0~ynh9, which requires YunoHost 12.1.38 or newer, and restart the server afterward; the SSO integration stays disabled until the package migrates to SOGo 6. Operators stuck on YunoHost 11 should apply commit bd4b4d00ee1272ac71a29b601fb7e6c9d289a03e or remove the SOGoTrustProxyAuthentication parameter from /etc/sogo/sogo.conf by hand, and ensure every reverse proxy in front of SOGo strips client-supplied x-webobjects-* headers before forwarding. Hunt in Nginx access logs for external requests carrying x-webobjects-remote-user, and for Basic-auth successes in $remote_user where one public IP authenticates as two or more distinct users within 15 minutes, the bypass signature, since wrong passwords never surface at the web tier. Then sweep admin and exposed mailboxes for forwarding rules, filters, vacation messages and folder shares created from public sources; the accompanying threat report ships nine behavioral detection rules covering exactly these patterns, with its indicator values gated behind registration, so log analysis is the practical ground truth.

Two developments would change the assessment. Scanner telemetry for the header, a public PoC, or a KEV or EPSS listing would move this from candidate to confirmed threat, and given a one-request exploit the gap between those states is small. A YunoHost 11 backport matters just as much, because without it a long tail of installs stays exposed with the exploit mechanics now public and no vendor package to install.