Actively exploited vulnerability
Linux Kernel: memory corruption flaw under attack
CVE-2026-53266 · Linux Kernel Out-of-Bounds Write Vulnerability
What is affected
Linux Kernel is found on ordinary personal computers and phones, so this is not only a problem for companies. If you use it and have not updated since the fix was released, you are exposed.
Linux Kernel contains an out-of-bounds write vulnerability in the ebtables SNAT target which allows an ARP sender hardware address rewrite to write directly into a nonlinear socket-buffer fragment backed by a splice-imported file page. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.
What an attacker can do
This is a memory corruption flaw. It lets an attacker corrupt the program's memory by feeding it specially crafted content: a web page, a file or a network message. The result ranges from a crash to the attacker running their own code.
- How it is reached
- Needs access to the device or a file opened on it
- Access the attacker needs
- A basic user account
- Does the victim have to do something?
- No, works without the victim doing anything
What to do
- Update Linux Kernel now. Open the update or "About" screen, install whatever is offered and restart the app or device, because the fix is not active until you do.
- Turn on automatic updates so the next fix arrives without you having to look for it.
- If your device is too old to receive this update, stop using the affected app for anything sensitive and plan a replacement.
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Vendor advisories and fixes
- git.kernel.orggit.kernel.org/stable/c/bf84ad7c7a9ede46e31afaa41a1ba06a159e8c87
- git.kernel.orggit.kernel.org/stable/c/76280b78cc9f23bdc6438e10ad6dff148ef8375b
- git.kernel.orggit.kernel.org/stable/c/b7e91939ba9be805a62a257fa4e227dffbb88fa0
- git.kernel.orggit.kernel.org/stable/c/afd64b59c3de9bbbdd3759e834fdc55cda716e0b
- git.kernel.orggit.kernel.org/stable/c/153ea96c806aea395daba907a4f88480b6ad5093
- git.kernel.orggit.kernel.org/stable/c/b18675263db1147c8e1cab625400c13a0d87bd2d
How urgent is it
CISA added this vulnerability to its Known Exploited Vulnerabilities catalogue on September 18, 2026, which means there is reliable evidence of attacks in the wild. US federal agencies must fix it by September 21, 2026, a deadline that has already passed. That deadline does not bind anyone else, but it shows how seriously the agency rates it.
The EPSS model estimates a 0.8% probability that this flaw will be exploited somewhere in the next 30 days. That is higher than 56% of all scored vulnerabilities.
Its CVSS severity score is 8.8 out of 10 (high), as recorded in the US National Vulnerability Database.
Technical description
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().