Repository navigation
2.8.0 release #5122
Description
WIP
This issue tracks the upcoming 2.8.0 release.
Expected date: 01/10/2026 02/10/2026.
Deprecation notice
- This major version will be the last to support Python 3.7 and 3.8. While this was initially planned for 2.7.0, support was extended because of how used those versions still were. They have been EoL for more than 2 years, and we highly encourage remaining users to upgrade.
Note
We have clarified our CONTRIBUTING and SECURITY guidelines. This notably includes some new guidance related to the use of AI, and some instructions regarding the submission of security issues. We encourage contributors to take a moment to read the updated versions.
Security
Scapy has taken part in OpenAI + Trail of Bits collab's initiative called "Patch the Planet". As part of this initiative, we have received a free security coverage of our code overseen by @KernelClint (Trail of Bits) and multiple OpenAI agents. This has led to the discovery of around 130+ bugs, among which were 54 issues that could be considered related to security, with various degrees of severity. You can find a partial list on https://github.com/secdev/scapy/security/advisories and here but please bear in mind that some reports have been written entirely by AI.
After analysis, we have marked 5 vulnerabilities with a "High" level of impact, which justify an immediate upgrade to 2.8.0, or backporting if packaged by downstream repositories:
- Patch the Planet: arbitrary read of on-disk files while parsing TLS packets
- Patch the Planet: out-of-band read while receiving packets through libpcap
- Patch the Planet: A malicious SMB directory entry makes recursive downloads overwrite arbitrary local files
- Patch the Planet: SMB server mishandling of share case insensitivity leads to default folder always being served
- Patch the Planet: A zero-width NetFlow template keeps
NetflowSessionrunning forever
The other issues have been triaged as "Moderate" or "Low" and don't justify immediate action from users or downstream package maintainers (those include crashes, issues in various protocol implementations, automatons and answering machines, mis-implementations of protocols like our TLS stack, etc. but nothing that leads to a potential compromission of the host machine).
We would like to thank again OpenAI and Trail of Bits (and in particular @KernelClint) for this opportunity and the time spent on this project.
Changelog
- Windows protocols:
- Kerberos: IAKERB support, WinSSP, KDC pinning, S4U+FAST fix, NTLM MIC server-side check
- SMB: various SMB2 fixes, new
smbclient()features - DCE/RPC: fragmentation fixes, proper client auth denial, context commit fixes
- NTLM/SPNEGO/WinSSP: late fallback mechanism, encryption support, doc fixes
- [new] registry abstraction layer for [MS-RRP] RPC
- [MS-NRTP] fix
- Automotive related changes:
- Added SAE J1939 support
- Added standalone UDS/KWP/OBD/GMLAN packets
- Improved CAN/ISO-TP soft-socket robustness
- Added configurable busy-response retries in automotive scanners
- Work has begun to clean up the remaining compatibility code that allowed the transition from Python 2.
- Minor security fixes (the full list is available in the Security tab):
- RADIUS: verify Message-Authenticator
- fwdmachine: verify upstream TLS certs, correct TLS server context
- tls/sslv2: stricter security handling
- Several fuzzing-found crash fixes (HSRP, Bluetooth, Kerberos)
- Bound/robustness fixes across pcap, pcapng, ISOTP, TCP reassembly, BGP, IPv6, HTTP, DNS, LDAP, modbus parsing
- Bluetooth:
- Many new vendor-specific command modules (Realtek, Barrot, Intel, Espressif, CSR, Zephyr)
- Fixed link-layer byte order, normalized field naming
- New HCI event handler registration mechanism
- New protocols/contrib:
- DICOM support
- CBOR implementation (fields + packets)
- SAE J1939 protocol + soft socket
- PTP protocol
- MySQL classic protocol
- 802.11: added HE Operation, HT Operation, EHT Operation, and Radio Measurement elements
- Performance: minor improvements to packet dissection/build speed, reduced unnecessary copying in reassembly paths (netbios, pcapng, HTTP/2, LDAP, ISOTP, TFTP)
- DNS: EDNS0 padding option, client-subnet fixes, off-by-four fix
- IGMP: full rework, merged implementations
- Misc fixes: TCP MD5 option calculation, BPF error reporting, FreeBSD 32-bit BPF support, hexdiff bounds check
Activity
polybassa commentedon Sep 29, 2026
Automotive related changes:
evverx commentedon Sep 30, 2026
Looks like the commit fixing that issue causes python to segfault when
scapyis in libpcap mode and packets are captured withsniffon 32-bit NetBSD machines at least. I'll double-check but it seems that with that commit reverted it doesn't crash.KernelClint commentedon Sep 30, 2026
Thanks @evverx, I think I can see why. The underlying problem predates that commit; the commit just exposed it.
Scapy describes libpcap's packet header with a timestamp made of two C
longs (scapy/libs/winpcapy.py, which despite its name holds the libpcap bindings on every platform). On 32-bit NetBSD the timestamp's seconds field is 64 bits, so the real timestamp is bigger than Scapy expects, and every field after it has always been read from the wrong place. On i386, for example:lenactually holds the captured length, so the old code happened to read the right number of bytes;caplenactually holds the timestamp's microseconds (0 to 999,999), so once the fix switched tocaplen, it copies up to about a megabyte from a small packet and crashes.If that's right, reverting would bring back the original over-read everywhere else, so the header itself needs fixing. Other 32-bit systems with a 64-bit timestamp may be affected too (OpenBSD, musl, Debian armhf), but I haven't tested those.
I'm working on a fix. It would help to know your NetBSD version and architecture, and whether the packet timestamps from
sniffthere look wrong. They should, if this is the cause, both before and after that commit. On i386 I'd expect the microseconds to come out as 0 on every packet.evverx commentedon Sep 30, 2026
It's
NetBSD nbsd32 11.0 NetBSD 11.0 (GENERIC)and the analysis looks correct. 30b872b addressed a 64-bit-time_t-related issue in another place (NetBSD switched to 64-bit in https://www.netbsd.org/releases/formal-6/NetBSD-6.0.html).I'm not saying it should be reverted. It's just that the python segfault on receiving packets should probably be addressed before 2.8.0 is tagged.
KernelClint commentedon Sep 30, 2026
Thanks for confirming. I could reproduce the bad reads on a NetBSD 10.1 i386 VM (reading a pcap file, so no crash, but up to 734,512 bytes from a 60-byte packet), and the fix is in #5209.
The layout there is as I described, with
caplenat byte 12 where Scapy expected 8. The same problem affects musl and 64-bit-time glibc on 32-bit ARM and x86. There, packets came back empty before the GHSA fix, and it crashes after it.