Skip to content

2.8.0 release #5122

Description

@gpotter2

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:

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

  1. added this to the 2.8.0 milestone on Aug 31, 2026
  2. pinned this issue on Sep 22, 2026
  3. polybassa commented on Sep 29, 2026

    @polybassa
    Contributor

    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
  4. evverx commented on Sep 30, 2026

    @evverx
    Contributor

    GHSA-c547-xwrv-q9jm

    Looks like the commit fixing that issue causes python to segfault when scapy is in libpcap mode and packets are captured with sniff on 32-bit NetBSD machines at least. I'll double-check but it seems that with that commit reverted it doesn't crash.

  5. KernelClint commented on Sep 30, 2026

    @KernelClint
    Contributor

    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:

    • the field Scapy calls len actually holds the captured length, so the old code happened to read the right number of bytes;
    • the field Scapy calls caplen actually holds the timestamp's microseconds (0 to 999,999), so once the fix switched to caplen, 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 sniff there 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.

  6. evverx commented on Sep 30, 2026

    @evverx
    Contributor

    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).

    If that's right, reverting would bring back the original over-read everywhere else

    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.

  7. KernelClint commented on Sep 30, 2026

    @KernelClint
    Contributor

    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 caplen at 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions