CVE-2026-55706: OpenBSD Authentication Bypass Vulnerability

CVE-2026-55706 Overview

CVE-2026-55706 is an authentication bypass vulnerability in the sppp_pap_input function within sys/net/if_spppsubr.c in OpenBSD. The flaw resides in the kernel's Synchronous PPP (sPPP) implementation, which handles Password Authentication Protocol (PAP) credential checking. An attacker on an adjacent network can submit a PAP authentication request containing zero-value length fields to bypass credential comparison.

The weakness is classified under [CWE-1284] (Improper Validation of Specified Quantity in Input). It affects OpenBSD versions prior to commit 076e2b1. Public analysis by Argus Systems indicates the underlying logic flaw existed in the codebase for approximately 27 years before remediation.

Critical Impact
Adjacent-network attackers can bypass PAP authentication on OpenBSD sPPP interfaces by sending crafted requests with zero-length credential fields, gaining unauthorized link-layer access.

Affected Products

OpenBSD versions before commit 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8
Systems using sys/net/if_spppsubr.c synchronous PPP driver
Network deployments terminating PAP authentication on OpenBSD endpoints

Discovery Timeline

2026-06-14 - Patch committed to OpenBSD source tree (if_spppsubr.c revision 1.202)
2026-06-16 - Public discussion posted to Openwall OSS-Security mailing list
2026-06-17 - CVE-2026-55706 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-55706

Vulnerability Analysis

The vulnerability resides in sppp_pap_input(), the kernel routine that processes inbound PAP authentication frames on synchronous PPP links. PAP messages carry a peer identifier and password, each prefixed by a length byte. The function compared received credentials against locally configured values without first validating that the supplied length fields were non-zero.

When an attacker submits a PAP authenticate-request with length fields set to zero, the comparison routine treats the empty input as matching, regardless of the configured secret. The peer is then authenticated and the PPP link transitions to the network phase. This bypasses the only authentication boundary protecting the link.

The issue is exploitable from an adjacent network position because PAP runs at the data-link layer over a serial or tunneled PPP session. Exploitation requires the ability to send frames to a PAP-enabled interface, such as a leased line, dial-up endpoint, or PPP-over-Ethernet (PPPoE) concentrator.

Root Cause

The root cause is missing input validation on the length fields contained in the PAP authenticate-request packet. The credential comparison path executed even when the declared lengths were zero, allowing a degenerate match. [CWE-1284] captures this class of defect: failure to validate a specified quantity before consuming it.

Attack Vector

The attack vector is adjacent-network. An attacker needs link-layer reachability to an interface running sPPP with PAP enabled. The attacker transmits a malformed PAP authenticate-request with zero-length peer ID and password fields and receives an authenticate-ack in response.

// Patch context from OpenBSD source tree
// Source: https://github.com/openbsd/src/commit/076e2b1c1fc4ac0883a72d3544131ad5cee7adf8
-/*	$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.
  *

The patch in sppp_pap_input() adds a guard that refuses to compare credentials when received lengths are zero. See the GitHub OpenBSD Commit and the Argus Blog Auth Bypass Analysis for full technical detail, and the Argus Blog PoC Script for a reference proof of concept.

Detection Methods for CVE-2026-55706

Indicators of Compromise

PAP authenticate-request frames containing zero-length peer ID or password fields captured on sPPP interfaces.
Successful PAP authentications immediately followed by IPCP negotiation from previously unknown peers.
Unexpected sppp log entries indicating peer authentication from non-provisioned link identifiers.

Detection Strategies

Inspect PPP packet captures on terminating routers and firewalls for malformed PAP frames with zero-byte credential lengths.
Audit OpenBSD kernel versions against the patched if_spppsubr.c revision 1.202 or later.
Cross-reference PAP authentication events with expected peer inventories to surface unauthorized link establishments.

Monitoring Recommendations

Enable verbose PPP logging (spppcontrol and pppd log facilities) and forward records to a central analytics platform.
Alert on PAP authentication successes that originate from MAC addresses or circuit IDs not present in the provisioning database.
Monitor for new IP assignments via IPCP on interfaces that should have a static peer set.

How to Mitigate CVE-2026-55706

Immediate Actions Required

Update OpenBSD to a build that includes if_spppsubr.c revision 1.202 (commit 076e2b1) or later.
Inventory all systems terminating PAP over synchronous PPP or PPPoE and prioritize patching internet-adjacent concentrators.
Where patching is not immediately possible, disable PAP on sPPP interfaces and require CHAP or stronger authentication.

Patch Information

The authoritative fix is OpenBSD commit 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8, which modifies sppp_pap_input() to skip credential comparison when received length fields are zero. Apply the upstream OpenBSD security update or rebuild the kernel from a source tree at or beyond revision 1.202 of sys/net/if_spppsubr.c. Reference the Openwall OSS-Security Discussion for vendor coordination details.

Workarounds

Replace PAP with CHAP (Challenge Handshake Authentication Protocol) on affected links, which is not affected by this length-handling flaw.
Restrict physical and logical access to PPP interfaces using port security and circuit-level access controls.
Place affected interfaces behind a separately authenticated transport such as IPsec until the kernel patch is deployed.

bash

# Verify patched if_spppsubr.c revision on OpenBSD
ident /usr/src/sys/net/if_spppsubr.c | grep '\$OpenBSD'
# Expected output should show revision 1.202 or later