OpenBSD has spent a quarter-century building a brand on being the operating system that got authentication right. So there is a particular sting to CVE-2026-55706: a one-line authentication bypass that has been sitting in the kernel’s PPP stack since a July 1999 import from FreeBSD, disclosed this week by researchers at Argus with full technical details and a working proof-of-concept. The bug let a peer defeat PAP login without knowing a single credential. It survived 27 years because nobody looked, and the fix it finally got was the same fix its sibling code had all along.
A length the attacker controls
The flaw lives in sppp_pap_input() inside the sppp(4) subsystem — the code that drives synchronous PPP links, the thing underneath PPPoE. When OpenBSD acts as a PAP authenticator, it validates the peer’s supplied name and password with bcmp. The problem is where the comparison length comes from: straight out of the incoming PAP frame. The attacker sets it.
bcmp returns 0 — “equal” — whenever the length is zero. So a peer that sends empty name and password fields makes both comparisons pass on a zero-byte compare. The failure branch never executes, OpenBSD answers with a PAP_ACK, and the session authenticates with no credentials whatsoever. It is the textbook shape of an authentication bypass, hiding in plain sight in the one OS whose users assume it cannot happen.
The same attacker-controlled length yields a second bug. Hand the parser an oversized name length and bcmp reads past the allocated buffer, leaking adjacent kernel heap memory back into the exchange — an information disclosure primitive bolted onto the bypass for free.
Reachable over PPPoE, no credentials required
Both bugs sit on the PPPoE data path, which sets the realistic threat model. An attacker who can run a rogue PPPoE server in the same broadcast domain can impersonate a legitimate concentrator. Once the handshake completes, the victim routes its traffic through the attacker’s endpoint — interception, or a full man-in-the-middle position on whatever rides that link.
That is a network-adjacent attack, not an internet-wide one. You need Layer 2 reach into the segment. MITRE rates it CVSS 5.8 (medium) for exactly that reason, and EPSS sits near 0.2% with no confirmed exploitation yet. Do not let the medium score lull you if you run PAP over PPPoE across segments you do not fully trust — a shared metro Ethernet, a wholesale access network, a lab VLAN with guests on it. On those, “network-adjacent” is just “reachable.”
The tell: CHAP was always correct
The most damning detail is in the same file. The CHAP handler right next to the vulnerable code always used an exact-length check and was never affected. The PAP handler simply never received the same treatment. A 2009 refactor that moved credentials to dynamic allocation is what introduced the heap over-read on top of the original bypass. Two bugs, one root cause, 27 years, and a correct implementation sitting inches away the whole time. The researchers verified the attack against OpenBSD 7.6 (amd64) under QEMU/KVM and published a PoC that completes the handshake and forces a PAP_ACK with empty fields.
What to do now
OpenBSD developer mvs committed a fix on June 14, 2026 — two days after responsible disclosure — adding exact-length checks before each comparison, which closes the bypass and the over-read together. Pull a patched build and update promptly; this is a kernel fix, so it means a kernel you are actually running, not one sitting in a snapshot.
If you cannot update immediately, treat any Layer 2 segment carrying PAP-over-PPPoE as untrusted and watch for rogue access concentrators appearing in the broadcast domain. Better still, stop authenticating with PAP where you have the choice — CHAP in the same stack was never vulnerable, which is the whole point of the story. The PoC is public. The window where this stays theoretical is closing.
Sources: Argus Systems research writeup, SecurityOnline coverage, and the OpenBSD source commit fixing sppp_pap_input().