VYPR
← All advisories
Unrated severityNVD Advisory· Published Jun 17, 2026

CVE-2026-55706

CVE-2026-55706

Description

OpenBSD's sppp(4) PAP authentication is bypassed by sending a request with zero-length name and password, as bcmp(...,0) always returns success.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

OpenBSD's sppp(4) PAP authentication is bypassed by sending a request with zero-length name and password, as bcmp(...,0) always returns success.

Vulnerability

The sppp_pap_input() function in sys/net/if_spppsubr.c in OpenBSD before commit 076e2b1 (all versions through 7.6) uses attacker-controlled name_len and passwd_len fields from an incoming PAP Auth-Request as the length argument to bcmp(). The existing guard checks that these values are not greater than AUTHMAXLEN (255), but allows zero. Since bcmp(buf, ref, 0) always returns 0, sending a PAP frame with name_len=0 and passwd_len=0 causes the authentication check to succeed unconditionally, bypassing credential verification entirely [1][2]. A secondary heap over-read is also possible by setting name_len larger than the actual allocated credential string [2].

Exploitation

An attacker must be able to send a PPP PAP authentication request to a vulnerable OpenBSD system acting as the PAP authenticator. No prior authentication or special privileges are required. The attacker crafts a standard PAP Auth-Request packet but sets both the name length and password length fields to zero. This single malformed packet is sufficient to trigger the authentication bypass [1][2].

Impact

Successful exploitation allows an unauthenticated remote attacker to bypass PAP authentication and gain unauthorized access to the PPP link. Once authenticated, the attacker may proceed to higher-layer network communications, potentially leading to further compromise of the connected network. The heap over-read variant could leak sensitive kernel memory [1][2].

Mitigation

The vulnerability is fixed in OpenBSD -current by commit 076e2b1 (2026-06-14) [3]. The fix replaces the upper-bound check with an exact length comparison using strlen() against the configured credential lengths. Users should update to a version containing this commit or, if on a stable release, wait for the next errata or release. No workaround is available; PAP authentication must be considered unreliable on unpatched systems [2][3].

References
  1. security - OpenBSD sppp_pap_input: PAP authentication bypass
  2. A 27-Year-Old Authentication Bypass in OpenBSD's PPP Stack · Argus Blog
  3. sppp_pap_input(): do not compare credentials if the lengths of received · openbsd/src@076e2b1

AI Insight generated on Jun 17, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • OpenBSD/Srcinferred2 versions
    < 076e2b1+ 1 more
    • (no CPE)range: < 076e2b1
    • (no CPE)range: < 076e2b1

Patches

1
076e2b1c1fc4

sppp_pap_input(): do not compare credentials if the lengths of received

https://github.com/openbsd/srcmvsJun 14, 2026via body-scan
commit
1 file changed · +3 −3
  • sys/net/if_spppsubr.c+3 −3 modified
    @@ -1,4 +1,4 @@
-/*	$OpenBSD: if_spppsubr.c,v 1.201 2026/05/16 13:27:03 daniel Exp $	*/
+/*	$OpenBSD: if_spppsubr.c,v 1.202 2026/06/14 05:39:23 mvs Exp $	*/
 /*
  * Synchronous PPP link level subroutines.
  *
@@ -3813,8 +3813,8 @@ sppp_pap_input(struct sppp *sp, struct mbuf *m)
 			sppp_print_string((char*)passwd, passwd_len);
 			addlog(">\n");
 		}
-		if (name_len > AUTHMAXLEN ||
-		    passwd_len > AUTHMAXLEN ||
+		if (name_len != strlen(sp->hisauth.name) ||
+		    passwd_len != strlen(sp->hisauth.secret) ||
 		    bcmp(name, sp->hisauth.name, name_len) != 0 ||
 		    bcmp(passwd, sp->hisauth.secret, passwd_len) != 0) {
 			/* action scn, tld */

Vulnerability mechanics

Root cause

"Missing exact-length pre-check in sppp_pap_input allows bcmp with attacker-controlled zero length to always return 0, bypassing PAP credential validation."

Attack vector

An attacker on the same network segment sends a PPPoE discovery and LCP negotiation, followed by a PAP Auth-Request with `name_len=0` and `passwd_len=0`. Because `bcmp(buf, ref, 0)` always returns 0 and the existing upper-bound guard (`> AUTHMAXLEN`) permits zero, both credential comparisons succeed unconditionally [ref_id=1][ref_id=2]. The target system must be configured as a PAP authenticator (e.g. `ifconfig pppoe0 peerproto pap peername <x> peerkey <y>`), but the attacker does not need to know any credentials [ref_id=1]. The same zero-length fields also trigger a kernel heap over-read when a non-zero length larger than the allocated credential is supplied [ref_id=2].

What the fix does

The patch replaces the upper-bound checks (`name_len > AUTHMAXLEN`, `passwd_len > AUTHMAXLEN`) with exact-length comparisons (`name_len != strlen(sp->hisauth.name)`, `passwd_len != strlen(sp->hisauth.secret)`) [patch_id=6240366]. This mirrors the already-correct CHAP handler pattern [ref_id=2]. The change simultaneously prevents the zero-length bypass (because `0 != strlen(...)` is true when a credential is configured) and bounds the `bcmp` length to the exact stored credential size, eliminating the heap over-read [ref_id=1][ref_id=2].

Preconditions

  • configTarget must be configured as a PAP authenticator (e.g. ifconfig pppoe0 peerproto pap peername peerkey )
  • networkAttacker must be on the same network segment (broadcast domain) as the target
  • authNo authentication or prior knowledge of credentials required
  • inputAttacker controls name_len and passwd_len fields in the PAP frame payload

Generated on Jun 17, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

3

News mentions

0

No linked articles in our index yet.