Critical Linux kernel issue (CVE-2026-31431 / “Copy Fail”) — guidance for WebGee VPS & Dedicated customers

Audience: WebGee VPS and Dedicated server customers running Linux
Purpose: Explain the risk, point to authoritative references, and show how to check and mitigate using WebGee’s helper script or standard Linux steps.

Summary

A serious Linux kernel vulnerability, publicised as Copy Fail and tracked as CVE-2026-31431, can allow a local, unprivileged user to escalate privileges to root on affected systems. That means a compromise of any unprivileged account (or code running as a non-root user—such as through a vulnerable website or CMS) could potentially be chained into full control of the server.

You should treat this as urgent: plan a kernel update from your distribution as soon as a fixed package is available for your release, then reboot into the new kernel. Until then, a short-term mitigation recommended by the community is to block the algif_aead kernel module from loading.

WebGee provides a small script that detects whether your running kernel appears patched or exposed, whether the module is present or loaded, and optionally applies the modprobe-based mitigation.

What WebGee recommends

1. Permanent fix: When your distribution publishes an updated kernel that addresses CVE-2026-31431, install it and reboot so the running kernel is the fixed one:

   • Example on Debian/Ubuntu-style systems: apt update && apt upgrade -y (then reboot when a new kernel is installed).

2. Short-term mitigation: Until you are on a fixed kernel, apply the community modprobe workaround (block algif_aead and unload it if safe). This is what WebGee’s script can automate.

3. Verify: After any change, re-run the check script (or your distro’s security tooling) so you know whether the running system still looks exposed.

Check your server with WebGee’s script (one command)

The script must run as root on the server (full administrative access to read kernel state and write /etc/modprobe.d/ if you mitigate).

If you are already logged in as root (common on many VPS setups), you can use:

curl -fsSL 'https://security.webgee.com/scripts/copyfail-check.sh' | bash

If you use a normal user with sudo:

curl -fsSL 'https://security.webgee.com/scripts/copyfail-check.sh' | sudo bash

What the flags mean: -f fails on HTTP errors, -sS is quiet but still shows errors, -L follows redirects—together this is a standard pattern for “fetch a script and run it.” Only use URLs you trust; this one is served by WebGee under our security subdomain.

The script prints a coloured report: whether it could confirm a patch, whether algif_aead exists and is loaded, whether a block is already in place, and a short verdict. If it believes the system is affected, it exits with a non-zero status unless you have already mitigated or it believes you are not exploitable.

Apply the mitigation with the same script

To apply the workaround automatically (writes /etc/modprobe.d/disable-algif-aead.conf and attempts to unload the module):

As root:

curl -fsSL 'https://security.webgee.com/scripts/copyfail-check.sh' | bash -s -- --mitigate

With sudo:

curl -fsSL 'https://security.webgee.com/scripts/copyfail-check.sh' | sudo bash -s -- --mitigate

Trade-off: Blocking algif_aead can affect rare setups that rely on AF_ALG through that path (for example, custom OpenSSL afalg engine use). Most typical web, mail, and database stacks do not require it; the script may warn if your OpenSSL configuration references afalg.

Manual mitigation (equivalent to what the script does)

If you prefer to apply the steps yourself:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

(Your distribution or WebGee’s script may use a slightly different filename under /etc/modprobe.d/; multiple drop-in files are normal.)

Then reboot is not required for this workaround to take effect for new module loads; rmmod clears an already-loaded instance when the kernel allows it.

After the kernel is properly patched

Once you have booted a fixed kernel from your vendor, the vulnerability is addressed in the proper way. You may keep or remove the modprobe drop-in file according to your internal policy; removing it restores the ability to load algif_aead if you ever needed it (uncommon on typical hosting stacks).

Limitations and honesty about detection

No single userspace script can mathematically prove the running kernel is safe on every distro: vendors backport fixes with their own changelog text, and live patching can fix memory without changing the on-disk vmlinuz package name you expect. WebGee’s script uses several heuristics (package changelogs, livepatch hints, and some distro security tools when present) and clearly labels uncertainty when it cannot confirm a fix.

Bottom line: Use the script for a practical on-host assessment and quick mitigation; treat distribution updates and reboot as the real resolution, and follow the references above for broader context.

References (also linked from the article):

https://copy.fail

https://nvd.nist.gov/vuln/detail/CVE-2026-31431

Support

If you are a WebGee VPS or Dedicated customer and are unsure about reboot windows, kernel packages, or compatibility with your workloads, open a ticket with our team and include the full text output of the check script (no need to send us your root password).

This notice is provided as a courtesy to help you harden your server. It is not a substitute for your own security monitoring, backups, and vendor advisories.