NTPsec EUVD-2026-115826

Exploitation requires the NTPsec client (versions before 1.2.4) to initiate an NTS-KE handshake with an NTS-KE server the attacker controls - i.e., the client must be configured to use that server, or the attacker must impersonate a legitimate NTS-KE server with a TLS certificate the client trusts. The trigger is a server-supplied NTS-KE record whose declared length field exceeds the number of bytes actually received, which drives the parser to over-read client stack memory. Key limiting factors: NTS-KE runs over TLS, so a passive network position or plain MITM without a trusted certificate is insufficient; the data disclosed is low-value in itself (a stack over-read, no code execution) and is useful mainly to defeat ASLR when chained with another bug. No special condition is needed on the client beyond being an NTS client that connects to the malicious endpoint.

This is a genuinely low-priority finding, and the signals are consistent rather than conflicting. The CVSS 3.1 base score of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) describes a network-reachable but high-complexity information-disclosure bug with only low confidentiality impact and no integrity or availability impact, which matches the description: an out-of-bounds read (CWE-125) that leaks client stack memory. The vuln.today Decision label is 'monitor', the lowest urgency tier, and nothing contradicts it. There is no CISA KEV listing, so this is not confirmed as actively exploited; no EPSS score was supplied, so exploitation probability cannot be quantified from the input; and no public exploit code is identified - the three references are the NTPsec fix commit and two GitLab work items, not weaponized PoC. The one nuance worth flagging for defenders is that AV:N is technically correct but somewhat misleading in isolation: exploitation requires the victim client to establish an NTS-KE (TLS) session with an attacker-controlled server, which is a meaningful real-world precondition and is what justifies AC:H. The practical value of the leak is that disclosed pointers defeat ASLR, so its real risk is as a stepping stone for chaining with a separate memory-corruption bug, not as a standalone threat.

A victim's NTPsec client (before 1.2.4) performs NTS key establishment against an NTS-KE server that the attacker controls or can impersonate over TLS. The malicious server returns an NTS-KE record whose declared length exceeds the bytes actually sent, causing the client parser to read past the buffer into adjacent stack memory, and the client then transmits those leaked bytes - including pointers that defeat ASLR - back in cleartext as NTS cookies for the attacker to harvest. No public exploit identified at time of analysis; the high attack complexity (AC:H) reflects that the victim must connect to the attacker's NTS-KE endpoint.