CVE-2026-55706: 27-Year-Old OpenBSD sppp(4) PAP Authentication Bypass in sppp_pap_input() — Threadlinqs Intelligence
As of 2026-06-19, CVE-2026-55706: 27-Year-Old OpenBSD sppp(4) PAP Authentication Bypass in sppp_pap_input() is a medium-severity vulnerability threat, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 17 indicators of compromise.
Threat ID: TL-2026-0881 · Severity: MEDIUM · CVSS: 5.8 · Status: PATCHED · Category: VULNERABILITY
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
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).
Weaknesses (CWE)
CWE-287, CWE-1284, CWE-125
Target sectors: telecommunications, internet-service-providers, managed-network-services, government, critical-infrastructure
Target regions: Global
Detections & IOCs
As of 2026-07-28, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 17 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
VULNERABILITY, MEDIUM, threat intelligence, cybersecurity, CVE-2026-55706, T1583, T1190, T1078, T1133, T1557, T1212, T1211, T1046, T1016, T1557