NTPsec ntpd CVE-2026-102484

Exploitation requires ntpd to be explicitly configured with the JJY refclock driver (type 40) in Telephone JJY mode - this is a non-default, region-specific configuration not present in typical deployments. The attacker must additionally control or impersonate the JJY time source so it can deliver more than six time replies to the driver. Limiting factors: physical/local control of the time source is needed (AV:P), the vulnerable driver must be enabled, and only NTPsec builds before 1.2.6 are affected; stock configurations without the JJY refclock are not exposed.

This is a moderate-severity, low-real-world-priority issue despite a CVSS of 6.4. The CVSS vector (AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H) hinges on AV:P (Physical) - the attacker must control the Telephone JJY time source that feeds replies to ntpd, which is a highly constrained position rather than a remotely reachable one. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, all of which align with the physical attack vector to indicate targeted-at-best rather than widespread exploitation potential. The PR:N (unauthenticated) metric is technically correct for the ntpd process (no credentials are checked), but it is misleading in isolation: the real gating factor is the prerequisite ability to control the time source, not an open network service. One signal worth verifying: the description references a 'Telephone JJY' source, which can involve a telephone/modem path - if an attacker could reach that path remotely the practical reachability would exceed what AV:P implies, so the exact deployment topology should be confirmed with the vendor. Overall this is a niche, configuration-dependent memory-corruption bug, not a drop-everything priority.

An attacker who has compromised or is impersonating the JJY time source (e.g., a connected Telephone JJY receiver or the serial/telephone path feeding it) sends more than six crafted time replies to an ntpd instance configured with the JJY refclock driver. The oversized reply sequence overflows a heap buffer in the driver, corrupting memory and either crashing ntpd (denial of service) or potentially enabling further memory manipulation. No public exploit code has been identified at time of analysis.