A pre-authentication global buffer overflow in pppd's LCP Configure-NAK construction, verified on the 2.5.4-dev master snapshot of 2026-08-13 (latest release: 2.5.3 of 2026-05-26; current master lcp.c still carries the unguarded writes). lcp_reqci() builds the NAK reply in a fixed static u_char nak_buffer[PPP_MRU] (1500 bytes) and never checks remaining space at any of its PUTCHAR/PUTSHORT/PUTLONG sink sites. Each rejected 4-byte CI_AUTHTYPE option is answered with a 5-byte suggestion (4→5 amplification), and the option loop does not reject duplicate options — so a single legal Configure-Request (N repeated PAP-AUTHTYPE options, packet <= default MRU 1500) makes pppd write 5 bytes per 4-byte option: N=374 writes 1870 bytes into the 1500-byte .bss buffer (370-byte global OOB write), N=301 is the minimal trigger. A second overflow follows at lcp.c:1855-1856, where the whole nak_buffer is copied back into the 1504-byte input buffer. Both were reproduced with AddressSanitizer on the unmodified pppd/lcp.o + pppd/fsm.o.

The attacker is the PPP link peer and LCP is processed before any authentication. Precondition: the victim runs the CHAP-only hardening configuration (refuse-pap + refuse-eap, equivalently require-chap with PAP/EAP refused) — a legitimate, commonly recommended hardening; the default accept-anything configuration does not trigger this path. No advisory on the repo covers LCP (both existing GHSAs are radius-plugin only; CVE-2020-8597 was in eap.c), and no commit in history touches the nakp writes.