CVE-2016-10142

CVE-2016-10142

Published Jan 14, 2017 · Updated Aug 6, 2024

An issue was discovered in the IPv6 protocol specification, related to ICMP Packet Too Big (PTB) messages. (The scope of this CVE is all affected IPv6 implementations from all vendors.) The security implications of IP fragmentation have been discussed at length in [RFC6274] and [RFC7739]. An attacker can leverage the generation of IPv6 atomic fragments to trigger the use of fragmentation in an arbitrary IPv6 flow (in scenarios in which actual fragmentation of packets is not needed) and can subsequently perform any type of fragmentation-based attack against legacy IPv6 nodes that do not implement [RFC6946]. That is, employing fragmentation where not actually needed allows for fragmentation-based attack vectors to be employed, unnecessarily. We note that, unfortunately, even nodes that already implement [RFC6946] can be subject to DoS attacks as a result of the generation of IPv6 atomic fragments. Let us assume that Host A is communicating with Host B and that, as a result of the widespread dropping of IPv6 packets that contain extension headers (including fragmentation) [RFC7872], some intermediate node filters fragments between Host B and Host A. If an attacker sends a forged ICMPv6 PTB error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario. Another possible scenario is that in which two BGP peers are employing IPv6 transport and they implement Access Control Lists (ACLs) to drop IPv6 fragments (to avoid control-plane attacks). If the aforementioned BGP peers drop IPv6 fragments but still honor received ICMPv6 PTB error messages, an attacker could easily attack the corresponding peering session by simply sending an ICMPv6 PTB message with a reported MTU smaller than 1280 bytes. Once the attack packet has been sent, the aforementioned routers will themselves be the ones dropping their own traffic.

CVSS severityUnavailable
Unscored
EPSS probability2.75%
Next 30 days · Sep 16, 2026
Known exploitationUnconfirmed
Based on sourced intelligence
Hinoki checkNot available
Coverage for this vulnerability

See if you're affected

Explore vulnerability checks for your environment with Hinoki.

Book a demo

Summary

What happened

An issue was discovered in the IPv6 protocol specification, related to ICMP Packet Too Big (PTB) messages. (The scope of this CVE is all affected IPv6 implementations from all vendors.) The security implications of IP fragmentation have been discussed at length in [RFC6274] and [RFC7739]. An attacker can leverage the generation of IPv6 atomic fragments to trigger the use of fragmentation in an arbitrary IPv6 flow (in scenarios in which actual fragmentation of packets is not needed) and can subsequently perform any type of fragmentation-based attack against legacy IPv6 nodes that do not implement [RFC6946]. That is, employing fragmentation where not actually needed allows for fragmentation-based attack vectors to be employed, unnecessarily. We note that, unfortunately, even nodes that already implement [RFC6946] can be subject to DoS attacks as a result of the generation of IPv6 atomic fragments. Let us assume that Host A is communicating with Host B and that, as a result of the widespread dropping of IPv6 packets that contain extension headers (including fragmentation) [RFC7872], some intermediate node filters fragments between Host B and Host A. If an attacker sends a forged ICMPv6 PTB error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario. Another possible scenario is that in which two BGP peers are employing IPv6 transport and they implement Access Control Lists (ACLs) to drop IPv6 fragments (to avoid control-plane attacks). If the aforementioned BGP peers drop IPv6 fragments but still honor received ICMPv6 PTB error messages, an attacker could easily attack the corresponding peering session by simply sending an ICMPv6 PTB message with a reported MTU smaller than 1280 bytes. Once the attack packet has been sent, the aforementioned routers will themselves be the ones dropping their own traffic.

The record

CVE
CVE-2016-10142
Published
Jan 14, 2017
Updated
Aug 6, 2024
Vendor
Unknown vendor
Product
Unknown product
Classifications
Unavailable
Attack vector
Unavailable
Privileges
Unavailable

Timeline

How it unfolded

  1. Jan 14, 2017CVE publishedPublication date reported by the CVE source.
  2. Aug 6, 2024Record updatedLatest update available in the CVE record.

Exploitability

Present is not the same as exploitable

Compare your product and version with the public record. A matching version still requires validation against your environment.

Is a vulnerable build present?

Affected buildAffected product and version details are unavailable.

What conditions does exploitation require?

Attack vectorUnavailable in this record.
Required privilegesUnavailable in this record.

What is affected?

Affected products and versions are unavailable in this record.

Published CVSS scores

No CVSS assessment is available in this record.

CVSS describes severity. EPSS estimates exploitation probability.

Attacks

What attackers are doing with it

Daily unique IPs observed by Shadowserver honeypots for known exploited vulnerabilities (KEVs). Missing observations do not establish an absence of attacks.

Daily unique IPsNo honeypot observations are available for this CVE in the selected window.

No observations available

Sep 9, 2026Sep 15, 2026
Latest reporting daySep 15, 2026
Latest daily unique IPsUnavailable
Prior 30-day averageUnavailable
SourceShadowserver honeypots (KEV)
VectorUnavailable
PrivilegesUnavailable
Known exploitationUnconfirmed
Public exploitUnconfirmed

Weakness, pattern, technique

No sourced classifications are available.

Public exploit references

No public exploit references are available in this record.

Labels summarize the accepted research assessment. They do not indicate a test against your environment.

Technologies

Your stack

See the directory against your own environment.

Your stack

Check the software in your environment

Book a demo to see how Hinoki identifies affected software and validates exploitability in your environment.

Book a demo