ssldump CVE-2026-111458

Requires that the victim run ssldump with FAN/1 X.509 fingerprinting enabled - specifically the -j (JSON output) and -N options - against an attacker-supplied pcap that contains a TLS handshake with a valid X.509 server certificate. The overflow is deterministic and fires on every invocation of fanx_fingerprint with valid certificate inputs, so no special payload tuning is needed. Limiting factors that reduce real-world risk: exploitation is local only (the attacker cannot reach the tool over the network), it depends on the victim actively choosing to process the malicious file with the non-default FAN/1 fingerprinting options, and the overflow is only 3 bytes of largely fixed content, making a crash far more likely than code execution.

This is a genuine but modest-priority memory-safety bug, not a drop-everything emergency. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:A) correctly models the real constraint: exploitation is LOCAL and requires active user interaction - a victim must voluntarily run ssldump against an attacker-supplied pcap with FAN/1 fingerprinting enabled (-j -N). There is no network-facing attack surface; ssldump is an offline/CLI analysis tool, so this is an analyst-workstation / sandbox-detonation risk rather than a server-compromise risk. No EPSS score, KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vendor-assigned VI:H/VA:H is debatable: the root cause is a fixed, deterministic 3-byte heap overflow whose overflowing bytes are the constant tail of the format string plus a NUL terminator (from the +31 vs +34 calloc miscalculation). A reliable crash (DoS) is plausible, but 'arbitrary code execution' is a worst-case claim dependent on heap layout and allocator behavior - the input data does not substantiate reliable RCE, and the 'RCE' tag should be read as theoretical worst case rather than demonstrated. Net: treat as a low-to-moderate priority fix, higher only for operators who routinely process untrusted pcaps with -j -N.

An attacker crafts a pcap file containing a TLS handshake with an X.509 server certificate and delivers it to an analyst (e.g. as a 'suspicious capture' sample). When the analyst runs ssldump with FAN/1 fingerprinting enabled (-j -N) against the file, fanx_fingerprint writes 3 bytes past an undersized heap buffer, corrupting the heap and most likely crashing the process (DoS), with arbitrary code execution as an unproven worst case. No public exploit code was identified in the provided data; exploitation requires the victim to actively open the file with the specific options.