CVE-2013-1428: tinc VPN stack buffer overflow in receive_tcppacket

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 19 September 2026. Confidence: medium.

high priorityRemote authenticated code execution or DoS in a VPN daemon with a high EPSS score, though exploitation is not confirmed and a valid peer account is required.

What it is

tinc before 1.0.21 and 1.1 before 1.1pre7 has a stack-based buffer overflow in receive_tcppacket in net_packet.c. A remote authenticated peer can send a large TCP packet to crash the daemon or possibly execute arbitrary code. The flaw matters because tinc peers are trusted nodes, so a single compromised or malicious peer can take down or compromise the VPN mesh.

Impact

An attacker who is an authenticated tinc peer can cause a denial of service by crashing the daemon, and may be able to execute arbitrary code in the context of the tinc process. That could disrupt the VPN and potentially give the attacker a foothold on the peer host.

Attack surface

Reachable over the network via the tinc TCP control/data channel; the CVSS vector AV:N/AC:L/Au:S indicates no user interaction but a single authenticated peer account is required. The attacker must already be a valid peer in the tinc network.

Exploitation

Not listed in CISA KEV and no ransomware associations are documented. EPSS is high (0.60679, 99.1st percentile), but the record contains no public exploit or in-the-wild exploitation references, so exploitation is not confirmed.

What to do

• Upgrade tinc to 1.0.21 or later, or 1.1pre7 or later, which contain the fix.
• Apply vendor and distribution patches (Debian DSA-2663, Fedora package updates) if immediate upgrade is not possible.
• Restrict which peers can connect to the tinc daemon and treat peer credentials as high-value; a compromised peer is the required precondition.
• Monitor tinc daemon logs for crashes or abnormal restarts and investigate any peer that triggers them.

Detection

• Watch for tinc daemon crashes, core dumps, or unexpected restarts and correlate with peer connection events.
• Inspect network traffic for unusually large TCP packets sent to the tinc port from peer addresses.
• Audit tinc peer configuration and connection logs for unexpected or unauthorized peers.
• Use host-based monitoring to detect abnormal child processes or memory corruption indicators in the tinc process.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.