This is a receptionist telling strangers what time the wall clock says
The finding fires when a host or network appliance answers an unauthenticated ICMP Timestamp Request (type 13) with a Timestamp Reply (type 14). There is no meaningful software version boundary here: *any* OS, hypervisor, firewall, load balancer, printer, or appliance that chooses to answer the protocol can trigger it, which is why NVD maps it broadly and often without concrete versions. Tenable also notes older Windows families such as Vista/7/2008/2008 R2 deliberately returned inexact values rather than exact time.
Tenable's LOW label is already restrained, but for enterprise patch prioritization this is better treated as IGNORE. The issue is reconnaissance-only unless you can pair it with a second weakness such as obsolete time-based authentication or weak time-derived randomness, and that chaining requirement is the entire story: by itself this does not get an attacker code execution, credentials, privilege, or durable access.
4 steps from start to impact.
Send an ICMP timestamp probe
type 13 using commodity tooling such as nmap -PP or hping3 --icmp-ts. If the network path permits the packet and the target implements the message, the host may answer immediately from the IP stack or control plane without touching any application service.- Target is reachable over IP from the attacker's position
- Intervening firewalls/ACLs allow ICMP timestamp traffic
- The target stack or appliance is configured to answer
type 13
- Many perimeter firewalls already drop uncommon ICMP types
- Management interfaces are often isolated from untrusted networks
- Some modern hosts return inaccurate values or do not answer at all
nmap -PP and hping3 --icmp-ts can validate it. Network telemetry can catch type 13/14 if ICMP control-plane traffic is logged.Harvest time and minor fingerprinting data
- A valid timestamp reply is returned
- The attacker can observe the reply
- The disclosed datum is low-value by itself
- Clock skew of seconds to minutes is rarely decisive in modern environments
- Other, richer fingerprinting sources usually exist already
Chain into a separate weak design
- A second vulnerable mechanism exists that materially depends on accurate target time
- The attacker knows how to exploit that second mechanism
- This prerequisite is the main severity killer
- Modern MFA, Kerberos, SSO, and OTP ecosystems do not become breakable because a host answered
type 13 - Weak time-seeded randomness is mostly a legacy or embedded-system problem
Use it as low-grade recon, not compromise
- The attacker is conducting reconnaissance at scale
- Comparable or better host liveness and fingerprinting data is available from normal TCP/UDP probing
- The blast radius is nil unless another exploit path already exists
The supporting signals.
| In-the-wild status | No evidence of meaningful standalone exploitation was found in the reviewed sources, and this CVE is not listed in the CISA KEV catalog. |
|---|---|
| Proof-of-concept availability | Commodity probing is trivial: Nmap documents -PP for ICMP timestamp requests, and Kali's hping3 documents --icmp-ts as an alias for ICMP type 13. |
| EPSS | CVEdetails reports 0.65% EPSS with roughly 70th percentile. Absolute probability is still low; the percentile looks inflated because the long tail of ancient CVEs scores near zero. |
| KEV status | Not present in CISA KEV at time of review. |
| CVSS interpretation | NVD retains a legacy CVSS v2 2.1 / LOW vector AV:L/AC:L/Au:N/C:P/I:N/A:N. That vector is a poor fit for the practical reality here: the observable behavior is remote, but the impact is so slight that the score still lands near the floor. |
| Affected scope | Effectively any device that replies to ICMP timestamp requests. NVD lists very broad generic CPEs with no meaningful version ceilings, which is a hint that this is protocol behavior rather than a discrete software defect. |
| Fixed versions | There is no universal patched version. Most vendors treat this as configuration or control-plane hardening; some ship product-specific fixes or recommend ACL/firewall filters. Example: A10 published resolved ACOS releases, while Dell OS6 documents an ACL workaround. |
| Exposure / scanning data | The 2019 paper *Sundials in the Shade* found 2.2 million internet hosts replying to ICMP timestamp requests across 42,500+ ASes. So exposure exists, but the consequence remains recon-grade. |
| Disclosure timeline | CVE publication traces back to 1997-08-01; Nessus plugin 10114 was first published 1999-08-01 and updated 2024-10-07. |
| Research / reporting origin | This is a legacy generic issue, not a modern product-specific bug bounty or exploit-chain discovery. No current researcher attribution materially changes prioritization. |
noisgate verdict.
The decisive factor is that this finding has no standalone compromise path: it only discloses the target's clock and becomes interesting *only if* a second, separate weak design is already present. For a 10,000-host program, pushing this into the patch queue steals time from flaws that actually produce initial access, privilege gain, or lateral movement.
Why this verdict
- [object Object]
- Standalone impact is recon only: the host leaks time data, not credentials, code execution, privilege, or persistence.
- The attack path requires a second weakness: the only serious scenarios depend on obsolete time-based authentication or weak time-derived randomness elsewhere in the stack.
- This is not a real patch-management item: there is often no universal vendor patch, only protocol filtering or device-specific hardening, so treating it like a software vulnerability distorts remediation priorities.
Why not higher?
There is no KEV signal, no meaningful evidence of active campaigns built around this issue, and no direct attacker payoff from the timestamp reply alone. Even when exposed externally, the blast radius is tiny unless another defect is already available to weaponize the clock leak.
Why not lower?
It is not *nothing*: internet-facing control planes and legacy appliances do leak a real datapoint, and the behavior can aid fingerprinting and scan validation. If you are chasing external scan cleanliness or hardening network appliances, blocking type 13/14 is reasonable hygiene.
What to do — in priority order.
- Block ICMP types 13 and 14 at the perimeter — Drop inbound ICMP Timestamp Requests and outbound Timestamp Replies on edge firewalls, internet DMZs, and exposed management planes. This is the cleanest way to kill the finding and reduce recon noise; because the verdict is IGNORE, do it in the next normal network-policy change window rather than under any expedited SLA.
- Restrict appliance management interfaces — Put firewalls, load balancers, hypervisor managers, and switch/router management IPs behind admin-only networks or VPN paths. That shrinks the reachable population dramatically and matters more than chasing every host that happens to answer the protocol.
- Document a risk-acceptance rule — If the finding is on internal-only servers with no special control-plane exposure, document that the issue is reconnaissance-only and excluded from patch SLAs. This prevents recurring scanner churn from displacing real remediation work.
- Running normal OS patch rollups often does nothing; this is commonly protocol behavior or firewall policy, not a software defect with a universal patch.
- EDR is mostly irrelevant, especially for appliances and control planes that answer ICMP in the network stack before any userland telemetry exists.
- MFA does not address the issue directly; the finding is not an authentication bypass on its own.
Crowdsourced verification payload.
Run this from an auditor workstation or jump box that has network reachability to the target, not necessarily on the target itself. Invoke it exactly as sudo python3 icmp_ts_check.py 192.0.2.10; raw ICMP sockets require root/Administrator privileges. It sends one ICMP Timestamp Request and reports VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
"""
icmp_ts_check.py - Verify whether a host replies to ICMP Timestamp Requests (type 13)
Exit codes:
0 = PATCHED / no timestamp reply observed
1 = VULNERABLE / timestamp reply observed
2 = UNKNOWN / execution error or insufficient privileges
"""
import os
import socket
import struct
import sys
import time
import select
import random
from datetime import datetime, timezone
ICMP_TIMESTAMP_REQUEST = 13
ICMP_TIMESTAMP_REPLY = 14
TIMEOUT = 3.0
def checksum(data: bytes) -> int:
if len(data) % 2:
data += b"\x00"
s = 0
for i in range(0, len(data), 2):
s += (data[i] << 8) + data[i + 1]
s = (s >> 16) + (s & 0xFFFF)
s += s >> 16
return (~s) & 0xFFFF
def ms_since_midnight_utc() -> int:
now = datetime.now(timezone.utc)
return ((now.hour * 3600 + now.minute * 60 + now.second) * 1000) + (now.microsecond // 1000)
def build_request(ident: int, seq: int) -> bytes:
originate = ms_since_midnight_utc()
# type, code, checksum, identifier, sequence, originate, receive, transmit
header = struct.pack("!BBHHHIII", ICMP_TIMESTAMP_REQUEST, 0, 0, ident, seq, originate, 0, 0)
csum = checksum(header)
return struct.pack("!BBHHHIII", ICMP_TIMESTAMP_REQUEST, 0, csum, ident, seq, originate, 0, 0)
def recv_reply(sock: socket.socket, ident: int, seq: int, timeout: float):
end = time.time() + timeout
while time.time() < end:
remaining = end - time.time()
r, _, _ = select.select([sock], [], [], remaining)
if not r:
break
packet, addr = sock.recvfrom(65535)
if len(packet) < 20:
continue
ihl = (packet[0] & 0x0F) * 4
icmp = packet[ihl:]
if len(icmp) < 20:
continue
icmp_type, icmp_code, _, r_ident, r_seq, orig, recv_ts, xmit_ts = struct.unpack("!BBHHHIII", icmp[:20])
if icmp_type == ICMP_TIMESTAMP_REPLY and icmp_code == 0 and r_ident == ident and r_seq == seq:
return {
"src": addr[0],
"originate": orig,
"receive": recv_ts,
"transmit": xmit_ts,
}
return None
def main():
if len(sys.argv) != 2:
print("UNKNOWN - usage: sudo python3 icmp_ts_check.py <ip-or-hostname>")
sys.exit(2)
target = sys.argv[1]
try:
dst_ip = socket.gethostbyname(target)
except Exception as e:
print(f"UNKNOWN - cannot resolve target: {e}")
sys.exit(2)
try:
sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)
sock.settimeout(TIMEOUT)
except PermissionError:
print("UNKNOWN - raw socket requires root/Administrator")
sys.exit(2)
except Exception as e:
print(f"UNKNOWN - socket error: {e}")
sys.exit(2)
ident = random.randint(0, 0xFFFF)
seq = 1
packet = build_request(ident, seq)
try:
sock.sendto(packet, (dst_ip, 0))
reply = recv_reply(sock, ident, seq, TIMEOUT)
except Exception as e:
print(f"UNKNOWN - probe failed: {e}")
sys.exit(2)
finally:
sock.close()
if reply:
print(f"VULNERABLE - received ICMP timestamp reply from {reply['src']} (recv_ts={reply['receive']}, xmit_ts={reply['transmit']})")
sys.exit(1)
else:
print("PATCHED - no ICMP timestamp reply observed")
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
type 13/14 on internet-facing and management networks during the next routine firewall change; for an IGNORE verdict there is no noisgate mitigation SLA and no noisgate remediation SLA—document rationale only unless external exposure on appliances makes the hygiene change worth doing.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.