CVE-2026-53266 Added to CISA KEV: Linux ebtables Exposure and Fix

CVE-2026-53266 is now in CISA’s Known Exploited Vulnerabilities catalog, which means defenders should treat the Linux kernel flaw as an active exploitation problem rather than an ordinary patch backlog item. The vulnerability affects a narrow ebtables bridge SNAT path used when rewriting an ARP sender hardware address. Exposure therefore depends on both the kernel/vendor build and the relevant bridge netfilter configuration.

CISA added CVE-2026-53266 to KEV on September 18, 2026 and lists a September 21 due date for applicable federal environments. The KEV entry also ties remediation to BOD 26-04 guidance and forensic triage. CISA’s reviewed public material does not identify a threat actor, campaign or IOC set, and ransomware use is listed as unknown.

What is CVE-2026-53266?

CVE-2026-53266 is an out-of-bounds write in the Linux kernel’s ebtables SNAT handling. The vulnerable code path is in net/bridge/netfilter/ebt_snat.c.

The issue occurs when the SNAT target performs the optional ARP sender-hardware-address rewrite. The target range may still sit in a nonlinear socket-buffer fragment backed by an imported file page, allowing the write to affect memory that was not first made safely writable.

The upstream Linux fix changes this path so the relevant ARP sender-hardware-address range is made writable before the modification occurs.

Does every Linux system have CVE-2026-53266 exposure?

No. Merely running Linux or having ebtables available does not establish that the vulnerable operation is reachable.

Red Hat’s security guidance says exploitation requires specific bridge netfilter rules. The important configuration is ebtables SNAT operating on ARP traffic with sender hardware-address rewriting.

This distinction matters because a generic inventory result such as “ebtables package installed” is not enough to prove exposure.

How should administrators check exposure?

Which upstream Linux kernel versions contain the fix?

The Linux CNA data identifies fixed points in maintained upstream branches including:

The upstream correction is associated with commit 67ba971ae02514d85818fe0c32549ab4bfa3bf49.

Do not use these upstream numbers as a universal distro test. Enterprise distributions frequently backport a security fix while retaining a different kernel version string. Vendor security advisories should control the final answer for a supported system.

What do current vendor advisories show?

Vendor security trackers already show product-specific remediation rather than one universal package answer.

• Red Hat: RHEL 9 remediation includes RHSA-2026:36645. RHEL 8 remediation includes RHSA-2026:39082 and RHSA-2026:39083.
• Debian: the security tracker lists fixed source-package versions including Bullseye 5.10.259-1, Bookworm 6.1.176-1, Trixie 6.12.94-1 and unstable 7.0.13-1.
• Amazon Linux: Amazon publishes product-specific fixed status for its kernel families and should be treated as the controlling source for Amazon Linux hosts.
• Ubuntu and SUSE: both maintain product-specific CVE status, again showing why an upstream kernel number alone is not enough for enterprise patch verification.

Is there a mitigation if the kernel cannot be patched immediately?

Red Hat documents a configuration-level mitigation for affected systems: disable ARP hardware-address rewriting in ebtables SNAT rules or remove the ebtables SNAT rules that operate on ARP traffic on bridge interfaces.

This should not be converted into a universal instruction to remove all ebtables rules. The mitigation needs to be evaluated against the actual network configuration and the vendor’s current guidance.

What does CISA require by September 21?

CISA’s KEV record gives September 21, 2026 as the due date for applicable federal remediation. The entry directs covered agencies to apply vendor mitigations, follow BOD 26-04 guidance and perform forensic triage.

The federal deadline is binding for covered Federal Civilian Executive Branch environments. Private organizations should not misread that as a statutory deadline automatically applying to them, although CISA recommends prioritizing KEV vulnerabilities because exploitation is known.

What does BOD 26-04 add beyond patching?

The important distinction is that the KEV state is not only a patch-management event. CISA also expects applicable federal defenders to perform the required forensic triage under BOD 26-04.

That means organizations within scope should follow CISA’s current directive and implementation guidance rather than treating package installation alone as proof that the entire response obligation is complete.

Do we know who is exploiting CVE-2026-53266?

Not from the public evidence reviewed for this article. CISA confirms evidence of exploitation by placing the CVE in KEV, but the reviewed KEV material does not identify a named threat actor, exploitation campaign or IOC set.

CISA’s ransomware-use field for this vulnerability is listed as Unknown. TPS therefore does not describe CVE-2026-53266 as a ransomware vulnerability or attribute the exploitation to a named group.

Can the vulnerability cause privilege escalation?

Red Hat describes the flaw as an out-of-bounds write that can lead to kernel memory corruption and may result in consequences including denial of service or privilege escalation depending on the environment and exploitation path.

The safe conclusion is that this is a kernel memory-corruption issue with serious potential impact. TPS does not infer a universal exploit outcome or remote unauthenticated compromise from the KEV entry alone.

What should Linux administrators do now?

1. Identify affected systems. Inventory Linux hosts or products using kernels covered by vendor advisories.
2. Check the relevant configuration. Determine whether ebtables bridge SNAT ARP sender-hardware-address rewriting is actually in use.
3. Use vendor package status. Confirm whether the installed kernel contains the backported or upstream fix.
4. Apply the supported update. Install the vendor-supported fixed kernel where available.
5. Use supported mitigation when necessary. If patching is delayed, follow the vendor’s documented mitigation rather than improvising firewall changes.
6. Follow incident-response requirements. Covered federal environments should complete the applicable BOD 26-04 forensic-triage steps.
7. Watch for new exploitation evidence. Reassess if CISA or vendors publish IOCs, campaign details or downstream-product exposure.

What remains unknown?

• The threat actor or campaign behind the exploitation confirmed by CISA.
• Public indicators of compromise tied specifically to CVE-2026-53266.
• The prevalence of the vulnerable ebtables SNAT ARP-rewrite configuration across real-world Linux systems.
• The full status of every supported or downstream Linux distribution, appliance and kernel flavor.
• Whether new evidence will narrow or expand the known exploitation prerequisites.

What happens next?

The next known material checkpoint is September 21, the CISA KEV due date for applicable federal environments. The same canonical should also be updated if CISA publishes IOCs or campaign context, if Linux or vendors change the affected/fixed scope, or if downstream products publish materially different remediation guidance.

Verification note

ThePulseSignal reviewed the CISA KEV state, the upstream Linux CNA and kernel fix, Red Hat’s exposure and mitigation guidance, and representative distribution security trackers. Known exploitation, the ebtables SNAT ARP-rewrite defect and supported remediation paths are established; actor, campaign and IOC details remain unresolved.