Threat reportVulnerabilityTL-2026-0881
CVE-2026-55706: 27-Year-Old OpenBSD sppp(4) PAP Authentication Bypass in sppp_pap_input()
CVE-2026-55706 (TL-2026-0881), also tracked as 27-Year-Old OpenBSD PAP Authentication Bypass, is a medium-severity software vulnerability scored CVSS 5.8, first published 2026-06-17. It has no confirmed attribution, affects OpenBSD OpenBSD (sppp(4) / sys/net/if_spppsubr.c), references 1 CVE (CVE-2026-55706), maps to 14 MITRE ATT&CK techniques (T1016, T1021, T1040), and is covered by 9 detection rules and 17 indicators of compromise.
- CVSS
- 5.8/10Medium
- CVEs
- 1Referenced vulnerabilities
- Techniques
- 14MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 17Indicators of compromise
Key facts for TL-2026-0881
- Threat ID
- TL-2026-0881
- Also known as
- 27-Year-Old OpenBSD PAP Authentication Bypass, OpenBSD sppp PAP Empty-Credential Bypass
- Severity
- MEDIUM
- CVSS
- 5.8 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:L)
- Status
- PATCHED
- Category
- VULNERABILITY
- First published
- Last reviewed
- Attribution confidence
- NONE
- Motivation
- UNKNOWN
- Target sectors
- telecommunications, internet-service-providers, managed-network-services, government, critical-infrastructure
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 17
How CVE-2026-55706 works
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).
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 techniques used in TL-2026-0881
Discovery
T1016 System Network Configuration Discovery; T1046 Network Service Discovery
Lateral Movement
credential-access
Initial Access
T1078 Valid Accounts; T1133 External Remote Services; T1190 Exploit Public-Facing Application
Command and Control
T1090 Proxy; T1095 Non-Application Layer Protocol; T1572 Protocol Tunneling
Defense Evasion
T1211 Exploitation for Stealth
Credential Access
T1212 Exploitation for Credential Access; T1557 Adversary-in-the-Middle
Collection
Resource Development
Affected products and versions in CVE-2026-55706
- OpenBSD — OpenBSD (sppp(4) / sys/net/if_spppsubr.c)
Vulnerable versions: 7.6 and earlier; all releases since the 1999-07-01 import (before commit 076e2b1)
Fixed in: builds including commit 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8 (2026-06-14)
Remediation for CVE-2026-55706
Patches
- OpenBSD commit 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8 (mvs, 2026-06-14) adds exact-length pre-checks before bcmp() in sppp_pap_input()
Immediate actions
- Update OpenBSD to a build including commit 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8 (sys/net/if_spppsubr.c) or apply the corresponding -stable errata patch
- Where patching is not immediately possible, disable PAP on sppp(4)/PPPoE interfaces and require CHAP instead
- Restrict PPPoE ingress to trusted, isolated layer-2 segments so a rogue access concentrator cannot reach clients in the broadcast domain
Workarounds
- Switch sppp(4) peer authentication from PAP to CHAP
- Disable PPPoE/sppp interfaces that are not strictly required
- Confine PPPoE to point-to-point isolated VLANs / dedicated broadcast domains
Longer-term hardening
- Permanently retire cleartext PAP for PPP/PPPoE authentication and standardize on CHAP or stronger transport-protected authentication
- Segment management/PPPoE networks and enforce 802.1X / port security to prevent rogue concentrators on shared media
- Add kernel-network regression tests asserting exact-length credential validation for all PPP auth handlers (PAP and CHAP)
CVEs associated with CVE-2026-55706
Weaknesses (CWE) in CVE-2026-55706
Timeline of CVE-2026-55706
- Vulnerable sppp credential-comparison logic originates in a Cronyx Engineering synchronous-PPP implementation (circa 1994-1996) and is carried into FreeBSD.
- sppp(4) code (sys/net/if_spppsubr.c) imported into OpenBSD from FreeBSD, carrying the flawed PAP length handling in sppp_pap_input().
- Refactor to dynamic malloc credential storage replaces the legacy AUTHNAMELEN(64)/AUTHKEYLEN(16) limits with the AUTHMAXLEN(256) upper-bound check, introducing the secondary kernel heap over-read for oversized attacker-supplied lengths.
- Vulnerability responsibly reported to OpenBSD by researcher shj (shahriyar@...eray.co.uk); PoC demonstrates full PAP bypass against OpenBSD 7.6 (amd64) via a rogue PPPoE server.
- OpenBSD developer mvs commits fix 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8 adding exact-length pre-checks before bcmp() in sppp_pap_input().
- Issue posted to the oss-security mailing list by shj with technical details of the zero-length bypass and the kernel heap over-read.
- CVE-2026-55706 published (CVSS v3.1 5.8 Medium, AV:A/AC:H); Argus Systems technical analysis and initial press coverage released.
- Broader security-press and vendor advisory coverage (GBHackers, Mallory, BrinzTech) documents affected versions, the call chain, and mitigations.
Sources cited for CVE-2026-55706
- 27-Year-Old OpenBSD Vulnerability Allows Attackers to Bypass PAP Authentication Entirely
- A 27-Year-Old Authentication Bypass in OpenBSD's PPP Stack (Argus Systems)
- CVE-2026-55706 — Tenable
- CVE-2026-55706 — NVD Detail
- OpenBSD commit 076e2b1c1fc4ac0883a72d3544131ad5cee7adf8 (if_spppsubr.c PAP fix)
- oss-security — OpenBSD sppp_pap_input: PAP authentication bypass (shj)
- BrinzTech Technical Advisory — Empty-Credential Remote Auth Bypass inside OpenBSD Subsystems
- 7-Year-Old OpenBSD Security Flaw Exposes Systems to Full PAP Authentication Bypass (GBHackers)
- OpenBSD PPP PAP Flaw Allowed Authentication Bypass Across All Releases (Mallory)
Detection coverage for TL-2026-0881
As of 2026-06-17, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0881 across Splunk SPL, Microsoft KQL and Sigma, covering 17 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.