Act nowDisclosed

Advisory · CVE-2026-129483

Cyrus SASL SRP flaw lets anyone log in without a password

An unauthenticated network client can send a crafted SRP public value to Cyrus SASL and authenticate as any existing user, with no password and no fixed release available yet.

Advisory published November 15, 2026Independent summary
Vendor
Cyrus SASL
Product
Cyrus SASL
Identifier / CWE
CVE-2026-129483
CWE-287
Action timing
Immediate
ELI5

Explain it like I’m five

Logging in with SRP is like proving you know a secret handshake. The server is supposed to reject a nonsense handshake, but it accepts one special nonsense value, and that makes the shared secret zero, which anyone can guess. So a stranger can walk in as any user without knowing the password.

SIMPLIFIED_ATTACK_PATH05 STEPS
  1. 01Login attempt

    An unauthenticated attacker starts an SRP login as any existing user, such as an administrator.

  2. 02Server responds

    The server returns its SRP parameters, including the prime N, generator, salt, and its public value B.

  3. 03Crafted public value

    Instead of a genuine public value, the attacker sends A equal to N, a multiple of N the server fails to reject.

  4. 04Zero shared secret

    The server computes a shared secret of zero, so the session key becomes a fixed value the attacker already knows.

  5. 05Forged proof accepted

    The attacker computes a valid proof using only public values, and the server authenticates them as the chosen user.

What happened

Cyrus SASL through 2.1.28 contains an authentication bypass in its SRP server mechanism. The server function srp_server_mech_step2 does not reject client public values that are multiples of the prime N, so an unauthenticated network client can send A equal to N and force the shared secret to zero, authenticating as any existing user without the password and learning the session keys. NVD scores it CVSS 9.1 (v3.1) and 9.3 (v4.0).

The flaw was reported upstream in July 2026, and a working proof of concept was published with the report. There is no fixed release: the project has shipped no new version since 2022, and the October 2026 oss-sec thread notes no maintainer response to the open security issues. The affected code is present in 2.1.28 and in current master.

Cyrus SASL underpins authentication in mail servers, LDAP directories, and other network services, so any deployment with the SRP mechanism enabled is exposed to unauthenticated login as any user.

What to do

  1. Inventory services that use Cyrus SASL, including mail servers, LDAP directories, and anything else offering SASL authentication.
  2. Disable the SRP mechanism on every Cyrus SASL deployment until a patched build is available.
  3. Apply a vendor or distribution patch as soon as one is released, and verify the deployed version afterwards.
  4. Review authentication logs for unusual SRP logins, logins as privileged accounts from unexpected sources, and SRP sessions that completed without a normal client.
  5. Treat any service that had SRP enabled as potentially compromised: rotate credentials and session keys for accounts that could have been reached.
  6. Where SRP is genuinely required, plan a move to a maintained authentication stack rather than waiting for an upstream release.

Management note

This is a critical, unauthenticated authentication bypass in a foundational library, with a public proof of concept and no fixed release in sight. The immediate mitigation is configuration, not patching: disable SRP. The longer question is strategic, since the project appears effectively unmaintained and the fix depends on distributions or a fork.