Linux Kernel CVE-2026-46300 Is on KEV: the ESP Flaw Chained With PHP to Get Root, and What to Patch

CVE-2026-46300 is not newly disclosed (it was public in May 2026 and distributions have shipped fixes since); it is newly listed as exploited. It is a Linux kernel flaw in how socket buffers are merged, which lets the IPsec ESP code decrypt data in place over memory that belongs to the page cache, so a local user can change the cached contents of files they are only allowed to read. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on 28 October 2026, set a due date of 31 October 2026, flagged it for forensic triage, and wrote in the entry that it "can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root." If you run Linux servers that host PHP, install your distribution's fixed kernel and reboot into it this week, patch PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later, and collect evidence before you reboot any host you think was touched, because the kernel bug changes files in memory, not on disk.

This post is the kernel leg of that chain. The PHP flaws are covered in PHP2Shell: CVE-2026-109618 and CVE-2026-109619 explained and find and patch every PHP runtime after PHP2Shell. Every fact below is dated and comes from a primary source: the KEV feed, the CVE record, NVD, the kernel disclosure thread and the distribution trackers.

Key takeaways

• On KEV with a three day clock. As of 29 October 2026, KEV lists CVE-2026-46300 as added 28 October 2026, due 31 October 2026, ransomware use "Unknown", forensicTriage "Yes".
• CISA names the chain. PHP CVE-2026-109618 or CVE-2026-109619 gives code execution as the web server user; this kernel flaw turns that into root.
• Local privilege escalation, CVSS 3.1 7.8 High per the kernel CNA and NVD. "Local" means little once a remote PHP bug hands out a local account.
• Public since May. Disclosed on 13 May 2026 as "Fragnesia", a Dirty Frag variant, with a public proof of concept. Red Hat rates it Important.
• Fixed upstream in 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33, 7.0.10 and 7.1, with distribution kernels since May.
• Reboot, and collect evidence first on suspect hosts. The disclosure says the technique changes a binary in the page cache while "the on-disk binary is untouched."

What happened, in order

The flaw was disclosed in May. What is new on 28 October is only CISA's KEV listing, and its note that the flaw can be chained with the PHP flaws disclosed on 21 October 2026.

On 13 May 2026, a post on the oss-security mailing list reported that a research team had disclosed "Fragnesia", described in their words as "a universal Linux local privilege escalation exploit" and "a member of the Dirty Frag vulnerability class", in "the same surface" as the earlier Dirty Frag bugs, "and the mitigation is the same as for dirtyfrag." Later that day Greg Kroah-Hartman replied on the same thread that "CVE-2026-46300 has been assigned for this issue." At that point, he noted, the patch was on the netdev mailing list but "not yet in that tree or in Linus's tree, therefore not in any stable kernels either."

On 22 May 2026 (Japan time; 21 May in UTC), Hyunwoo Kim, who posted the Dirty Frag fix patches, reported on oss-security that the fix for CVE-2026-46300 had been split into its own patch and merged into the netdev tree as commit f84eca5817390257cef78013d0112481c503b4a3, separately from a broader patch for the other Dirty Frag variants. He added a warning that is still worth reading: "As long as the in-place path in esp remains, further variants of this kind are expected to be found in the esp module."

The CVE record was published on 23 May 2026, distributions shipped fixed kernels from 20 May, and on 28 October 2026 CISA added it to KEV, two days after the PHP pair.

Timeline from primary sources

What the KEV entry says, field by field

As of 29 October 2026, the KEV machine readable feed (catalogVersion 2026.10.28, dateReleased 2026-10-28T19:00:04Z) lists CVE-2026-46300 with vendorProject "Linux", product "Kernel", dateAdded 2026-10-28, dueDate 2026-10-31, knownRansomwareCampaignUse "Unknown", forensicTriage "Yes" and CWE-456. The shortDescription reads, in full: "Linux Kernel contains a missing initialization of a variable vulnerability that could allow for unintended modification of page-cache-backed data via failure to preserve the shared-fragment marker during socket buffer coalescing, causing ESP input processing to decrypt shared fragments in place. This vulnerability can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root."

The requiredAction tells agencies to "Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA's BOD 26-04 Prioritizing Security Updates Based on Risk" and "CISA's 'Forensics Triage Requirements'", to follow BOD 26-04 guidance for cloud services "or discontinue use of the product if mitigations are unavailable", and says stakeholders "are responsible for evaluating each asset's internet exposure."

The notes field says the flaw "affects an open-source component, third-party library, protocol, or proprietary implementation that could be used by different products" and links eight kernel.org stable commits, BOD 26-04, the BOD 26-04 implementation guidance that holds the forensics triage requirements, and the NVD record.

For comparison, the two PHP entries, both added on 26 October 2026, carry a due date of 29 October 2026, the same "Unknown" ransomware field and the same forensicTriage "Yes".

Why the forensic triage flag matters

A forensicTriage value of "Yes" adds a second instruction to patching: check whether the asset was already compromised, following the requirements in the BOD 26-04 implementation guidance. BOD 26-04 (10 June 2026) replaced BOD 22-01 for federal civilian agencies and does not bind private companies, but the logic carries over. For this chain, any PHP host that ran an affected PHP build on the internet between 21 October and the day you patched should be treated as one that may have had a webshell and root. Work through the triage section below before returning it to service.

How the chain fits together

The two halves of this chain need different things from an attacker, and that is why CISA calls out the combination.

The PHP flaws are remote. According to the CVE records published by the PHP project on 21 October 2026, CVE-2026-109618 ("RCE via OOM corruption") and CVE-2026-109619 ("RCE via stale global state") let an unauthenticated attacker reach remote code execution in PHP. Both are scored CVSS 4.0 9.2 Critical with the vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Code that runs through those bugs runs as whatever account PHP runs as, typically the web server or PHP-FPM pool user. That is the "implant PHP webshells" part of the KEV description.

The kernel flaw is local. The kernel CNA's own scoring notes for CVE-2026-46300 say "a local account is required" (AV:L) and that "an unprivileged user can splice readable file pages and obtain CAP_NET_ADMIN to install xfrm SAs/policies inside a user+network namespace." A webshell running as www-data or apache is exactly that kind of unprivileged local account. The kernel bug then lets that account change the cached copy of a file it can only read, and the public disclosure describes doing that to a setuid root program. That is the "run commands as root" part.

Patch both: the PHP bugs are remote code execution even without root, and the kernel bug is a local root for any foothold, including a stolen SSH key or a compromised CI job.

What we could not confirm: as of 29 October 2026 we found no primary source, beyond the KEV entry's own wording, that documents a specific campaign using this chain, its victims or its indicators. CISA's KEV entry is the authoritative statement that the chain exists and that CVE-2026-46300 is exploited. We do not repeat secondary reports that we could not trace to a primary source.

The flaw: what the kernel got wrong

Shared fragments and why the marker exists

Linux network buffers (struct sk_buff, or skb) can carry data in a linear area and in a list of page fragments. Some of those fragments do not belong to the network stack at all. When a program uses sendfile, splice or vmsplice, the kernel can attach pages from the page cache, the in-memory copy of files, straight to a socket buffer instead of copying them. That saves copies, which is why it exists.

Those pages are shared with every process that reads the same file. Writing into them would change what every reader sees. So the kernel marks such buffers with a flag, SKBFL_SHARED_FRAG, and code that wants to modify buffer data in place checks skb_has_shared_frag() first. If the flag is set, the code copies the data to private memory before writing.

What went wrong

The kernel CNA's description of the fix explains the bug in four sentences. skb_try_coalesce(), which merges one socket buffer into another, "can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost."

That breaks a rule other code relies on. The record continues: "ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags."

ESP (Encapsulating Security Payload) is the part of IPsec that encrypts and decrypts packets. Decrypting in place means writing the plaintext over the ciphertext in the same memory. When that memory is a page cache page for a file, the decrypt writes into the cached file.

The fix is small. It makes skb_try_coalesce() propagate SKBFL_SHARED_FRAG when it transfers paged fragments. The record notes that the "tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors." The changed file is net/core/skbuff.c.

What the public disclosure says about impact

The 13 May 2026 oss-security post quotes the original disclosure. It describes "arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition", triggered "when a TCP socket transitions to espintcp ULP mode after data has already been spliced from a file into the receive queue." The disclosure says its proof of concept overwrites the start of the cached copy of /usr/bin/su and then runs it, and that "the page cache modification is not backed to disk; the on-disk binary is untouched."

We do not reproduce the technique. Two details matter to defenders: the target is the in-memory copy of a privileged program, so integrity tools that hash files on disk after a reboot see nothing; and the public proof of concept needs the espintcp module, which ties exposure to whether ESP in TCP can load on the host.

The CVSS vector

The kernel CNA and NVD both score CVE-2026-46300 at 7.8 High, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The CNA published its reasoning per metric. Attack vector is local because the shared fragment condition "only arises from local page splicing" and "NIC-received packets never carry SKBFL_SHARED_FRAG". Complexity is low because the attacker controls the spliced pages, the ESP key and the packet timing on loopback. Privileges are low because an unprivileged user can get CAP_NET_ADMIN inside its own user and network namespace, while "the global page cache is still corrupted from there." Scope is unchanged: no virtual machine or IOMMU boundary is crossed. That privileges line is the whole chain in one sentence: a PHP webshell is exactly such an unprivileged user.

Related CVEs you should patch together

Ubuntu's tracker note for CVE-2026-46300 adds context that is easy to miss. It says to "pair with CVE-2026-43284: ship both fixes together", because the CVE-2026-43284 fix "is what makes the SHARED_FRAG bit actually checked at decrypt time" while the CVE-2026-46300 fixes "make sure that bit is not lost on the way." It also notes that the kernel CNA assigned CVE-2026-43503 to a second Fragnesia commit, 48f6a5356a33 ("net: skbuff: propagate shared-frag marker through frag-transfer helpers"). In practice, a distribution kernel released after late May 2026 that lists CVE-2026-46300 as fixed should carry the related fixes too, but check your vendor's notice for each CVE rather than assuming.

Affected and fixed versions

Upstream kernel

As of 29 October 2026, the CVE record (kernel CNA, last updated 28 October 2026) lists the flaw as introduced in 3.9 and fixed in these stable releases:

Kernels before 3.9 are listed as unaffected. Branches not in this table, such as 5.4 or 6.8, are end of life upstream and have no upstream fix; if your distribution ships one of those, its own package is what matters. NVD's configuration for the CVE lists the same end points for the 5.15 through 7.0 ranges.

The CVE record and the KEV entry list eight stable commits, all fixing the same change in net/core/skbuff.c:

3599e6b3cc1ada96883d496a50a210d3afbb6987
2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c
9d3e5fd19fe1063bf607219e8562fbd567b8e8d5
78bf6b6bb19541d19fbda6242e7cfe2c682763c0
760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34e
3bd9e113d50034db99d7ef69fd8e5242d15e414a
3884358a9286b17f389a72b1426fc4547c23c111
f84eca5817390257cef78013d0112481c503b4a3

If you build your own kernels, check that the commit for your branch is in your tree. For example, in a stable kernel checkout:

# Is the fix in the tree you build from?
git merge-base --is-ancestor 3599e6b3cc1ada96883d496a50a210d3afbb6987 HEAD && echo fixed || echo "not an ancestor (check the commit for your branch)"

# Or search by subject
git log --oneline --grep="preserve shared-frag marker during coalescing"

Red Hat Enterprise Linux

As of 29 October 2026, Red Hat's security data rates CVE-2026-46300 Important, gives a public date of 13 May 2026, and lists Red Hat Enterprise Linux 6 and 7 as not affected. Red Hat's statement says the issue is Important rather than Critical "because exploitation requires local access to the system" and describes a low privileged local attacker using the "XFRM ESP-in-TCP subsystem to gain root privileges by overwriting sensitive system files." Fixed packages include:

Red Hat lists further fixed kernels for its 8.4, 8.6, 8.8, 9.0 and 9.2 extended streams on the CVE page. It also lists live patches (kpatch-patch) for several streams, for example RHSA-2026:23470 for RHEL 8 and RHSA-2026:23468 for RHEL 9.6 EUS, both released 4 June 2026, and fixed Red Hat Enterprise Linux CoreOS images for OpenShift Container Platform 4.12 through 4.21. On OpenShift, the node operating system is updated through a cluster update, not by installing a kernel package on the node. Red Hat's mitigation field says "See the security bulletin for a detailed mitigation procedure."

Ubuntu

As of 29 October 2026, Ubuntu's CVE tracker gives CVE-2026-46300 a priority of High, with the reason "Trivial local privilege escalation." It describes the flaw as "a logic flaw ... in the XFRM ESP-in-TCP subsystem" and says a local attacker "could use this to escalate privileges, or possibly escape a container." Fixed versions for the main kernel and the three largest cloud kernels:

Ubuntu explains why focal and bionic are marked not affected: the public proof of concept needs the espintcp module, which "first showed up upstream at commit e27cca96cd68 (Nov 2019, v5.6)", so kernels older than that "cannot run the PoCs, so they are not affected in practice." The tracker lists many Ubuntu Security Notices for this CVE across kernel flavours, including USN-8370-1, USN-8371-1 and USN-8373-1, and a Livepatch notice, LSN-0122-1. Other flavours (HWE, Oracle, IBM, low latency and so on) have their own fixed versions on the tracker page; check the one your hosts run.

Debian

As of 29 October 2026, Debian's security tracker lists these fixed source package versions:

The versions currently in bookworm (6.1.190-1 in the security suite), trixie (6.12.113-1 in the security suite), forky and sid are all marked fixed. Debian's own fixed version for trixie, 6.12.90-1, is lower than the upstream 6.12.91 because Debian applied the patch itself; trust the distribution's number for distribution packages.

SUSE

As of 29 October 2026, SUSE's CVE page rates the issue important, shows the same CVSS 3.1 vector as the kernel CNA, and gives the overall state as "Resolved". It lists fixed kernel-default versions per code stream, including 4.12.14-122.307.1, 5.14.21-150400.24.214.1, 5.14.21-150500.55.163.1, 6.4.0-150600.23.109.1, 6.4.0-150700.53.55.1, 6.4.0-44.1, 6.12.0-160000.31.1 and 6.12.0-160100.7.2. Match the stream in your installed version string (for example 150500 or 160000) against the SUSE page for your product before you compare numbers.

Who is exposed

A host is in the risk group for this chain when all of these hold:

1. It runs a Linux kernel in an affected range without the vendor fix, or a fixed kernel is installed but the host has not rebooted into it.
2. The ESP in TCP code can be loaded. On most general purpose distribution kernels the IPsec modules are built as loadable modules and load on demand.
3. An attacker can run code as an unprivileged local user. For the chain in the KEV entry, that user is the PHP process, through CVE-2026-109618 or CVE-2026-109619 on an unpatched PHP build.
4. For the unprivileged path the CNA describes, the user can create user and network namespaces.

Start with PHP application servers, shared hosting, container nodes running PHP and CI runners that execute untrusted code. Containers share the host kernel, so an image cannot carry its own fix; a PHP container on an unpatched node is exposed through the node, and Ubuntu's tracker says the flaw could "possibly escape a container." Patch the nodes, then the images.

Am I exposed? Checks you can run today

These checks are read only. Run them on each host, or push them through your configuration management tool.

1. What kernel is running, and is a newer one installed?

# The kernel that is actually running
uname -r

# Debian and Ubuntu: installed kernel images
dpkg -l 'linux-image-*' | awk '/^ii/{print $2, $3}'

# RHEL, Rocky, Alma, Oracle Linux, Fedora
rpm -q kernel kernel-core --last | head

# SUSE
rpm -q kernel-default

If the installed package is fixed but uname -r shows an older version, the host needs a reboot.

# Debian and Ubuntu: does the system want a reboot?
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

# RHEL family
needs-restarting -r

# SUSE
zypper needs-rebooting

2. Ask the distribution's own tooling about the CVE

# Ubuntu (Pro or the OVAL data): status of a specific CVE
pro fix CVE-2026-46300

# RHEL family: is the advisory for this CVE applied?
dnf updateinfo list --cve CVE-2026-46300
dnf updateinfo info --cve CVE-2026-46300

# SUSE
zypper list-patches --cve=CVE-2026-46300

These read the vendor's advisory data, which is the answer your auditor wants.

3. Are the ESP and ESP in TCP modules loaded or loadable?

# Loaded right now?
grep -E '^(esp4|esp6|espintcp|esp4_offload|esp6_offload|xfrm_user) ' /proc/modules

# Could they load on demand? (shows the module file if it exists)
modinfo -n esp4 esp6 espintcp 2>/dev/null

# Built in rather than modular? (then blocking modules will not help)
grep -E 'CONFIG_INET_ESP=|CONFIG_INET6_ESP=|CONFIG_INET_ESPINTCP=|CONFIG_INET6_ESPINTCP=' /boot/config-$(uname -r)

A value of =m means the code is a loadable module, which you can block as a stopgap. A value of =y means it is built into the kernel, and only a kernel update fixes it.

4. Do you use IPsec on this host?

# Any IPsec security associations or policies in the host namespace?
ip xfrm state
ip xfrm policy

# IPsec daemons installed or running
systemctl list-units --type=service | grep -E -i 'strongswan|libreswan|ipsec|charon'

Blocking the modules is low risk on a web server with no IPsec, and breaks traffic on a VPN gateway.

5. Is PHP on this host patched?

php -v
# Debian and Ubuntu
dpkg -l | grep -E '^ii +php[0-9.]*-(cli|fpm|common)'
# RHEL family
rpm -qa | grep -E '^php(-cli|-fpm|-common)?-[0-9]'

The upstream fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Distribution PHP packages carry backports, so check your vendor's notice for the PHP CVEs. The PHP runtime post covers images, bundled runtimes and the places PHP hides.

Patch: the fix, distribution by distribution

The fix is a kernel update and a reboot. Plan the reboot like any other change, but do not let a change window push you past the KEV due date of 31 October 2026 for internet facing PHP hosts.

Ubuntu

sudo apt update
sudo apt install --only-upgrade linux-image-generic linux-generic   # or your flavour meta package
sudo reboot
# after the reboot
uname -r

Hosts with Livepatch enabled can check canonical-livepatch status; Ubuntu lists LSN-0122-1 against this CVE. Treat a live patch as a bridge to the next reboot.

Debian

sudo apt update
sudo apt full-upgrade
sudo reboot

RHEL, Rocky, Alma and Oracle Linux

sudo dnf update --advisory=RHSA-2026:19568   # RHEL 9 example; use your stream's advisory
# or simply
sudo dnf update kernel
sudo reboot

Where Red Hat lists a kpatch for your stream, dnf install kpatch-patch can apply the fix without a reboot until your next window. Rebuild-derived distributions publish their own advisories; check their trackers for the same CVE.

SUSE

sudo zypper refresh
sudo zypper patch --cve=CVE-2026-46300
sudo reboot

Kubernetes and managed nodes

Patch the node image, not the pods: drain nodes, roll them onto a fixed image and confirm with kubectl get nodes -o wide, which shows each node's kernel. On OpenShift the fix arrives with the cluster update.

Mitigate if you cannot reboot yet

If a host cannot take a new kernel before the due date, reduce the attack surface and record the exception with a date.

Block the ESP modules

Ubuntu's Dirty Frag guidance, which its tracker says applies to this CVE ("the same procedure"), blocks the affected modules from loading. The ESP part of that guidance:

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
sudo rmmod esp4 esp6 2>/dev/null
grep -qE '^(esp4|esp6) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Ubuntu's full procedure also blocks rxrpc for the RxRPC half of Dirty Frag. Ubuntu warns that the mitigation disables IPsec ESP, so it breaks IPsec VPNs on that host, and that it "should only be applied if the Linux kernel cannot be updated." Once the fixed kernel is installed, remove the file with sudo rm /etc/modprobe.d/dirty-frag.conf. If CONFIG_INET_ESP is =y, this does nothing; the code is built in.

Restrict unprivileged user namespaces (hardening, test first)

The CNA's scoring notes say the unprivileged path gets its network capability inside a user and network namespace. On single purpose web servers that do not need them, user.max_user_namespaces = 0 in /etc/sysctl.d/ narrows that path. This is general hardening, not a vendor listed fix, and it breaks rootless containers and some sandboxes, so test it first.

Detection and forensic triage

CISA flagged this entry for forensic triage. The federal requirements live in the BOD 26-04 implementation guidance; the practical steps below apply to anyone.

Before you reboot a suspect host

The public disclosure says the proof of concept modifies the page cache, not the file on disk. A reboot, or anything that evicts that page from memory, removes the evidence of the kernel step. On a host you think was compromised, capture first, then patch:

1. Snapshot or capture memory if you have the tooling (a hypervisor or cloud snapshot that includes memory, or a memory acquisition tool you already use).
2. Check setuid binaries while they are still cached. Reading a file returns the page cache copy, so package verification run now may show a mismatch that disappears after a reboot.

# Debian and Ubuntu
sudo debsums -s -c 2>/dev/null | head
sudo debsums -s util-linux login sudo passwd 2>/dev/null

# RHEL family and SUSE
sudo rpm -V util-linux shadow-utils sudo passwd

# Hashes of common setuid targets, to compare with a known good host of the same version
sha256sum /usr/bin/su /usr/bin/sudo /usr/bin/passwd /usr/bin/mount

A mismatch on /usr/bin/su or another setuid program on an otherwise unchanged host is a strong signal. A clean result does not prove the host is clean, because the attacker may have used a different target, or the page may already have been evicted.

3. Save process, network and namespace state.

ps -eo pid,ppid,user,lstart,cmd --forest > /root/ir-ps.txt
ss -tanp > /root/ir-ss.txt
lsns > /root/ir-lsns.txt                     # namespaces created by web users stand out
sudo ip xfrm state > /root/ir-xfrm.txt
lsmod > /root/ir-lsmod.txt

Look for user and network namespaces owned by the web server account, shells or su running under the PHP-FPM or web server process tree, and ESP modules loaded on a host that has no IPsec configuration.

Look for the PHP leg

The KEV entry describes PHP webshells. Search the web roots and upload directories for PHP files created or changed since 21 October 2026, and review web server and PHP-FPM logs for crashes and memory errors around unusual requests. Our PHP2Shell explainer lists what the PHP advisories say about these bugs.

# PHP files changed in the last 10 days under common web roots
sudo find /var/www /srv /usr/share/nginx -type f -name '*.php' -mtime -10 -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' 2>/dev/null | sort

# PHP-FPM worker crashes
sudo journalctl -u 'php*-fpm*' --since "2026-10-21" | grep -i -E 'segfault|SIGSEGV|exited on signal|Allowed memory size' | head -50

Look for the kernel leg after the fact

auditd rules on execve of setuid programs and on unshare by the web server account leave a record that survives a reboot. Kernel logs may show ESP modules loading on hosts with no IPsec use.

sudo journalctl -k --since "2026-10-21" | grep -i -E 'esp|xfrm' | head
sudo ausearch -m EXECVE -ts 10/21/2026 2>/dev/null | grep -E 'comm="su"|/usr/bin/su' | head

If you find something

Treat it as a root compromise: rebuild from a known good image, rotate every credential the host could read (database passwords, application API keys, SSH keys, cloud instance credentials) and check what else it could reach. Patching does not remove what an attacker with root left behind.

Technical details

What would have helped

Practices any team can use

• Track reboots, not just installs. Report daily on hosts whose running kernel differs from the newest installed one.
• Treat local privilege escalations on web hosts as remote. On a server running internet reachable code, a "local" vector means little.
• Load only the kernel modules you use. Web servers that never use IPsec do not need ESP loadable.
• Write the triage order down in advance. For bugs that change memory but not disk, capture before you reboot.

Where Safeguard fits

Safeguard does not patch kernels and is not an endpoint or host intrusion detection tool. For the kernel leg, the fix comes from your distribution, and the checks above are the right tools. Where Safeguard helps is the software you build and ship around it, which is where the PHP leg of this chain lives.

Safeguard's container image scanning adds one step after your pipeline builds an image: it scans the image on the runner, records it in Safeguard under the image's repository with one version per environment and tag, and can fail the build on vulnerabilities. Only the results leave the runner. You can then explore the SBOM for each image to see its components and versions, including the PHP build and operating system packages. Continuous scanning re-evaluates SBOMs and container images when vulnerability feeds change, including when CISA adds a KEV entry, so images scanned before 21 October still surface when the PHP CVEs land. Policies and gates turn that into a build that fails. Reachability analysis in Safeguard is static: it ranks findings in your application's dependencies by whether your code calls the vulnerable path, and it does not observe running hosts or kernels.

To be clear about what it is not: Safeguard did not discover CVE-2026-46300 or the PHP flaws, and we make no claim that any Safeguard component had a fix for them before the public releases. Zero-Day Discovery is built for open source package ecosystems; neither PHP core nor the Linux kernel is a package it covers.

How Safeguard helps, step by step

1. Find every image that carries PHP. Add safeguard ci scan --image <image:tag> --environment prod --wait after each PHP image build, as the container images page describes, and scan the images you already run. Search the resulting SBOMs for the PHP packages and versions.
2. Put KEV listed findings first. Both PHP CVEs are on KEV (due 29 October 2026), and KEV status is one of the prioritization signals Safeguard uses. Start with images that run on internet facing hosts.
3. Stop the vulnerable build shipping again. Both PHP CVEs are scored Critical, so --fail-on critical on the production step fails a build that still carries them, and a gate built on the "No Critical Vulnerabilities" policy template does the same through --fail-on-gate.
4. Track the node work next to it. Record the kernel rollout as its own task with the distribution advisory numbers from this post, and close it only when uname -r on every node shows a fixed kernel.

Common mistakes

• Installing the kernel package and not rebooting. The running kernel is still vulnerable. Check uname -r.
• Patching the container image and calling it done. Containers use the node's kernel. The image fix covers PHP; the node fix covers the kernel.
• Blocking modules on a VPN gateway. Blocking esp4 and esp6 stops IPsec. Do it only on hosts that do not use IPsec, and remove the block once patched.
• Rebooting a suspect host before collecting evidence. The disclosed technique changes files in memory only.

FAQ

Is CVE-2026-46300 being exploited?

Yes, according to CISA. As of 29 October 2026, it is in the KEV catalog (added 28 October 2026) and CISA's enrichment in the CVE record marks exploitation as "active". CISA lists known ransomware campaign use as "Unknown".

What is the KEV due date for CVE-2026-46300?

31 October 2026. The PHP CVEs it is chained with were due on 29 October 2026.

Is it remotely exploitable?

Not on its own. The CVSS vector is local and the CNA says a local account is required. CISA says it can be chained with PHP CVE-2026-109618 and CVE-2026-109619, which are remote, to run commands as root.

I patched in May. Am I done?

If every host rebooted into a fixed kernel, the kernel leg is covered. Patch PHP and triage hosts left unpatched after 21 October 2026.

Did Safeguard find this vulnerability?

No. The kernel flaw was disclosed publicly in May 2026 and fixed by the kernel developers and distributions. Safeguard's role is helping you find which of your images and builds carry the affected PHP versions and keeping them out of new builds.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: you install the CLI, ask it to fix a lodash CVE, approve each step as it edits package.json and runs the install and tests, then scan. It shows an npm change, not a PHP or kernel change. For a PHP image you would make the same request against your Dockerfile's base image tag or PHP package pin, then review the diff and run your tests. The kernel still comes from your distribution.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. For a team with many PHP services, that is how you scan each repository and image on your own infrastructure.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask an assistant to look up a CVE's affected and fixed versions and KEV status while you plan the rollout. Whether a given CVE is in your workspace's data depends on your account, so confirm against the CVE record and your distribution's advisory.

Click through it at your own pace, or open it full screen.

To try it on your own images, download Safeguard or start with the CLI documentation.

Quick check

Sources

• CISA Known Exploited Vulnerabilities catalog entry: CVE-2026-46300
• CISA KEV catalog, machine readable feed (catalogVersion 2026.10.28)
• CVE record: CVE-2026-46300 (kernel CNA, with CISA and Red Hat enrichment)
• NVD: CVE-2026-46300
• kernel.org stable commit 3599e6b3cc1a: net: skbuff: preserve shared-frag marker during coalescing
• kernel.org stable commit f84eca581739
• oss-security, 13 May 2026: Re: Linux kernel LPE ("fragnesia"), CVE assignment
• oss-security, 21 May 2026: Linux kernel: Dirty Frag variants, fix merged into netdev
• oss-security, 21 May 2026: follow up on the Dirty Frag variants
• Red Hat CVE page: CVE-2026-46300
• Ubuntu CVE tracker: CVE-2026-46300
• Ubuntu blog: Dirty Frag Linux kernel local privilege escalation vulnerability mitigations
• Debian security tracker: CVE-2026-46300
• SUSE CVE page: CVE-2026-46300
• CVE record: CVE-2026-109618 (PHP) and PHP advisory GHSA-w8hw-w9fx-j79w
• CVE record: CVE-2026-109619 (PHP) and PHP advisory GHSA-6wmf-4rv5-p3rp
• CISA alert, 21 October 2026: Critical vulnerabilities in PHP require immediate patching
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 Implementation Guidance (Forensics Triage Requirements)
• MITRE CWE-456: Missing Initialization of a Variable