# CVE-2026-55706: 27-Year-Old OpenBSD sppp(4) PAP Authentication Bypass in sppp_pap_input()

> A 27-year-old flaw (present since the July 1999 FreeBSD import) in OpenBSD's sppp(4) subsystem lets an unauthenticated attacker bypass PAP authentication entirely. sppp_pap_input() in sys/net/if_spppsubr.c trusts attacker-controlled length fields, so zero-length name/password values make bcmp() return 0 and the credential check always passes; a secondary heap over-read leaks adjacent kernel memory when supplied lengths exceed the credential buffer. Disclosed by researcher shj and fixed by commit 076e2b1 (mvs, 2026-06-14).

- **Published:** 2026-06-17T00:00:00Z
- **Last reviewed:** 2026-06-17T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-0881
- **ID:** TL-2026-0881
- **Severity:** MEDIUM (CVSS 5.8)
- **Category:** VULNERABILITY
- **Status:** PATCHED
- **Detections:** 9 · **IOCs:** 17 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-55706

## Description

CVE-2026-55706 is an authentication-bypass vulnerability in the OpenBSD kernel's synchronous-PPP driver, sppp(4), implemented in sys/net/if_spppsubr.c. The defect lives in sppp_pap_input(), the handler for inbound PAP (Password Authentication Protocol) Authenticate-Request frames on PPP and PPPoE links.

Root cause — protocol-controlled length trusted in credential comparison: The validation logic compared the supplied username and password against the configured peer credentials using bcmp(), but used the length fields taken directly from the incoming PAP frame:

    if (name_len > AUTHMAXLEN || passwd_len > AUTHMAXLEN ||
        bcmp(name, sp->hisauth.name, name_len) != 0 ||
        bcmp(passwd, sp->hisauth.secret, passwd_len) != 0)

The guard only enforced an UPPER bound (AUTHMAXLEN, 256 bytes) and never checked for a lower/exact length. Because bcmp(buf, ref, 0) unconditionally returns 0 (equal) regardless of buffer contents, an attacker who sends a PAP Authenticate-Request with name_len = 0 and passwd_len = 0 makes both comparisons succeed regardless of the real configured secret, and the stack issues a PAP_ACK — establishing a fully authenticated PPP session without any valid credentials.

Secondary heap over-read: A 2009-02-16 refactor that moved credential storage to dynamic allocation (malloc) and replaced the older fixed limits AUTHNAMELEN (64) and AUTHKEYLEN (16) with the AUTHMAXLEN (256) boundary introduced a kernel-memory disclosure. Because the same attacker-controlled length drives bcmp(), an oversized value (e.g. name_len = 200 against an 8-byte stored credential) reads ~192 bytes past the allocation, exposing adjacent kernel heap contents to comparison/oracle behavior.

Reachability and attack model: The vulnerable code is reached over the PPPoE data path pppoe_data_input -> pppoeintr -> sppp_input -> sppp_pap_input, requiring no prior credentials or access. An attacker who stands up a rogue PPPoE access concentrator within the victim's layer-2 broadcast domain can complete PPPoE discovery (PADI/PADO/PADR/PADS), perform LCP negotiation, drive the PAP exchange with empty credentials, and bring up an IP-configured link. A published proof of concept against OpenBSD 7.6 (amd64) demonstrated a rogue PPPoE server sending zero-length PAP credentials, receiving a PAP_ACK, completing IPCP to a "FULL LINK ESTABLISHED" state, and exchanging ICMP echo traffic over the established session.

Provenance: The flawed comparison originated in a Cronyx Engineering sppp implementation from 1994-1996, was carried into FreeBSD, and imported into OpenBSD on 1999-07-01, remaining effectively unchanged for ~27 years. The companion CHAP handler already performed the correct exact-length pre-check (if (name_len != strlen(sp->hisauth.name) || bcmp(name, sp->hisauth.name, name_len) != 0)); the PAP path never received the same treatment.

Resolution: Reported to OpenBSD on 2026-06-12 by researcher shj (shahriyar@...eray.co.uk) and fixed two days later by developer mvs in commit 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8 (2026-06-14), which adds exact-length pre-checks before any bcmp() call — rejecting zero-length and oversized inputs and closing both the bypass and the over-read. The issue was posted to the oss-security mailing list on 2026-06-16 and CVE-2026-55706 was published 2026-06-17. The practical effect — a remote-on-link, unauthenticated, full PAP bypass plus kernel-heap disclosure — is severe for any deployment using sppp/PPPoE with PAP, though scored Medium due to the Adjacent attack vector and high attack complexity (the attacker must be on the same broadcast domain).

## MITRE ATT&CK

- T1583 Acquire Infrastructure
- T1190 Exploit Public-Facing Application
- T1078 Valid Accounts
- T1133 External Remote Services
- T1557 Adversary-in-the-Middle
- T1212 Exploitation for Credential Access
- T1211 Exploitation for Stealth
- T1046 Network Service Discovery
- T1016 System Network Configuration Discovery
- T1557 Adversary-in-the-Middle
- T1040 Network Sniffing
- T1021 Remote Services
- T1090 Proxy
- T1572 Protocol Tunneling
- T1095 Non-Application Layer Protocol

## Sources

- [27-Year-Old OpenBSD Vulnerability Allows Attackers to Bypass PAP Authentication Entirely](https://cybersecuritynews.com/27-year-old-openbsd-vulnerability/)
- [A 27-Year-Old Authentication Bypass in OpenBSD's PPP Stack (Argus Systems)](https://blog.argus-systems.ai/blog/openbsd-pap-27-year-auth-bypass.html)
- [CVE-2026-55706 — Tenable](https://www.tenable.com/cve/CVE-2026-55706)
- [CVE-2026-55706 — NVD Detail](https://nvd.nist.gov/vuln/detail/CVE-2026-55706)
- [OpenBSD commit 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8 (if_spppsubr.c PAP fix)](https://github.com/openbsd/src/commit/076e2b1c1fc4ac0883a72d3544131ad5cee7adf8)
- [oss-security — OpenBSD sppp_pap_input: PAP authentication bypass (shj)](https://www.openwall.com/lists/oss-security/2026/06/16/)
- [BrinzTech Technical Advisory — Empty-Credential Remote Auth Bypass inside OpenBSD Subsystems](https://www.brinztech.com/breach-alerts/brinztech-technical-advisory-protocol-parameter-inversion-multi-decade-kernel-boundary-erasure-and-the-empty-credential-remote-auth-bypass-inside-openbsd-subsystems)
- [7-Year-Old OpenBSD Security Flaw Exposes Systems to Full PAP Authentication Bypass (GBHackers)](https://gbhackers.com/7-year-old-openbsd-security-flaw/)
- [OpenBSD PPP PAP Flaw Allowed Authentication Bypass Across All Releases (Mallory)](https://www.mallory.ai/stories/019ed242-db3a-7cdb-9d87-852777ed38b1)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-0881