Skip to content
eastbaycyber

CVE-2026-46300: Linux Kernel Vulnerability

CVSS · High
7.8
In CISA KEV
Yes
Published
Oct 30
Patch SLA & TriageVector: Local
Immediate (BOD 22-01 due 2026-10-31)

Active exploitation confirmed in CISA KEV.

Exposure:
Control:
CVE explainers 10 min read
Security Research Desk Source-checked
Auto-checked against the official CVE record · Human-reviewed after publishing · Updated 2026-10-30
⚠
CISA Known Exploited Vulnerability

Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-10-28. Federal agencies must patch by 2026-10-31.

Everything CISA added on 2026-10-28 · Linux KEV history

▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - CVE-2026-46300 is a CVSS 7.8 Linux kernel flaw involving shared fragments and ESP processing. - Local, low-privilege attackers may achieve kernel-level confidentiality, integrity, and availability impact. - CISA KEV confirms exploitation in the wild; patch maintained kernels by 2026-10-31.

CVE-2026-46300 is an actively exploited Linux kernel vulnerability affecting networking code that handles shared paged fragments during socket-buffer coalescing and ESP processing. Administrators should prioritize vendor kernel updates, verify backported fixes, and investigate affected systems with local untrusted users or workloads.

For background on related defensive concepts, see our guide to rogue device detection and our explanation of YARA rules.

What Is the Root Cause?

The root cause is loss of the SKBFL_SHARED_FRAG marker when skb_try_coalesce() transfers paged fragment descriptors from one socket buffer to another. The source buffer can indicate that its fragments are shared, externally owned, or backed by page cache. If the destination receives those fragments without the marker, later code can incorrectly treat the buffer as safe for in-place modification.

The affected decision occurs in the ESP input path. ESP processing checks skb_has_shared_frag() before deciding whether it must invoke skb_cow_data(). If TCP receive coalescing has transferred shared fragments but failed to preserve the marker, ESP may skip copy-on-write handling and decrypt directly into memory that should not be modified in place. That can result in corruption or an attacker-controlled kernel memory-safety condition, with potential impact across confidentiality, integrity, and availability.

The supplied technical material describes this as a missing-initialization-style vulnerability in the CISA title, but the operationally important defect is the broken socket-buffer invariant. The upstream correction propagates SKBFL_SHARED_FRAG when paged fragments are transferred. The separate tailroom-copy path does not require the marker because it copies bytes into the destination’s linear data rather than transferring fragment descriptors.

AnalystImpact · assess the risk

What Happened, in Brief

CVE-2026-46300 affects Linux kernel networking code that handles shared paged fragments while coalescing socket buffers. The vulnerable path involves skb_try_coalesce(), TCP receive coalescing, and the XFRM ESP input path. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on 2026-10-28, confirming exploitation in the wild.

Field Details
CVE ID CVE-2026-46300
Product Linux Kernel
CVSS v3.1 7.8 High
CVSS vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack vector Local
Authentication or privileges required Low privileges required
User interaction None
Patch status Upstream stable-tree fixes and distribution backports are available or expected; exact package versions vary
CISA KEV status Listed; remediation due date 2026-10-31
Ransomware attribution Unknown

The available records do not provide a single universal minimum fixed Linux version. Linux distributions commonly backport kernel fixes into maintained release branches. The relevant remediation is therefore the newest security-supported kernel package for the operating system, together with confirmation that it contains the correction.

Who Needs to Act?

Organizations running Linux kernel systems should treat all security-maintained distributions as potentially affected until the installed package is matched against a vendor advisory. The affected component is the Linux kernel networking stack, particularly systems using the relevant TCP receive coalescing and XFRM ESP processing paths.

A server does not need to expose a service directly to the internet for this issue to matter. The CVSS vector requires local access, and a low-privilege account may be sufficient.

Analyst’s Take: Patch priority should follow local privilege exposure and confirmed exploitation, not whether a host is internet-facing. Multi-user systems, shared hosting, build servers, bastion hosts, container hosts, and systems where untrusted users can execute code should be handled first because they provide the local foothold described by the CVSS vector.

The available NVD record does not publish a complete affected-version range or a universal fixed version. It would therefore be unsafe to claim that a particular upstream version is sufficient without a distribution-specific advisory. Administrators should record the exact kernel package, distribution release, architecture, and vendor advisory status.

Product or code line Affected version information Fixed version guidance
Upstream Linux Kernel Complete vulnerable range not provided in the available NVD record Use a maintained upstream stable release containing the referenced correction
Red Hat Enterprise Linux kernel packages Exact affected and fixed package versions must be checked in Red Hat’s advisory Install the latest security-maintained Red Hat kernel package and confirm the backport
Other Linux distributions Exact ranges depend on vendor backport policy and release support status Follow the distribution’s security advisory; do not infer status from the upstream package version alone

Red Hat classifies CVE-2026-46300 as Important and notes that local exploitation may allow a low-privileged attacker to achieve root-level impact through the Linux kernel’s XFRM ESP-in-TCP subsystem. Multi-user systems, shared hosting, build servers, bastion hosts, container hosts, and systems where untrusted users can execute code should receive priority.

Why This CVSS Score?

The CVSS v3.1 score is 7.8 High, represented by:

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Metric Value Meaning
Attack Vector Local (AV:L) The attacker needs local access or local code execution
Attack Complexity Low (AC:L) No unusual conditions or specialized race is reflected in the score
Privileges Required Low (PR:L) A low-privilege account is sufficient according to the scoring
User Interaction None (UI:N) No separate victim action is required
Scope Unchanged (S:U) The impact remains within the vulnerable security authority
Confidentiality High (C:H) Potential disclosure of sensitive kernel or system data
Integrity High (I:H) Potential modification of kernel or system state
Availability High (A:H) Potential denial of service or loss of system availability

The local attack vector lowers the score compared with a remotely reachable kernel flaw, but it does not make the issue low priority. Local code execution is common on developer workstations, shared servers, application hosts, container platforms, and systems exposed to untrusted tenants.

The score does not account for the fact that CISA KEV confirms real-world exploitation. CVSS measures technical severity under a defined model; KEV status is a separate operational risk signal. Organizations should combine the 7.8 score, local privilege requirements, asset importance, and confirmed exploitation when setting remediation deadlines.

Has CVE-2026-46300 Been Exploited?

Yes. Exploitation in the wild is confirmed. CISA added CVE-2026-46300 to the Known Exploited Vulnerabilities catalog on 2026-10-28 and assigned a remediation due date of 2026-10-31. This should override assumptions that a local-only vulnerability can wait.

The available research note does not identify a verified public proof-of-concept repository or exploit code. Accordingly, the current status is: active exploitation confirmed, public PoC not verified in the retrieved sources. Absence of a known public PoC does not reduce the urgency created by KEV inclusion. CISA also does not currently attribute the vulnerability to a known ransomware campaign; ransomware use is therefore unknown, not disproven.

Defenders should assume that exploit capability may be held privately or integrated into targeted intrusion tooling. Local privilege exposure, especially on systems that permit shell access, arbitrary workloads, untrusted containers, or code execution through applications, should be treated as a meaningful precondition for compromise.

ResponderRunbook · act now

Detection Guidance

Detection has two objectives: identify systems that remain vulnerable and investigate evidence that an attacker used local access to reach the kernel. Vulnerability scanners should inventory the running kernel and distribution package release, then compare them with the operating system vendor’s advisory. Do not rely solely on the upstream uname -r string because distributions may backport the fix without changing the apparent upstream base version.

Start with host inventory and package verification:

uname -a
cat /etc/os-release

# Debian and Ubuntu
dpkg-query -W -f='${Package}\t${Version}\n' 'linux-image*' 2>/dev/null

# RHEL, CentOS Stream, Fedora, and compatible systems
rpm -q kernel
rpm -q --changelog kernel 2>/dev/null | grep -i -C 3 'CVE-2026-46300'

# Installed kernel modules and boot entries
find /lib/modules -maxdepth 1 -mindepth 1 -type d -printf '%f\n'

There is no supplied universal audit-log signature that uniquely identifies exploitation of this flaw. Kernel crashes, warnings, or memory corruption may be non-specific. Investigators should correlate kernel and authentication events with suspicious local execution, privilege changes, and network activity involving ESP or XFRM.

# Search common journal sources for kernel faults and XFRM/ESP activity
journalctl -k --since "30 days ago" | \
  grep -Ei 'BUG:|Oops:|general protection fault|kernel panic|use-after-free|xfrm|esp|skb|segfault'

# Review successful local logins and privilege changes
journalctl --since "30 days ago" | \
  grep -Ei 'sshd.*Accepted|sudo:|su:|session opened|new user|useradd'

# Identify processes that may have preceded suspicious kernel events
journalctl --since "30 days ago" -o short-iso | \
  grep -Ei 'execve|sudo|su:|container|unshare|setns'

These queries are triage aids, not proof of exploitation. Normal XFRM or ESP traffic can produce matching records, and many vulnerable executions may leave no distinctive log entry. Preserve journald data, authentication logs, endpoint telemetry, crash dumps, and relevant network-flow records before rebooting a potentially compromised host.

If exploitation is suspected, isolate the system while maintaining forensic integrity and investigate possible post-exploitation persistence or credential access. Organizations may also wish to review their broader vulnerability response process in light of CISA KEV-listed issues and maintain clear ownership for emergency remediation.

Remediation and Patching

The primary remediation is to install the latest security-maintained kernel supplied by the Linux distribution and reboot into the patched kernel. The upstream correction is represented by the following stable-tree commits listed by NVD:

  • 2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c
  • 3599e6b3cc1ada96883d496a50a210d3afbb6987
  • 3884358a9286b17f389a72b1426fc4547c23c111
  • 3bd9e113d50034db99d7ef69fd8e5242d15e414a
  • 760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34

No universal fixed version number is available in the supplied NVD response. Do not mark a host remediated merely because it runs a newer-looking kernel string. Confirm the distribution’s advisory, installed package release, and running kernel after reboot.

Technical Notes

Use the package manager appropriate to the operating system, then reboot and verify the active kernel:

# Debian or Ubuntu
sudo apt-get update
sudo apt-get install --only-upgrade linux-image-generic linux-headers-generic
sudo reboot

# RHEL, CentOS Stream, Fedora, or compatible systems
sudo dnf upgrade --refresh 'kernel*'
sudo reboot

# Verify after reboot
uname -r
cat /proc/version

These commands are intentionally generic because exact package names and repositories vary by release. Production teams should first confirm the vendor advisory and test the kernel in a representative staging environment where operational constraints require it. Given the CISA due date of 2026-10-31, testing should not become an indefinite delay.

Where an immediate reboot is not possible, reduce exposure while arranging a kernel update. Restrict shell and code-execution access, remove unnecessary local accounts, disable dormant accounts, limit untrusted workloads, and apply strong isolation between tenants. Review whether XFRM/IPsec ESP functionality is required and disable unneeded IPsec policy or tunnels according to the organization’s network design.

This is a risk-reduction measure, not a substitute for the kernel fix; the supplied sources do not establish a complete, vendor-approved workaround that eliminates the vulnerability.

After updating, confirm that the running kernel—not merely an installed package—is the remediated one. Retain the prior kernel only if required by the distribution’s rollback policy, and ensure bootloader defaults select the patched image. For systems that cannot receive a maintained kernel, evaluate discontinuing use where mitigations are unavailable. Apply relevant CISA BOD 26-04 requirements, document exceptions, and preserve forensic evidence from systems with suspicious local activity.

References

The following sources support the vulnerability status, technical root cause, and remediation guidance:

  1. CISA Known Exploited Vulnerabilities catalog — CVE-2026-46300 is listed as actively exploited, added 2026-10-28, with a due date of 2026-10-31.
  2. Red Hat CVE-2026-46300 advisory — severity classification and local exploitation context:
    https://access.redhat.com/security/cve/cve-2026-46300
  3. Linux stable-tree correction:
    https://git.kernel.org/stable/c/2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c
  4. Linux stable-tree correction:
    https://git.kernel.org/stable/c/3599e6b3cc1ada96883d496a50a210d3afbb6987
  5. Linux stable-tree correction:
    https://git.kernel.org/stable/c/3884358a9286b17f389a72b1426fc4547c23c111
  6. Linux stable-tree correction:
    https://git.kernel.org/stable/c/3bd9e113d50034db99d7ef69fd8e5242d15e414a
  7. Linux stable-tree correction:
    https://git.kernel.org/stable/c/760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34
  8. NVD record for CVE-2026-46300 — publication date 2026-05-23 and last modification 2026-10-29.

CVE-2026-46300 should be handled first on systems that combine local, low-privilege access with sensitive workloads or untrusted users. Patch the distribution-maintained kernel, verify both the backport and active booted kernel, then investigate systems with suspicious local activity. The confirmed KEV exploitation and 2026-10-31 remediation date leave little basis for deferring those steps.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Choosing a tool? Pricing and head-to-head guides

Last verified: 2026-10-30

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.