Loading story…
OpenBSD fixed a high-severity authentication bypass in its PPP stack after researchers disclosed that the bug had existed since the original sppp code import from FreeBSD in 1999. The flaw affects sppp_pap_input() and all OpenBSD releases through 7.6 when the system is configured as a PAP authenticator on the PPPoE data path. By trusting attacker-controlled name_len and passwd_len values in bcmp() comparisons, the code could accept zero-length credentials as valid because a zero-length bcmp() returns success, allowing remote attackers to authenticate without legitimate credentials.
The disclosure also described a secondary kernel heap over-read caused when a supplied username length exceeds the allocated size of the stored credential, a condition introduced after credential fields became dynamically allocated in 2009. Researchers said the bug could let an attacker intercept or read PPPoE traffic and could also allow a rogue PPPoE server to impersonate a legitimate server during mutual authentication. OpenBSD committed a fix to -current on 2026-06-14, and a proof of concept reportedly showed successful PAP authentication with empty credentials followed by establishment of a full network-layer link.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
OpenBSD committed a fix to -current for the high-severity sppp_pap_input() authentication bypass on 2026-06-14. The flaw affected all versions through 7.6 and allowed zero-length credentials to authenticate successfully due to attacker-controlled length values being used in bcmp() comparisons.
The vulnerability was publicly disclosed with technical details describing the PAP null-auth weakness, affected OpenBSD versions, PPPoE reachability, and a Python proof of concept that successfully authenticated with empty credentials and established a network-layer link.
A 2009 change that moved credential fields to dynamic allocation enabled a secondary kernel heap over-read condition in the same code path when a supplied PAP name length exceeded the allocated stored credential size.
The vulnerable comparison pattern in OpenBSD's PPP stack originated when sppp code was imported from FreeBSD in July 1999, introducing the PAP authentication bypass condition.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
7 references tracked. Mallory keeps watching after this page renders.
securityonline.info
Open sourcecybersecuritynews.com
Open sourceblog.argus-systems.ai
Open sourcereddit.com
Open sourcegithub.com
Open sourceseclists.org
Open sourceseclists.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
OpenBSD disclosed **CVE-2026-56099**, a medium-severity flaw in the MPLS subsystem that can expose kernel stack memory to a remote attacker when MPLS is enabled on an interface. The bug is in `mpls_do_error()` in `sys/netmpls/mpls_input.c`, where a crafted MPLS packet with **16 labels** and no **Bottom-of-Stack** bit causes the kernel to copy **17 shim headers** from a **16-entry** local stack array, leaking **4 bytes** of adjacent kernel stack data in an ICMP/MPLS error response. The issue affects OpenBSD `-current` before the fix and traces back to code introduced in 2010 in the ICMP/MPLS error-handling path. Exploitation requires an attacker to send an MPLS frame with EtherType `0x8847`, an outer label TTL of `1`, and an IPv4 inner payload; researchers at **Argus Systems** reported the vulnerability, and OpenBSD corrected it by rejecting label stacks that reach the maximum depth without a BoS bit.
Jun 29, 2026
OpenBSD disclosed a local privilege-escalation vulnerability, tracked as **CVE-2026-57589**, in its System V semaphore implementation. The bug stems from an integer overflow in the `sys_semget()` handler that can lead to kernel memory corruption and allow a local user to escalate privileges to **root** under certain conditions. A fix was committed to **OpenBSD-current**, while patches for stable branches were still pending in the reporting cited. The flaw was reportedly identified during the **Patch the Planet** event focused on AI-assisted vulnerability research, and the same reporting also referenced separate OpenBSD findings affecting **IPsec/IPComp**, **NFS**, and the **pinsyscall** and **kbind** mechanisms.
Jul 16, 2026
FreeBSD disclosed **CVE-2026-4747** in advisory **`FreeBSD-SA-26:08.rpcsec_gss`**, warning that improper bounds checking in RPCSEC_GSS packet-signature validation can copy attacker-controlled data into a fixed stack buffer and trigger a stack overflow. The bug affects all supported FreeBSD versions and can be exploited by an unauthenticated client. In the kernel, exploitation is possible when **`kgssapi.ko`** is loaded and the system is running an NFS server with RPCSEC_GSS enabled; in userspace, RPC servers linked against **`librpcsec_gss`** are also exposed, although FreeBSD said it was not aware of vulnerable base-system applications in that category. Independent technical write-ups tied the flaw to **`svc_rpc_gss_validate`** in the RPC/NFS path, describing how a crafted **RPCSEC_GSS** credential length can overflow a 128-byte stack buffer and potentially corrupt saved control data, leading to denial of service or kernel-mode remote code execution. The reports said the issue is reachable over the network, commonly via NFS on **TCP port 2049**, and could result in full system compromise if exploited successfully. FreeBSD released patches for supported stable and release branches and said there is no practical workaround beyond avoiding deployments where **`kgssapi.ko`** is loaded.
Jun 29, 2026