{"vulnerability": "cve-2003-0001", "sightings": [{"uuid": "72772432-63c7-4863-a3f7-f53119d17a79", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2003-0001", "type": "seen", "source": "https://t.me/cibsecurity/46659", "content": "\u203c CVE-2022-22216 \u203c\n\nAn Exposure of Sensitive Information to an Unauthorized Actor vulnerability in the PFE of Juniper Networks Junos OS on PTX Series and QFX10k Series allows an adjacent unauthenticated attacker to gain access to sensitive information. PTX1000 and PTX10000 Series, and QFX10000 Series and PTX5000 Series devices sometimes do not reliably pad Ethernet packets, and thus some packets can contain fragments of system memory or data from previous packets. This issue is also known as 'Etherleak' and often detected as CVE-2003-0001. This issue affects: Juniper Networks Junos OS on PTX1000 and PTX10000 Series: All versions prior to 18.4R3-S11; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S6; 20.1 versions prior to 20.1R3-S2; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S2; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R1-S1, 21.2R2. Juniper Networks Junos OS on QFX10000 Series and PTX5000 Series: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S10; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S4; 19.4 versions prior to 19.4R2-S6, 19.4R3-S6; 20.1 versions prior to 20.1R3-S2; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R2.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-07-20T18:11:59.000000Z"}, {"uuid": "da67800e-50d0-48c1-a54c-5e60bd0283f9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2003-0001", "type": "seen", "source": "https://t.me/hacking_Attack/186842", "content": "EtherLeak: IP Total Length Over-read via Ethernet Frame Padding | Netacoding\nhttps://www.reddit.com/r/redteamsec/comments/1tzh41w/etherleak_ip_total_length_overread_via_ethernet/\n\nBackground In 2003, CVE-2003-0001 documented that multiple NIC drivers leaked kernel memory through Ethernet frame padding \u2014 extractable via ICMP Echo. In 2021, Palo Alto disclosed CVE-2021-3031: the same class of issue on PA-series firewalls, affecting every model from PA-200 to PA-7000. In 2026, independent research confirmed the mechanism alive in enterprise network infrastructure. The vulnerability has a name \u2014 EtherLeak \u2014 a simple root cause, and a consistent lifecycle: discovered, patched in one product, rediscovered in another. This post documents the mechanism in full. The Ethernet Minimum Frame Problem Ethernet has a minimum frame size requirement of 60 bytes (excluding the 4-byte FCS). This minimum exists for collision detection in half-duplex environments (the slot time constraint from 10BASE5). When the actual payload is smaller than the minimum, the NIC pads the frame to reach 60 bytes: [ Ethernet Header (14B) ][ IP Header (20B) ][ ICMP Header (8B) ][ Padding (18B) ] = 14 + 20 + 8 + 18 = 60 bytes \u2713  The critical question: what goes into those 18 bytes of padding? The answer depends on the NIC driver and operating system:  Well-implemented stacks: padding is zeroed before transmission. Poorly-implemented or legacy drivers: padding contains whatever was in the DMA ring buffer slot from the previously processed frame.  In the latter case, those 18 bytes can contain fragments of:  Previous frame payloads (management traffic, credentials, session tokens) Source/destination MAC addresses and IP addresses from adjacent frames Partial application-layer data from in-flight management connections  The Vulnerability Mechanism IP Total Length vs. Actual Frame Data The IP header contains a Total Length field (bytes 2-3) declaring the total size of the IP datagram. The ICMP Echo handler uses this field to determine how much payload to echo back: icmp_payload_length = IP_Total_Length - IP_Header_Length - ICMP_Header_Length = IP_Total_Length - 20 - 8 = IP_Total_Length - 28  A standards-compliant implementation validates this value against the actual received frame length. A vulnerable implementation trusts it unconditionally. When an attacker sends a packet with IP_Total_Length inflated beyond the actual IP data: Attacker sends: Actual IP data: 28 bytes (IP header + ICMP header, no payload) IP_Total_Length: 46 (claims 18 bytes of payload exist) Wire frame: 42 bytes actual + 18 bytes NIC padding = 60 bytes Vulnerable handler calculates: icmp_payload = 46 - 28 = 18 bytes Reads 18 bytes starting after the ICMP header \u2192 Reads INTO the NIC padding area \u2192 Echoes back whatever is there  The reply mirrors the inflated IP_Total_Length, confirming the over-read occurred. Threshold Determination The maximum exploitable IP_Total_Length is bounded by the Ethernet minimum frame size: Maximum IP_Total_Length = Ethernet minimum frame - Ethernet header = 60 - 14 = 46 bytes \u2192 Maximum over-read = 46 - 28 = 18 bytes  Values above 46 cause the handler to read beyond the minimum Ethernet frame boundary \u2014 at which point behavior becomes implementation-specific. Empirically, many stacks drop these packets silently.   IP_Total_Length Actual IP Data Over-read Expected Behavior    28 28 0 bytes Normal reply   29 28 1 byte Reply \u2014 1B over-read   36 28 8 bytes Reply \u2014 8B over-read   46 28 18 bytes Reply \u2014 maximum over-read   48+ 28 \u2014 Typically dropped   more on blog...    submitted by    /u/Pale_Surround_3924  (https://www.reddit.com/user/Pale_Surround_3924) \n [link] (https://netacoding.com/posts/etherleak-reloaded/)   [comments] (https://www.reddit.com/r/redteamsec/comments/1tzh41w/etherleak_ip_total_length_overread_via_ethernet/)", "creation_timestamp": "2026-09-01T20:00:07.952398Z"}, {"uuid": "74c7eb4f-153d-4c88-b611-ed0834610160", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2003-0001", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/186842", "content": "EtherLeak: IP Total Length Over-read via Ethernet Frame Padding | Netacoding\nhttps://www.reddit.com/r/redteamsec/comments/1tzh41w/etherleak_ip_total_length_overread_via_ethernet/\n\nBackground In 2003, CVE-2003-0001 documented that multiple NIC drivers leaked kernel memory through Ethernet frame padding \u2014 extractable via ICMP Echo. In 2021, Palo Alto disclosed CVE-2021-3031: the same class of issue on PA-series firewalls, affecting every model from PA-200 to PA-7000. In 2026, independent research confirmed the mechanism alive in enterprise network infrastructure. The vulnerability has a name \u2014 EtherLeak \u2014 a simple root cause, and a consistent lifecycle: discovered, patched in one product, rediscovered in another. This post documents the mechanism in full. The Ethernet Minimum Frame Problem Ethernet has a minimum frame size requirement of 60 bytes (excluding the 4-byte FCS). This minimum exists for collision detection in half-duplex environments (the slot time constraint from 10BASE5). When the actual payload is smaller than the minimum, the NIC pads the frame to reach 60 bytes: [ Ethernet Header (14B) ][ IP Header (20B) ][ ICMP Header (8B) ][ Padding (18B) ] = 14 + 20 + 8 + 18 = 60 bytes \u2713  The critical question: what goes into those 18 bytes of padding? The answer depends on the NIC driver and operating system:  Well-implemented stacks: padding is zeroed before transmission. Poorly-implemented or legacy drivers: padding contains whatever was in the DMA ring buffer slot from the previously processed frame.  In the latter case, those 18 bytes can contain fragments of:  Previous frame payloads (management traffic, credentials, session tokens) Source/destination MAC addresses and IP addresses from adjacent frames Partial application-layer data from in-flight management connections  The Vulnerability Mechanism IP Total Length vs. Actual Frame Data The IP header contains a Total Length field (bytes 2-3) declaring the total size of the IP datagram. The ICMP Echo handler uses this field to determine how much payload to echo back: icmp_payload_length = IP_Total_Length - IP_Header_Length - ICMP_Header_Length = IP_Total_Length - 20 - 8 = IP_Total_Length - 28  A standards-compliant implementation validates this value against the actual received frame length. A vulnerable implementation trusts it unconditionally. When an attacker sends a packet with IP_Total_Length inflated beyond the actual IP data: Attacker sends: Actual IP data: 28 bytes (IP header + ICMP header, no payload) IP_Total_Length: 46 (claims 18 bytes of payload exist) Wire frame: 42 bytes actual + 18 bytes NIC padding = 60 bytes Vulnerable handler calculates: icmp_payload = 46 - 28 = 18 bytes Reads 18 bytes starting after the ICMP header \u2192 Reads INTO the NIC padding area \u2192 Echoes back whatever is there  The reply mirrors the inflated IP_Total_Length, confirming the over-read occurred. Threshold Determination The maximum exploitable IP_Total_Length is bounded by the Ethernet minimum frame size: Maximum IP_Total_Length = Ethernet minimum frame - Ethernet header = 60 - 14 = 46 bytes \u2192 Maximum over-read = 46 - 28 = 18 bytes  Values above 46 cause the handler to read beyond the minimum Ethernet frame boundary \u2014 at which point behavior becomes implementation-specific. Empirically, many stacks drop these packets silently.   IP_Total_Length Actual IP Data Over-read Expected Behavior    28 28 0 bytes Normal reply   29 28 1 byte Reply \u2014 1B over-read   36 28 8 bytes Reply \u2014 8B over-read   46 28 18 bytes Reply \u2014 maximum over-read   48+ 28 \u2014 Typically dropped   more on blog...    submitted by    /u/Pale_Surround_3924  (https://www.reddit.com/user/Pale_Surround_3924) \n [link] (https://netacoding.com/posts/etherleak-reloaded/)   [comments] (https://www.reddit.com/r/redteamsec/comments/1tzh41w/etherleak_ip_total_length_overread_via_ethernet/)", "creation_timestamp": "2026-09-02T01:00:20.800346Z"}]}