CVE on KnightLi Blog

poc-lab Patch Verification: Confirm Whether Recent High-Severity Vulnerabilities Are Fixed, Including Chrome CSSFontFeatureValuesMap UAF, NGINX Rift, Dirty Frag, and Fragnesia

Fri, 22 May 2026 23:13:24 +0800

poc-lab is a repository of PoCs and reproduction scripts for recently disclosed high-severity vulnerabilities. It focuses on fresh and impactful CVE reproduction material across Linux kernel, Windows, macOS, containers, service components, and browser-related vulnerabilities.

From its positioning, the repository is closer to a security research knowledge base than a one-click toolkit for general users. Each vulnerability directory usually includes PoC scripts, build files, and documentation, helping researchers understand impact, reproduction conditions, and references.

Main project contents

The repository is currently organized by vulnerability identifier or public vulnerability name. The full listed vulnerability names include:

CVE-2026-2441: Chrome CSSFontFeatureValuesMap use-after-free, also listed as Chrome CSSFontFeatureValuesMap UAF.
CVE-2026-27623: Pre-Authentication Denial of Service from malformed RESP request.
CVE-2026-31429: Slab Cross-Cache, a Linux kernel slab cross-cache exploitation direction.
CVE-2026-31431: Copy Fail, a Linux kernel related vulnerability.
CVE-2026-31635: DirtyDecrypt, a system security boundary related vulnerability.
CVE-2026-42945: NGINX Rift, a high-severity NGINX related vulnerability.
CVE-2026-43284: Dirty Frag, a Linux kernel related vulnerability.
CVE-2026-43494: PinTheft, a permission or credential security boundary related vulnerability.
CVE-2026-43500: Dirty Frag, a Linux kernel related vulnerability.
CVE-2026-46300: Fragnesia, a Linux kernel related vulnerability.
CVE-2026-46333: SSH Keysign pwn, an SSH keysign security boundary related vulnerability.

These names show that the project is not limited to one platform. It spans browsers, the Linux kernel, server components, and operating system security boundaries. For people working on vulnerability analysis, patch validation, detection rule writing, and security training labs, this kind of material can be useful reference material.

Directory structure

The project README says each vulnerability directory is intended to follow a consistent structure. Common files include:

exploit.py or exploit.sh: PoC script
README.md: vulnerability information, affected versions, reproduction steps, and references
build or related build files: used to compile or prepare the reproduction environment

The repository structure roughly looks like this:

poc-lab/
├── CVE-2026-XXXXX/
│   ├── exploit
│   ├── build
│   └── README.md
├── VULN-NAME/
│   ├── exploit.sh
│   └── README.md
└── ...

If a vulnerability already has a CVE identifier, the directory usually uses that CVE name. If there is no assigned CVE yet, it may use the public vulnerability name.

Suitable use cases

This type of repository is more suitable for the following purposes:

Security researchers reproducing vulnerability trigger conditions.
Enterprise security teams verifying whether patches are effective.
Detection engineers writing IDS, EDR, WAF, or log detection rules.
Security courses or internal training that build isolated lab environments.
Researchers comparing exploitation prerequisites and defensive ideas across vulnerabilities.

It is not suitable for direct production scanning, and it should not be used against unauthorized systems. The value of a PoC is to help understand risk and verify defenses, not to expand attack surface.

What to pay attention to when using it

First, testing must happen in an isolated environment. Vulnerability reproduction may trigger crashes, privilege changes, file corruption, or service outages. It should not be run directly on office machines, production servers, or third-party systems.

Second, read the README.md inside each vulnerability directory first. Different PoCs have different dependencies, target versions, trigger conditions, and risks. Reading only the root README is not enough.

Third, confirm the authorization boundary. Even if a PoC is public, running it against a system you do not own or have explicit permission to test can create legal and compliance risk.

Fourth, after reproduction, return to the defensive workflow. That includes confirming patched versions, adding detection rules, checking exposed assets, updating asset inventories, and documenting incident response procedures.

Why this kind of repository matters

In recent years, the time between high-severity vulnerability disclosure and public reproduction details has become shorter. For defenders, advisories and CVE descriptions are often not enough. Teams also need to understand trigger conditions, exploitation limits, and detection signals in realistic environments.

The value of repositories such as poc-lab is that they organize scattered high-severity vulnerability reproduction material by directory, helping researchers complete risk validation more quickly. It does not replace official advisories, vendor patches, or security baselines, but it can serve as supporting material for patch verification and detection engineering.

There is also risk. Public PoCs lower the reproduction threshold. If an organization does not have timely patch management and asset inventory capabilities, public reproduction material can widen the exposure window. For enterprise security teams, tracking these projects matters, but building a rapid assessment and remediation process matters even more.

Summary

poc-lab is a collection of PoCs and reproduction scripts for recent high-severity vulnerabilities, covering Linux kernel, browsers, service components, and operating system security issues. It is suitable for security research, patch verification, and detection rule development, but it must be used within authorization, isolation, and responsible disclosure boundaries.

For general readers, the point is not “how to run a PoC.” The more important lesson is that after high-severity vulnerabilities become public, verification and exploitation move faster. Security teams need to complete asset identification, patch assessment, detection updates, and risk closure more quickly.

References:

GitHub project: https://github.com/Unclecheng-li/poc-lab/tree/main
Chinese README: https://github.com/Unclecheng-li/poc-lab/blob/main/README.zh-CN.md

CVE-2026-43494 / PinTheft: Local Privilege Escalation Risk from Linux RDS and io_uring

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 is a Linux kernel local privilege escalation risk. The related exploitation chain is also known publicly as PinTheft. The key point is not a remote entry point, but whether a low-privilege local user can line up RDS zerocopy, io_uring fixed buffers, a readable SUID-root program, and a suitable kernel version.

One naming detail is worth clarifying first: the Unclecheng-li/poc-lab repository directory is named CVE-2026-43494 PinTheft, while the README title also mentions QVD-2026-27616 - PinTheft. Based on public CVE entries and third-party advisories, CVE-2026-43494 points to a Linux kernel RDS zerocopy issue where op_nents is not reset correctly, leading to a double-free / reference-counting anomaly. QVD-2026-27616 appears more like a Qianxin risk advisory identifier. In real triage, record both identifiers, but treat distribution security advisories and kernel patch status as the source of truth.

What Is the Core Bug?

The issue appears in the zerocopy send path of Linux RDS, Reliable Datagram Sockets. Public descriptions point to these key functions:

1
2

rds_message_zcopy_from_user()
rds_message_purge()

When iov_iter_get_pages2() fails inside rds_message_zcopy_from_user(), pages that have already been pinned can be released by the error path, but the related op_nents state is not cleared correctly. Later, rds_message_purge() may still release the residual entries again. The result is that the same batch of page references can be decremented too many times, creating an exploitable reference-counting error.

Viewed alone, the RDS bug is an error-path memory-management issue inside the kernel. PinTheft becomes dangerous because the exploitation chain connects it with the io_uring fixed-buffer mechanism: io_uring still keeps an old struct page *, while the page itself has already been freed and reallocated for another purpose. The public PoC then steers this state toward overwriting the page cache of a SUID-root program, eventually reaching local privilege escalation.

Why It Is Called PinTheft

io_uring REGISTER_BUFFERS pins user pages. For normal pages, FOLL_PIN is not just a simple reference increment; it raises the page refcount through a larger bias. The public PoC uses the concept of GUP_PIN_COUNTING_BIAS = 1024.

The name PinTheft means the attack chain repeatedly “steals” those pin references through the RDS zerocopy failure path. After the references are drained, io_uring still believes it holds a valid page, but that physical page can now be freed and reused by the page cache.

This class of vulnerability is easy to misread as “directly modifying /usr/bin/su on disk.” A more accurate description is that the exploitation chain tries to overwrite the in-memory page cache. The file itself may not be written back to disk, but when the kernel executes the SUID program, it may fetch instructions from the contaminated page cache and run the attack payload.

The Trigger Conditions Are Not Broad

This is not a vulnerability where “any Linux server can be remotely hit.” Public information indicates that the exploitation chain depends on at least these conditions:

The kernel has CONFIG_RDS and CONFIG_RDS_TCP enabled.
The system has CONFIG_IO_URING enabled, and kernel.io_uring_disabled=0.
The rds / rds_tcp modules are already loaded, or a low-privilege user can trigger autoloading.
A readable SUID-root binary exists locally, such as /usr/bin/su, /usr/bin/passwd, or /usr/bin/pkexec.
The public PoC also depends on the newer IORING_REGISTER_CLONE_BUFFERS API. CloudLinux analysis notes that the public PoC is more aligned with kernel 6.13 and later.

If any one of these links is missing, the public exploitation path breaks. For example, many RHEL-family distributions do not compile RDS by default, older Ubuntu kernels may lack the io_uring clone-buffer API needed by the PoC, and some environments restrict automatic RDS module loading by unprivileged users.

One-Minute Self-Check

First, check the kernel configuration:

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

Then check whether io_uring is disabled:

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

Interpret the common values like this:

0: allowed, giving the largest exposure.
1: restricted for unprivileged users; exact behavior depends on kernel version and distribution policy.
2: io_uring disabled.

Check whether the RDS modules exist and can be loaded:

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

If CONFIG_RDS is not set, or the system has no rds_tcp module at all, this bug usually cannot be reached. Conversely, if RDS is available, io_uring is not disabled, and the system uses a relatively new general-purpose kernel, continue checking distribution fix status with higher priority.

Which Machines Deserve Priority

Prioritize these environments:

Multi-user Linux hosts, teaching machines, jump hosts, and shared development machines.
Container hosts, especially environments that allow untrusted local users or have a loose container escape surface.
Desktops or servers running newer mainline / rolling kernels, such as Arch-like rolling distributions.
HPC, Oracle RAC, or other scenarios that may genuinely use RDS.
CI workers, build machines, and lab environments that allow unprivileged users to run large amounts of local code.

For an ordinary web server where only controlled service accounts run applications and RDS is not enabled, the practical risk is much lower. But “much lower” does not mean “ignore it”: the typical impact of a kernel local privilege escalation is that an attacker first gains low-privilege access through Web, SSH, CI, containers, or an application bug, then uses the local bug to expand control.

Temporary Mitigation Ideas

The proper fix should still come from the distribution kernel update. Patch status, backported versions, and affected ranges must be checked against advisories from Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, Arch, cloud vendors, or container base-image providers. Do not judge only by the upstream version number.

While waiting for patches, or when an immediate kernel reboot is not possible, choose temporary measures according to the environment:

# If the business does not depend on RDS, block related module loading
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

If the business does not depend on io_uring, consider disabling or restricting it:

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

Persistent configuration needs to be written into the appropriate /etc/sysctl.d/*.conf file. Be careful with this step: modern databases, proxies, runtimes, or high-performance I/O programs may use io_uring. Confirm business dependencies before changing production systems.

How to Verify After Fixing

After upgrading the kernel, do not rely only on package-manager success output. Confirm three things:

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

If a distribution advisory explicitly says CVE-2026-43494 is fixed, the kernel may still be protected even when uname -r does not look like the newest upstream release, because the stable distribution kernel may have received a backported patch. Conversely, if the kernel comes from a self-built tree, third-party repository, cloud marketplace image, or container host template, continue checking the patch commit and build time.

References

Impact Summary of Four Recent Linux Local Security Issues: Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

Several high-profile local security issues have appeared in the Linux ecosystem recently. Individually, they involve different areas: crypto interfaces, network and IPsec paths, page cache handling, and ptrace access checks. Together, they point to the same operational lesson: once an attacker has a low-privilege local execution point, the risk to Linux hosts, container nodes, CI machines, and multi-user servers increases sharply.

This article does not repeat all technical details of each vulnerability. Instead, it summarizes their practical impact and links to four separate articles on this site for deeper reading.

What the Four Events Affect

The four risks worth tracking are:

Copy Fail (CVE-2026-31431): a low-privilege local user may affect the page cache through kernel crypto-related paths and expand privileges.
Dirty Frag (related to CVE-2026-43284 / CVE-2026-43500): risk centers on xfrm/ESP, RxRPC, and related network and kernel data paths, making it dangerous in post-compromise scenarios.
Fragnesia (CVE-2026-46300): close to Dirty Frag, involving XFRM ESP-in-TCP, shared fragments, and page-cache write risk.
ssh-keysign-pwn (CVE-2026-46333): not a direct root-shell bug, but a local information disclosure risk that may expose SSH host private keys, /etc/shadow, and other sensitive files.

The entry points differ, and so do the mitigations. Fixing Copy Fail does not automatically cover Dirty Frag or Fragnesia. Disabling some network modules does not automatically remove the information disclosure risk around ssh-keysign-pwn.

Copy Fail: High Priority for Containers and CI Nodes

The key impact of Copy Fail is not an application crash. It is that low-privilege execution may be turned into root privileges. It is especially sensitive in these environments:

CI/CD nodes that allow users to upload or run code.
Container hosts running untrusted workloads.
Development machines, jump hosts, and shared servers.
Cloud hosts running older kernels with slower patch cycles.

The danger is that Copy Fail has a relatively low exploitation threshold and combines easily with container scenarios. Many teams treat containers as a strong isolation boundary, but ordinary containers still share the host kernel by default. If an attacker gets a shell inside a container, a kernel LPE can turn a container issue into a host issue.

Detailed analysis: Copy Fail CVE-2026-31431: Container Escape Risk in a Linux Kernel File-Copy Path.

Dirty Frag: A Post-Compromise Amplifier

Dirty Frag is more like a privilege amplifier after an attacker has entered a system. It is not a typical remote unauthenticated vulnerability. The usual prerequisite is that the attacker already has local execution through a weak password, WebShell, low-privilege service account, container task, or another foothold.

Its practical impact appears in several places:

A compromised low-privilege account may become root.
A low-privilege execution point inside a container may threaten the host.
Systems using IPsec, ESP, RxRPC, or related kernel networking capabilities need careful patch and mitigation review.
Security teams should look beyond perimeter defense and include post-compromise privilege escalation chains.

Dirty Frag reminds operations teams that local privilege escalation may not be the first entry point, but it can decide how far an intrusion goes. Once a low-privilege foothold exists, attackers will look for kernel bugs to push privileges to the highest level.

Detailed analysis: Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide.

Fragnesia: Similar Attack Surfaces Are Not Cleaned Up All at Once

Fragnesia matters because it shows that the attack surface near Dirty Frag is not an isolated one-off issue. Even if one bug is fixed, neighboring paths, similar data structures, and related module combinations may still contain new exploitable points.

Its operational impact is mainly:

Do not handle only the vulnerability name once. Keep checking by attack surface.
esp4, esp6, rxrpc, XFRM, and ESP-in-TCP should be evaluated against actual business dependencies.
If a system does not depend on the related network capabilities, temporary disabling may be considered, but it must be tested first to avoid breaking VPN, IPsec, tunnels, or internal networking.
Page-cache pollution risks can create detection blind spots where files appear unchanged, but the execution path is affected.

For enterprises, the biggest lesson is that patch management should not look only at a single CVE. A safer approach is to build an inventory around subsystems and attack surfaces, then identify which machines expose the relevant capabilities and which services truly need those modules.

Detailed analysis: Fragnesia (CVE-2026-46300): Linux Kernel Local Privilege Escalation Impact and Mitigation.

ssh-keysign-pwn: Not Direct Root, Still Dangerous

ssh-keysign-pwn differs from the previous three. It is more of a local sensitive information disclosure issue than a direct root-shell vulnerability. But in real attacks, sensitive information disclosure can quickly become a larger incident.

The main impacts include:

Leaked SSH host private keys may damage host identity trust.
Access to files such as /etc/shadow can lead to offline cracking and account takeover.
Multi-user servers, jump hosts, build machines, and shared development machines carry higher risk.
Even without immediate privilege escalation, attackers may obtain credential material useful for lateral movement.

This type of issue is easy to underestimate because it does not look as dramatic as a direct root shell. In enterprise environments, however, key and password-hash exposure often means a longer cleanup cycle: rotating SSH host keys, reviewing trust relationships, checking account passwords, and auditing login logs.

Detailed analysis: ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk.

Shared Impact: Containers Are Not a Strong Boundary by Default

Taken together, these four events make one point clear: ordinary container isolation is not virtual-machine isolation.

Docker, containerd, and Kubernetes use namespaces, cgroups, capabilities, seccomp, AppArmor, and SELinux to reduce attack surface, but they usually still share the host kernel. If the vulnerability is in the shared kernel, a low-privilege execution point inside a container can become an entry point.

High-risk environments should check:

Whether untrusted code is allowed to run on shared hosts.
Whether containers run as root by default.
Whether unnecessary capabilities are granted.
Whether seccomp policies are too broad.
Whether multi-tenant workloads should move to gVisor, Kata Containers, Firecracker microVM, dedicated virtual machines, or dedicated nodes.

CI/CD platforms deserve special attention. Build jobs naturally run external code, dependency install scripts, test scripts, and temporary binaries. If these jobs share hosts with long-running services, one local privilege escalation can affect much larger infrastructure.

Shared Impact: Patches Must Reach the Running Kernel

A common Linux kernel patching mistake is assuming that an installed package means the machine is running the fixed kernel.

At minimum, operations teams should verify three things:

`1`	`uname -a`

Check the currently running kernel.

`1`	`dpkg -l \| grep linux-image`

Or on RHEL-family distributions:

`1`	`rpm -qa \| grep kernel`

Check installed kernel packages.

Finally, confirm that the machine has rebooted into the fixed kernel. For core services that cannot reboot immediately, evaluate livepatch, hot patching, or short-term isolation, but do not treat temporary mitigation as the final fix.

Shared Impact: Attack Surface Reduction Must Be Specific

These vulnerabilities remind us that Linux hardening cannot stop at “update the system” and “enable a firewall.”

More specific checks include:

Whether AF_ALG / algif_aead is used by business workloads.
Whether XFRM, ESP, ESP-in-TCP, and IPsec are required by VPNs, tunnels, or security gateways.
Whether RxRPC is needed.
Whether unprivileged user namespaces must be enabled.
Whether containers can create overly broad socket types.
Whether ptrace access policies are too loose.

If the business does not need certain capabilities, evaluate disabling modules, adjusting sysctl settings, tightening seccomp, and reducing capabilities. Do not blindly copy commands into production. Inventory dependencies first, then roll out changes gradually.

Suggested Response Order

First, prioritize machines where local code execution is exposed:

Container hosts.
CI/CD runners.
Jump hosts.
Multi-user servers.
Hosts running external-facing services.
Systems running untrusted plugins, scripts, or extensions.

Second, confirm distribution advisories and the actual running kernel. Do not rely only on upstream version numbers. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, openEuler, and other distributions may backport security fixes.

Third, tighten container runtime policies. Prefer non-root users, minimal capabilities, no-new-privileges, read-only filesystems, and explicit seccomp plus AppArmor or SELinux policies.

Fourth, review key and credential exposure. Especially for environments affected by ssh-keysign-pwn, evaluate whether SSH host keys, /etc/shadow, jump-host credentials, and CI secrets need rotation.

Fifth, improve monitoring. Watch for abnormal root shells, suspicious local LPE PoCs, critical file changes, abnormal ptrace behavior, container processes accessing host paths, and unusual network connections from CI nodes.

Conclusion

The point of these four events is not “Linux is insecure.” The point is that default trust is no longer enough.

Linux remains transparent, fixable, configurable, and hardenable. But in environments where containers, CI, multi-tenancy, and AI-driven code execution are increasingly common, a low-privilege execution point can no longer be treated as a minor issue. If the kernel contains exploitable local privilege escalation or sensitive information disclosure bugs, a partial intrusion can become host control, credential exposure, or lateral movement.

A more realistic approach is to treat these four events as a reminder: patch quickly, confirm rebooted kernels, enable modules only when needed, tighten containers, make key rotation possible, and reassess isolation levels for multi-tenant workloads.

ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn refers to a set of exploitation paths around a logic flaw in Linux kernel __ptrace_may_access(), assigned CVE-2026-46333. It is not a remote unauthenticated flaw and it does not directly hand out a root shell, but the risk is still high: a low-privileged local user may read root-owned sensitive files that should be inaccessible, such as SSH host private keys or /etc/shadow.

For operations teams, the priority is not reproducing a PoC. The priority is to identify affected machines, upgrade the kernel, reboot into the fixed kernel, and rotate SSH host keys or reset passwords when necessary.

Bottom line

This vulnerability deserves high handling priority for four reasons:

It can be triggered by a low-privileged local user and does not require root.
Public PoC code is available, lowering the exploitation barrier.
The potential targets are not ordinary files, but SSH host private keys and /etc/shadow.
The fix requires a kernel patch and reboot; installing packages without rebooting is not enough.

If your servers have multiple users, local shell access, shared hosting, CI runners, container hosts, student lab machines, bastion hosts, or any local users you do not fully trust, handle this first.

What the vulnerability is

Qualys disclosed details on oss-security on May 15, 2026. They had previously reported a Linux kernel __ptrace_may_access() logic issue to security@kernel.org, and the upstream fix had already been merged by Linus. Public exploit code then appeared, so Qualys posted the details to oss-security.

The Linux kernel CVE team later assigned CVE-2026-46333. The NVD page lists kernel.org as the source, and the description maps to the kernel commit ptrace: slightly saner 'get_dumpable()' logic.

In simple terms, the bug sits in a process exit path. When some privileged processes are exiting, ptrace-related access-check logic in the kernel may bypass a dumpable check that should have applied because the target task no longer has an mm. An attacker can race a very narrow timing window and obtain file descriptors that the exiting privileged process still has open.

That is why the issue is called ssh-keysign-pwn: one public exploitation path uses ssh-keysign to read SSH host private keys.

Why SSH host private keys and /etc/shadow may be exposed

At its core, this is a local information disclosure issue. It abuses a window during privileged process exit where the memory descriptor is gone, but file descriptors have not yet been closed.

The AlmaLinux advisory explains the risk clearly: if a privileged program opened sensitive files before dropping privileges, and an attacker successfully grabs the corresponding file descriptor during the exit window, those sensitive files may become readable.

Two commonly discussed targets are:

ssh-keysign: may involve SSH host private keys such as /etc/ssh/ssh_host_*_key.
chage: may involve /etc/shadow.

If SSH host private keys leak, an attacker may impersonate the host and undermine SSH host identity trust. If /etc/shadow leaks, an attacker can crack password hashes offline and expand the compromise later.

That is why this should be treated as high priority even though it is not a “direct root shell” bug.

How to assess exposure

From the upstream perspective, this is a Linux kernel vulnerability. NVD records show the issue entered the NVD dataset on May 15, 2026, with no CVSS score assigned at that time.

Distribution status should be checked against each vendor’s own advisory:

AlmaLinux 8, 9, and 10 published guidance and updated it on May 16, 2026 to say patched kernels had reached production repositories.
Debian Security Tracker lists vulnerable and fixed states, plus fixed versions, for bullseye, bookworm, trixie, sid, and other branches.
For other distributions, check the official security pages or repositories for Ubuntu, Red Hat, SUSE, Arch, Alpine, and so on.

Do not judge safety only by the upstream kernel version. Distributions backport fixes, so the same upstream-looking version number may mean different patch states across distributions.

Which machines to prioritize

Prioritize remediation in this order:

Multi-user servers and shared hosts.
Bastion hosts, teaching machines, development machines, and other systems with normal shell accounts.
CI runners, build machines, and hosting platform nodes.
Container and virtualization hosts, especially where not-fully-trusted workloads coexist.
Public service machines. The vulnerability needs local access, but the risk compounds once a web bug, RCE, weak password, or similar path gives an attacker a low-privileged foothold.

Pure single-user desktop systems are lower risk, but they should still be updated. Local low-privileged code execution is common on desktops through browsers, developer tools, scripts, and third-party software.

Remediation guidance

The preferred fix is to install the fixed kernel supplied by your distribution and reboot.

Commands differ by distribution, but the principle is the same:

Refresh package metadata.
Install the kernel package containing the CVE-2026-46333 fix.
Reboot into the new kernel.
Use uname -r and the distribution security advisory to verify the running kernel is fixed.

The AlmaLinux advisory says fixed kernels are available in production repositories and users can run the usual dnf upgrade and reboot. The Debian tracker also lists fixed versions for multiple branches.

Important: if you only install a new kernel package but do not reboot, the old vulnerable kernel is still running.

Temporary mitigation: tighten ptrace_scope

If you cannot reboot immediately, tighten Yama ptrace_scope first.

Qualys confirmed in a follow-up oss-security reply that setting /proc/sys/kernel/yama/ptrace_scope to 2 (admin-only attach) or 3 (no attach) blocks the public exploitation paths they know about. They also noted that other theoretical exploitation paths may exist, so this is only a mitigation, not a fix.

Temporary setting:

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

Persistent setting:

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 disables ptrace attach and may affect debugging workflows such as gdb and strace -p. If production debugging is required, evaluate 2. Either way, schedule the kernel upgrade and reboot as soon as possible.

Should SSH host keys be rotated?

Use a conservative approach if the machine had any of the following conditions around the disclosure window:

Untrusted local users.
Shared hosting or container/CI multi-tenant environments.
Web vulnerabilities, weak passwords, supply-chain scripts, or other paths that could give an attacker a local foothold.
Suspicious local processes, unusual debugging behavior, or public PoC files in logs.
Long exposure before patching.

Conservative handling includes:

Rotate SSH host keys after patching and rebooting.
Update known-host fingerprint management systems.
Notify automation that depends on the host fingerprint.
Review SSH connection alerts so legitimate fingerprint changes are not mistaken for man-in-the-middle attacks, and real risks are not ignored.

If /etc/shadow may have leaked, also evaluate password resets, weak-password bans, and whether old hashes could be cracked offline.

What to monitor

The exploitation window is short, so traditional logs may not capture everything. Still, watch for:

Files such as ssh-keysign-pwn, chage_pwn, or similar PoC artifacts in normal user directories.
Suspicious compilation activity, such as unfamiliar C programs compiled in a short window.
Signs of abnormal access to /etc/ssh/ssh_host_*_key or /etc/shadow.
Unusual pidfd_getfd, ptrace, or debugger-related activity.
External reports of unexpected SSH host fingerprint changes.

These signals cannot prove exploitation occurred, and their absence cannot prove it did not. The real priorities remain patching, rebooting, credential rotation, and risk isolation.

Common misconceptions

First: this is not an OpenSSH remote vulnerability. The name includes ssh-keysign, but the root cause is Linux kernel ptrace access-check logic, not the remote authentication path in sshd.

Second: no local users does not mean no risk. The bug does require local execution, but real attack chains often obtain a low-privileged local foothold first through web services, CI, scripts, weak passwords, or container escape paths.

Third: setting ptrace_scope is not enough. It is a temporary mitigation, not the root fix. Kernel update and reboot are still required.

Fourth: “no root shell” does not mean “no incident.” Exposure of SSH host private keys or /etc/shadow can be enough to enable lateral movement, host impersonation, and offline password cracking.

Response checklist

Suggested order:

Inventory affected Linux hosts, especially multi-user and shared environments.
Check distribution security advisories and identify the fixed kernel version.
Install the fixed kernel and reboot.
For machines that cannot reboot immediately, set kernel.yama.ptrace_scope=2 or 3.
After remediation, verify the running kernel version.
Rotate SSH host keys on high-risk machines.
If /etc/shadow exposure is suspected, evaluate password resets and account audits.
Check for public PoCs, unusual compilation, and suspicious local debugging behavior.

Summary

ssh-keysign-pwn (CVE-2026-46333) is a local information disclosure vulnerability rooted in Linux kernel __ptrace_may_access() logic. It does not allow a remote attacker to break in directly and it does not directly grant a root shell, but it may let a low-privileged local user read high-value sensitive files, making it especially important in multi-user, shared hosting, CI, and container-host environments.

The reliable fix is to upgrade to a distribution-provided fixed kernel and reboot. ptrace_scope=2/3 can be used as a temporary mitigation, but it does not replace patching. Critical hosts exposed during the risk window should also be evaluated for SSH host key rotation and password risk.

References:

How to Check CVE-2026-42945: Nginx Rift Trigger Conditions, Version Checks, and Upgrade Advice

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 is a security vulnerability in NGINX Open Source and NGINX Plus. It is also being referred to as Nginx Rift. The issue is in ngx_http_rewrite_module, and the vulnerability type is heap-based buffer overflow.

News like this is easy to turn into headlines such as “hidden for 18 years”, “remote control without a password”, or “30% of servers affected”. Those claims travel well, but when reading the patch notes and NVD description, it is better to separate the risk into concrete pieces: the issue is serious, and it does not require a logged-in account; but not every Nginx instance is automatically compromised. Triggering it requires specific rewrite configuration and request conditions.

Start with the official description

The NVD description of CVE-2026-42945 can be summarized as follows:

It affects NGINX Plus and NGINX Open Source.
The vulnerability is in ngx_http_rewrite_module.
The issue may be triggered when a rewrite directive is followed by a rewrite, if, or set directive, unnamed PCRE capture groups such as $1 and $2 are used, and the replacement string contains a question mark ?.
An unauthenticated attacker can send a crafted request to trigger the vulnerability.
The result may be a heap buffer overflow and restart of an NGINX worker process.
If ASLR is disabled on the system, code execution is possible.

F5, as the CNA, gives the following scores:

CVSS v4.0: 9.2, Critical.
CVSS v3.1: 8.1, High.
CWE: CWE-122 Heap-based Buffer Overflow.

So this is not a routine “bad config causes a 404” issue. It is a memory safety vulnerability covered by an official Nginx security fix.

Which claims need context

First, “no password required” is best understood as unauthenticated attack. In other words, the attacker does not need to log in to an Nginx admin panel, obtain SSH access, or hold an application account. But that does not mean every public-facing Nginx instance can be casually taken over.

Second, “direct remote control” depends on conditions. The more careful official framing is that the vulnerability can cause worker process restarts; on systems where ASLR is disabled, code execution is a possible outcome. On environments with ASLR enabled, proper distribution hardening, and restricted runtime privileges, the exploitation path becomes more complex.

Third, “30% of servers affected” should not be treated as “all Nginx market share equals exposed attack surface”. Real exposure depends on the version, whether the affected module is present, whether the specific rewrite configuration exists, whether the distribution has already backported the patch, and how hardened the Nginx runtime environment is.

The more accurate approach is simple: if you run Nginx in production, check it quickly; but do not decide whether you are affected based only on a headline percentage.

How to determine the affected scope

According to nginx.org release information, the nginx-1.30.1 stable release and nginx-1.31.0 mainline release published on May 13, 2026 include multiple security fixes, including the ngx_http_rewrite_module buffer overflow tracked as CVE-2026-42945.

If you use official Nginx source builds or official packages, focus on:

NGINX Open Source stable: upgrade to 1.30.1 or later.
NGINX Open Source mainline: upgrade to 1.31.0 or later.
NGINX Plus: check the fixed version for your F5-supported branch.

If you use Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Alpine, container images, Plesk, control panels, Ingress Controller, or cloud-provider managed components, do not rely only on the upstream version shown by nginx -v. Many distributions backport security fixes into older package versions. The version string may look old while the patch is already included.

One-minute urgency check

Use these questions for a quick risk tiering:

Is this Nginx instance directly exposed to the internet, or is it part of an API Gateway, reverse proxy, load balancer, or Ingress entry layer?
Are you using official Nginx packages, source builds, third-party control panels, or container images without having confirmed the CVE-2026-42945 fix status?
Does the configuration contain complex rewrite rules, especially consecutive rewrite, if, or set directives and unnamed captures such as $1 and $2?
Does any rewrite target include request paths, query parameters, or other user-controlled input?
Is the system weakly hardened, for example with ASLR disabled, overly privileged workers, or overly broad container permissions?

If the first two items apply and rewrite configuration has not yet been reviewed, treat it as high priority. Public entry points, shared environments, Kubernetes Ingress, edge proxies, and Nginx instances carrying login or API traffic should be upgraded or replaced with a confirmed fixed package first.

How to confirm fixes on Debian / Ubuntu / RHEL / Alpine

Distribution users should not look only at nginx -v. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, and Alpine often backport security patches into stable branches, so the visible version may still be lower than nginx.org’s 1.30.1 or 1.31.0.

On Debian / Ubuntu, check security advisories, package changelog, and upgrade candidates:

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

On RHEL / AlmaLinux / Rocky Linux, check security updates and package changelog:

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

On Alpine, check the installed package version and security branch updates:

1
2

apk info -v nginx
apk version -v nginx

If the package manager, distribution security advisory, or vendor advisory explicitly says CVE-2026-42945 is fixed, you can treat it as backported even if the upstream version number looks old. Conversely, if the version looks new but the source is unclear, still confirm the build date and patch source.

How to check container images and Ingress Controller

In container environments, check the Nginx inside the image, not only the host. First confirm the actual embedded version:

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

Also check whether the base image has been updated. If the image is built on Debian, Ubuntu, Alpine, or distribution packages, apply the same advisory and changelog checks for that distribution. Restarting an old image is not useful; the image itself needs to be rebuilt or replaced.

For Kubernetes Ingress, confirm three things:

Whether the Ingress Controller project has published an advisory or fixed release for CVE-2026-42945.
Whether the running controller image digest has actually changed, rather than only the tag.
Whether the controller’s embedded Nginx version, build flags, and template configuration still contain high-risk rewrite rules.

Start by checking the running image:

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

If you use a cloud-provider managed Ingress or gateway, check the corresponding cloud service advisory. Managed components usually cannot be fixed by running apt upgrade yourself; you need the provider’s fix or a switch to a fixed version.

Which rewrite patterns deserve attention

This vulnerability is related to rewrite configuration. Start by searching Nginx configuration:

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

Pay attention to patterns like:

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

The unnamed captures such as $1 and $2, plus the ? in the replacement target, are among the key conditions described by the official sources. During review, pay special attention to:

A rewrite followed by another rewrite, if, or set.
Broad captures such as (.*) and (.+) that are reused as $1 or $2.
Rewrite targets containing ? to append or discard query parameters.
Rewrite input coming from public paths, Host, URI, parameters, or upstream-controlled values.
Rewrite rules generated by panels, gateways, Ingress annotations, or templates.

If you cannot upgrade immediately, use temporary mitigations:

Reduce complex rewrite rules.
Replace unnamed captures with clearer named captures.
Avoid unnecessary ? concatenation in replacement strings.
Add WAF or reverse-proxy rules for high-risk entry points.
Confirm that ASLR is enabled.
Reduce Nginx worker privileges and verify systemd sandboxing, SELinux/AppArmor, and related hardening.

These measures are mitigations, not replacements for patching.

Remediation priority

Prioritize by exposure:

Public-facing Nginx entry points.
Reverse proxies, API Gateway, and edge gateways.
Nginx in multi-tenant environments.
Kubernetes Ingress Controller.
Plesk, control panels, marketplace images, and other components that bundle Nginx.
Internal Nginx instances that carry critical business traffic.

How to verify after upgrading: nginx -t, reload, and worker state

After updating, do not stop at “the package manager succeeded”. Confirm the configuration, process state, and actual binary have all switched over. First validate the configuration:

`1`	`nginx -t`

If there are no errors, reload smoothly:

`1`	`systemctl reload nginx`

If the package upgrade replaced the binary, confirm old workers have exited:

`1`	`ps aux \| grep nginx`

You can also inspect the master process start time and binary path to ensure the running service is not an old process still resident in memory. If needed, schedule a maintenance window and restart the service so old workers or old containers do not continue handling requests.

For containers and Ingress, also confirm the new image rollout has actually completed:

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

The key verification question is not “did the command run”, but “is live traffic now handled by Nginx processes that include the fix”.

Do not ignore the same Nginx security batch

The 1.30.1 and 1.31.0 releases published by nginx.org on the same day fixed more than CVE-2026-42945. The release information also mentions HTTP/2 request injection, SCGI/uWSGI buffer overread, charset module buffer overread, HTTP/3 address spoofing, OCSP resolver use-after-free, and other issues.

That means production environments should not only add a temporary rule for a single CVE. Treat this Nginx security release as an overall upgrade.

Summary

The key point of CVE-2026-42945 is not “all Nginx instances can be instantly taken over”. It is a long-standing memory safety vulnerability in the rewrite module that can be triggered by unauthenticated requests under specific configurations. The most direct result is worker crash and restart; on weaker environments such as systems with ASLR disabled, code execution risk is higher.

For operations teams, the handling order is straightforward:

Confirm the Nginx source and version.
Check distribution, F5, nginx.org, or cloud-provider advisories.
Upgrade to a fixed version or distribution security package as soon as possible.
Review complex rewrite configuration, especially combinations of $1, $2, and ?.
Confirm ASLR, privilege isolation, and service reload state.

The headline can be scary. The fix should be calm: confirm exposure, upgrade, then clean up high-risk rewrite rules.

References

Dirty Frag, Copy Fail, and Fragnesia: Comparing Three Recent Linux Local Privilege Escalation Flaws

Fri, 15 May 2026 13:24:04 +0800

Several high-profile Linux kernel local privilege escalation vulnerabilities have appeared recently: Dirty Frag, Copy Fail, and Fragnesia. They look like a single family of events because the end result is similar: a low-privilege local user may be able to become root.

But from an operations perspective, they should not be treated as one vulnerability. Their entry modules, trigger paths, mitigation options, and patch timelines differ. A better way to understand them is this: they expose a shared risk around the complex boundary between the Linux page cache, splice, socket buffers, and crypto paths.

This post only covers risk and response analysis. It does not include reproducible exploitation steps.

What the Three Flaws Are

Dirty Frag: CVE-2026-43284

Dirty Frag mainly points to a page-cache write issue in the Linux kernel networking path. Public write-ups usually discuss it together with two issues: the xfrm-ESP side, CVE-2026-43284, and the rxrpc side, CVE-2026-43500.

CVE-2026-43284 is related to in-place decryption when ESP handles shared skb fragments. The key point is not that an attacker directly modifies a disk file, but that the kernel can write to shared pages it should not modify, affecting file contents in the page cache.

Operationally, remember that Dirty Frag reaches esp4, esp6, and rxrpc, a set of kernel modules and networking subsystem paths. It is tied to IPsec, ESP, and RxRPC, so temporary mitigation also focuses on those modules.

Copy Fail: CVE-2026-31431

Copy Fail is a Linux kernel local privilege escalation vulnerability disclosed by Theori / Xint Code. Its entry point is not the IPsec networking path, but the kernel userspace crypto API around algif_aead / AF_ALG.

Public explanations describe it as originating from an in-place optimization introduced in 2017. In some cases, the kernel failed to copy data as expected and instead placed page-cache pages into a writable destination path. An attacker can combine AF_ALG with splice() to perform a small controlled write to page-cache-backed pages.

Its risk comes from strong exploitability and broad impact across mainstream distributions. Unlike Dirty Frag, Copy Fail’s temporary mitigation focuses on restricting or disabling algif_aead, and on limiting AF_ALG socket creation in container and CI environments.

Fragnesia: CVE-2026-46300

Fragnesia is another Linux kernel local privilege escalation vulnerability disclosed by V12 Security, and it belongs to a similar attack surface as Dirty Frag. It is not the same bug as Dirty Frag, but it still revolves around IPsec ESP / rxrpc related modules and page-cache write effects.

AlmaLinux describes it as the third local-root issue in the same broad code area. The key problem is that skb_try_coalesce() did not preserve the shared-fragment marker when coalescing socket buffer fragments, which could later let the XFRM ESP-in-TCP receive path decrypt in place over external page-cache pages.

In short, Fragnesia is closer to Dirty Frag. Both revolve around esp4, esp6, rxrpc, skb fragments, and ESP decryption paths. Their temporary mitigations also overlap heavily.

Similarities: Why They Are Dangerous

The common thread is not that the exact code locations are identical, but that the attack outcome and risk model are very similar.

First, all three are local privilege escalation issues. Attackers usually need ordinary local code execution first, then they can attempt to become root. For a single-user desktop this is not remote one-click compromise; for multi-user servers, CI runners, container hosts, shared development machines, and VPS instances with exposed SSH, low-privilege entry points are not rare.

Second, all three involve page-cache writes. Attackers may not permanently modify the file on disk; instead, they affect the in-memory page-cache copy. This makes traditional integrity checks less reliable: the disk hash can remain normal while the execution path reads polluted page-cache content.

Third, they are closer to deterministic logic bugs than timing-sensitive race conditions. Public material repeatedly notes that these issues do not require winning a race condition. Defenders should not underestimate exploit reliability based on older assumptions.

Fourth, they amplify the risk of container and automation environments. Low-privilege code inside containers, CI jobs, build scripts, or third-party plugins can turn a “local issue” into a platform-level issue if it can reach the relevant host kernel interfaces.

Differences: One Mitigation Does Not Cover All

The biggest difference is the entry module.

Copy Fail’s critical entry point is algif_aead / AF_ALG, part of the kernel userspace crypto API. Its temporary defense focuses on disabling or restricting algif_aead, and using seccomp to block containers from creating AF_ALG sockets.

Dirty Frag’s critical entry point is xfrm-ESP and rxrpc. It is closer to protocol and socket buffer handling paths. Temporary defense typically considers disabling esp4, esp6, and rxrpc, but that can affect IPsec, VPNs, tunnels, or related networking capabilities.

Fragnesia sits in a similar region to Dirty Frag, but the concrete issue is that skb_try_coalesce() did not preserve the shared-fragment marker. It is more like another branch of the Dirty Frag risk surface than a Copy Fail crypto API issue.

So, fixing Copy Fail does not mean Dirty Frag and Fragnesia are covered. Likewise, disabling esp4 / esp6 does not automatically remove Copy Fail. Their patch state and mitigation strategy must be checked separately.

How to Judge Exposure

For these vulnerabilities, do not judge only by distribution name or kernel major version. Distributions backport fixes, cloud vendors maintain their own kernel branches, and enterprise distributions may carry additional patches.

A safer sequence is:

Check the distribution security advisory and kernel package changelog.
Verify whether the current kernel package fixes the relevant CVE.
For cloud servers, container hosts, and CI nodes, also check cloud or platform advisories.
For temporary mitigations, confirm whether the business depends on the affected module.
After a kernel update, schedule a reboot and confirm the running kernel has changed.

The most common trap is “the package is updated, but the machine has not rebooted.” Kernel vulnerabilities are not like ordinary userspace service updates. Until the system boots into the new kernel, the old kernel may still be running.

Operational Priority

The systems that deserve the highest priority are not all Linux machines equally. Start where low-privilege code execution is most likely.

Highest-priority environments include:

Multi-user login servers
CI / CD runners
Build and artifact packaging machines
Container hosts and Kubernetes nodes
Shared development machines
Cloud servers and VPS instances exposing SSH
Platforms running third-party scripts, plugins, or job queues
Machines with web vulnerabilities, weak passwords, or historical compromise signals

Closed, single-user machines with no external code execution entry point are still at risk if vulnerable, but they can usually be handled later.

How to Treat Temporary Mitigation

Temporary mitigation is not a replacement for a patch. Its value is reducing exposure when you cannot immediately reboot or are waiting for distribution packages.

For Copy Fail, focus on algif_aead and AF_ALG. If the business does not use the kernel AF_ALG crypto interface, evaluate disabling the related module. In container environments, check seccomp policies first so untrusted workloads cannot freely create the relevant socket.

For Dirty Frag and Fragnesia, focus on esp4, esp6, and rxrpc. If the system does not depend on IPsec ESP, related VPNs, tunnels, or RxRPC, consider temporary disabling. Do not do this blindly in production because these modules may support real networking workloads.

The final path is still a kernel update. Temporary mitigation can reduce attack surface, but it cannot prove the system is fully safe.

What These Three Flaws Tell Us

The important warning is not just the number of CVEs. These flaws all cluster around high-complexity kernel paths: zero-copy, splice, socket buffers, the page cache, crypto interfaces, and protocol-stack optimizations.

These paths deliver performance, but their ownership boundaries are hard to maintain. Whether a fragment is shared, whether a page may be written in place, and whether an optimization truly only reduces copying all become security boundaries.

For security and operations teams, the takeaways are practical:

Treat local privilege escalation as an amplifier for existing low-privilege entry points.
Containers are not a natural isolation boundary for kernel vulnerabilities.
File integrity checks cannot look only at disk contents.
CI, build machines, and plugin platforms are high-priority assets.
Kernel patching requires verifying both “installed” and “running” states.

Summary

Dirty Frag, Copy Fail, and Fragnesia are all high-priority recent Linux local privilege escalation events, but they are not three names for one vulnerability.

Copy Fail goes through the algif_aead / AF_ALG crypto API path. Dirty Frag goes through xfrm-ESP and rxrpc. Fragnesia, in a nearby Dirty Frag attack surface, again triggers page-cache write risk through skb fragment marker handling.

Operationally, the safest response is to update the kernel according to distribution advisories and reboot. For systems that cannot be updated immediately, evaluate temporary module disabling or tighter seccomp rules based on the actual vulnerability entry point. Prioritize multi-tenant systems, CI, container hosts, and shared development environments.

References:

Theori Copy Fail notes: https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail advisory: https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag notes: https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia notes: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC notes: https://github.com/v12-security/pocs/tree/main/fragnesia

May 2026 Edge High-Risk Vulnerability CVE-2026-2441: Malicious Pages May Trigger Remote Code Execution

Wed, 06 May 2026 08:30:17 +0800

Microsoft Edge has recently released several rounds of security updates to fix multiple issues from the Chromium project and Edge components. Among them, CVE-2026-2441 has been reported by the Chromium team as exploited in the wild, and fixes have been provided for both the Microsoft Edge Stable and Extended Stable channels.

If you use Edge for daily browsing, especially on Windows devices used for account logins, email, online banking, admin consoles, or enterprise systems, you should confirm that the browser has been updated to the latest version.

Vulnerability Risk

CVE-2026-2441 is a high-risk vulnerability that has already attracted attacker attention and has been exploited. A common browser attack path is to lure users to a page containing specially crafted content, then trigger a flaw in the rendering engine or related components.

In real attacks, this type of vulnerability may lead to the following risks:

Execute malicious code or chain with other vulnerabilities to break through sandbox restrictions.
Bypass some security controls and expand the attack surface.
Steal sensitive browser data, session information, or page content.
Cause browser crashes, abnormal page behavior, or denial of service.

Official vendors usually do not disclose full attack details immediately after a patch is released, to avoid making the vulnerability easier to reproduce. For most users, the most effective protection is to update promptly.

Affected Scope

Microsoft Edge is based on Chromium, so related vulnerabilities can affect Edge versions across multiple platforms, including Windows, macOS, Linux, and mobile versions. Any browser version below a fixed release remains at risk.

According to the Microsoft Edge security update release notes, Edge Stable Channel 145.0.3800.58, released on February 14, 2026, includes the fix for CVE-2026-2441; Extended Stable Channel 144.0.3719.130, released on February 17, 2026, also includes the fix. Later versions continue to include accumulated Chromium security patches.

As of May 6, 2026, the latest Stable Channel security version listed on the Edge security update page is 147.0.3912.98, released on April 30, 2026. If your local version is clearly older than these releases, update immediately.

Update Edge Now

Regular users can check and update Edge with these steps:

Open Microsoft Edge.
Enter edge://settings/help in the address bar and press Enter.
Wait for the browser to check for updates automatically.
After the update finishes, click “Restart”.

In enterprise environments, administrators should check endpoint management policies, WSUS, Intune, Group Policy, or third-party patching systems to make sure Edge updates are not being delayed for too long. For devices that cannot be updated immediately, reduce access to unknown websites and prioritize limiting external web access for high-risk user groups.

Protection Suggestions

Upgrade Edge as soon as possible and restart the browser after the update.
Do not click email links, chat links, or ad redirects from unknown sources.
Avoid using outdated browsers to access admin consoles, payment services, email, or other sensitive pages.
Keep Windows, antivirus software, and browser extensions updated.
Remove browser extensions that are unused or from unclear sources.

References

Summary

The key point about CVE-2026-2441 is not how complex the vulnerability details are, but that it has been reported as exploited in the wild. For personal users and enterprise endpoints, the most direct response is to open edge://settings/help, confirm that Edge has finished updating, and restart the browser.

Copy Fail CVE-2026-31431: Container Escape Risk in the Linux Kernel File-Copy Path

Fri, 01 May 2026 18:42:34 +0800

Copy Fail is a vulnerability in the Linux kernel file-copy path, tracked as CVE-2026-31431. Bugcrowd’s analysis describes it as a kernel-level issue worth attention: under specific conditions, an unprivileged user can abuse file-copy logic to trigger unauthorized writes, leading to privilege escalation or container escape.

From a risk perspective, this is not a normal application-layer vulnerability. The issue happens in the kernel path that handles file copying and page cache behavior, so its impact can extend to containers, shared hosts, CI/CD runners, PaaS platforms, and multi-tenant Linux environments. If an attacker can already run low-privileged code on a system, the vulnerability may become a stepping stone for breaking through isolation boundaries.

Where the Vulnerability Roughly Lives

Copy Fail is related to Linux kernel file-copy capabilities. Modern Linux provides several efficient copy paths, such as copy_file_range, splice-like paths, and data-copy optimizations across different file systems. These mechanisms are designed to reduce data movement between user space and kernel space and improve large-file copy performance.

The problem is that high-performance copy paths often reuse page cache, file offsets, permission checks, and file-system callbacks. If a boundary condition is not handled strictly enough, the kernel may perform a write in the wrong permission context, or expose data pages that should not be controlled by the attacker.

The core risk of Copy Fail can be summarized as:

the attacker does not need root privileges;
the attack entry point comes from common file-copy capabilities;
the affected logic runs in kernel space;
in container environments, the vulnerability may bypass namespace and mount isolation;
successful exploitation may write to host content that the container should not be able to modify.

That is why it has drawn attention. Container security depends on isolation provided by the Linux kernel. Once a kernel path itself allows unauthorized writes, the container boundary becomes fragile.

Why Container Scenarios Are More Sensitive

Containers are not virtual machines. Processes inside a container share the same Linux kernel with the host and are isolated through mechanisms such as namespaces, cgroups, capabilities, seccomp, and AppArmor/SELinux.

If a vulnerability exists in a user-space service, it usually affects only one container or one process. But if the vulnerability is in the kernel, especially one that can be triggered by an unprivileged user, an attacker may influence the host from inside a container.

That is where Copy Fail becomes dangerous. Many platforms allow users to submit build jobs, run scripts, start containers, or execute plugins. As long as an attacker can run code inside a container, they may try to use the kernel file-copy path to break isolation.

High-risk environments include:

untrusted workloads in Kubernetes clusters;
shared runners on CI/CD platforms;
sandbox platforms that allow users to upload and execute code;
multi-tenant Linux hosts;
containerized PaaS environments;
systems that run third-party plugins or extensions.

If these environments are running affected kernels and lack extra restrictions, the risk rises significantly.

Impact Depends on Kernel Patch Status

You cannot judge this kind of vulnerability only by distribution name. For the same Ubuntu, Debian, RHEL, Fedora, or Arch version, exposure depends on the kernel package that is actually running and whether the distribution has backported the fix.

During triage, prioritize three checks:

The currently running kernel version.
Whether the distribution security advisory mentions CVE-2026-31431.
Whether the cloud provider or managed platform has patched the host kernel.

You can first confirm the kernel version on the system:

`1`	`uname -a`

Then check distribution security advisories, kernel changelogs, or cloud platform notices. Do not judge safety only from the major version, because many enterprise distributions backport security fixes to older kernel branches.

Temporary Mitigation Ideas

The most reliable fix is still to update the kernel. But in environments where patches cannot be deployed immediately, you can reduce exposure first.

Common mitigation directions include:

disallow untrusted users from running privileged containers;
avoid mounting sensitive host paths into containers;
tighten container capabilities, especially avoiding unnecessary CAP_SYS_ADMIN;
use seccomp, AppArmor, or SELinux to restrict dangerous system calls and file access;
move untrusted workloads to stronger virtual-machine isolation;
destroy CI/CD runners per job instead of reusing the same host for a long time;
monitor abnormal file writes, permission changes, and signs of container escape.

These measures do not replace patches. Their role is to reduce exploitation success rate and impact, especially before patches reach production systems.

Patching Priority

Prioritize remediation by environment risk.

Patch first:

platforms that expose container execution to external users;
CI/CD nodes that run untrusted code;
multi-tenant Kubernetes nodes;
systems with user-defined plugins or script execution;
shared development machines, teaching machines, and lab platforms.

Relatively lower priority:

single-user desktops;
internal hosts that only run trusted services;
environments that already isolate untrusted code with virtual machines.

Even when risk is lower, it is still best to update the kernel through the distribution. Kernel vulnerabilities are often chained into more complex attacks, and delaying patches rarely provides much benefit.

Checklist for Operations Teams

You can process it in this order:

Inventory all Linux hosts and container nodes.
Mark machines that run untrusted code.
Check the current kernel version and distribution security advisories.
Update high-risk nodes first.
Apply temporary isolation policies to nodes that cannot be updated immediately.
Review container runtime configuration and remove unnecessary privileges and host mounts.
Reboot nodes after updating and confirm that the new kernel is actually running.
Keep change records for later audit.

Installing a kernel package does not mean the system is already running the new kernel. You must reboot after updating and confirm again:

`1`	`uname -a`

Summary

The key point of Copy Fail / CVE-2026-31431 is not that an application crashes, but that there is a permission-boundary issue in the Linux kernel file-copy path. It gives unprivileged code a chance to touch higher-privilege data-write paths, so it deserves special attention in container and multi-tenant environments.

When handling this type of vulnerability, the two most important actions are:

follow kernel patches from your distribution or cloud provider as soon as possible;
before patches are deployed, restrict untrusted code, privileged containers, and sensitive host mounts.

For personal desktops, it may not be an immediate panic issue. But for teams running container platforms, CI/CD, sandboxes, and shared hosts, it should be treated as a high-priority kernel security update.

References: