OpenBSD PPP Bug Lets Attackers Bypass PAP Authentication With Empty Credentials

A decades-old OpenBSD flaw can let attackers bypass Password Authentication Protocol authentication in certain PPP and PPPoE setups by sending empty username and password fields.

The vulnerability, tracked as CVE-2026-55706, affects the sppp_pap_input() function in OpenBSD’s synchronous PPP subsystem. According to Argus, the bug dates back to the original sppp code import in July 1999.

The flaw allows a PAP authentication request with zero-length name and password fields to pass validation. In the tested scenario, OpenBSD accepted the request, completed the PPP handshake, and established a working network-layer link without valid credentials.

How the OpenBSD PAP Authentication Bypass Works

PAP is one of the authentication methods used in Point-to-Point Protocol links. The OpenBSD pppd manual explains that PPP can authenticate a peer and negotiate IP addresses for a point-to-point connection.

The vulnerable OpenBSD code compared the supplied username and password against stored credentials using bcmp(), but it used length values taken directly from the incoming PAP frame. Those values were controlled by the attacker.

Because bcmp() succeeds when asked to compare zero bytes, an attacker could send both fields with a length of zero. The existing upper-bound check rejected oversized values, but it did not reject zero-length values.

Item	Details
CVE	CVE-2026-55706
Component	OpenBSD sppp_pap_input() in sys/net/if_spppsubr.c
Bug type	PAP authentication bypass and secondary kernel heap over-read
Attack condition	PPP/PPPoE path using PAP authentication
Reported	June 12, 2026
Fixed	June 14, 2026 in OpenBSD -current

The Bug Survived Since 1999

The oss-sec disclosure says the vulnerable comparison pattern entered OpenBSD with the original sppp code import on July 1, 1999. The code originated from FreeBSD and was derived from earlier Cronyx Engineering work from the mid-1990s.

Researchers confirmed the zero-length bypass against OpenBSD 7.6 on amd64 in a QEMU/KVM test environment. The advisory says earlier versions are likely affected because the same logic existed for years.

A secondary issue appeared from the same root cause. If an attacker supplied a length larger than the stored credential allocation, bcmp() could read beyond the intended kernel heap object. Argus said this became possible after a 2009 change moved authentication fields from fixed-size arrays to dynamically allocated strings.

• The attacker-controlled name_len and passwd_len fields were used as comparison lengths.
• Zero-length fields caused bcmp() to return success.
• The PAP handler did not first check whether the supplied lengths matched the stored credential lengths.
• The CHAP handler already used a safer exact-length check.
• A separate over-read condition could expose adjacent kernel heap data in some cases.

What an Attack Could Look Like

The exploit path runs through PPPoE data handling and reaches sppp_pap_input(). The attacker does not need to know a valid PAP username or password, but the target must be using the affected PPP authentication path.

In one scenario, an attacker on the same broadcast domain can act as a rogue PPPoE server. If the OpenBSD client uses PAP in a vulnerable way, the attacker can complete discovery, negotiate the link, send empty PAP credentials, and get authentication accepted.

The Argus technical write-up said the proof of concept established a full link, completed IP configuration, and received an ICMP echo reply after authentication succeeded with empty credentials.

1. The attacker positions a rogue PPPoE server on the same broadcast domain.
2. The OpenBSD system begins PPPoE discovery and link negotiation.
3. The attacker sends a PAP authentication request with empty credential fields.
4. OpenBSD accepts the request because zero-length comparisons succeed.
5. The PPP link reaches the network layer.
6. Traffic can then pass through the attacker-controlled endpoint in the tested scenario.

Why This Is Not a Normal Password Bypass

The bug does not mean any attacker can log in to any OpenBSD machine over SSH, a web interface, or a normal internet-facing service. It applies to a specific kernel PPP authentication path.

That limitation matters, but it does not make the flaw harmless. PPPoE is still used in some broadband, network access, lab, and embedded environments. Systems using OpenBSD as a PPP endpoint should treat the issue seriously if PAP authentication is enabled.

The risk also increases in environments where an attacker can reach the same Layer 2 segment as the PPPoE negotiation. In that case, a rogue endpoint may be able to impersonate the expected peer and intercept traffic.

Misconception	Reality
Any OpenBSD login can be bypassed	The issue affects the PPP PAP path, not general system login
The attacker needs valid credentials	The bypass works by sending zero-length PAP credential fields
The attack works from anywhere on the internet	The attacker must be in position to interact with the PPPoE link
Only authentication is affected	The same root cause can also create a kernel heap over-read

OpenBSD Fixed the Vulnerable Check

The OpenBSD source commit fixes the logic by checking that the received username and password lengths match the configured credential lengths before bcmp() compares the data.

This approach mirrors the safer pattern already used by the CHAP authentication handler in the same file. It blocks zero-length credential bypasses and prevents bcmp() from reading beyond the stored credential allocation.

The Argus advisory says the issue was reported with a proof of concept on June 12, 2026, and fixed on June 14, 2026. The public disclosure followed after the fix was committed.

What OpenBSD Administrators Should Do

Administrators should update OpenBSD systems that rely on PPP or PPPoE with PAP authentication. Systems that do not use the affected PPP authentication path face much lower practical exposure, but patching remains the safest option.

Network teams should also review whether PAP is still necessary. PAP sends credentials in a weaker authentication flow than modern alternatives, and many environments should avoid it when stronger options are available.

The oss-sec post lists the affected function, reachability path, impact, and fix timeline. Administrators should use it to identify whether their PPPoE configurations match the vulnerable conditions.

• Apply the OpenBSD fix or update to a release that includes it.
• Review PPP and PPPoE configurations that use PAP authentication.
• Reduce exposure to untrusted Layer 2 networks where PPPoE discovery can occur.
• Prefer stronger authentication methods where possible.
• Check logs and network captures for unexpected PPPoE negotiation behavior.
• Audit environments where OpenBSD acts as a PPPoE client or authenticator.

Why the 27-Year-Old Bug Matters

The vulnerability shows how small length-validation mistakes can survive for decades in mature networking code. The vulnerable check looked like a normal bounds check, but it checked only the maximum size and missed the exact-length requirement needed for credential comparison.

It also shows why legacy protocols and rarely touched code paths deserve security review. PPP and PAP may not be the center of modern enterprise networking, but they still exist in real systems, and attackers often look for forgotten paths.

The OpenBSD patch is small, but the impact of the bug could be significant in the right network position. The safer lesson from the PPP authentication documentation is clear: authentication checks must verify both value and length before accepting a peer.

FAQ