CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog on September 18, 2026, with a federal remediation deadline of September 21. The flaws are CVE-2025-39682, a memory exposure bug in the TLS receive path, CVE-2026-53266, an out-of-bounds write in the ebtables network filter, and CVE-2025-39964, a race condition in the AF_ALG crypto socket interface. All three are local privilege escalation flaws, which means an attacker needs a foothold on the server first and then uses the bug to become administrator. On the same day, a researcher released public exploits for four other kernel flaws. For a company running Linux servers, the message is to patch and reboot, and to treat any account that can run code on those servers as part of the attack surface.
Why a Local Flaw Still Matters to Your Business
A local privilege escalation flaw does not let a stranger break in from the internet by itself. It lets someone who already has a small foothold, such as a stolen web application account, a compromised developer login or a malicious script, become the all-powerful root user. That is the step that turns a minor intrusion into a full takeover.
CISA lists a flaw as exploited only when it has evidence of real attacks, so these three are not theoretical. Attackers chain them behind an initial entry that was easier to get, which is why patching them matters even on servers that are not directly exposed.
Here is the short version for business leaders:
- Three kernel flaws were confirmed exploited and added to the CISA catalog on September 18, 2026.
- Each lets a local attacker raise privileges, so the real risk begins after any other foothold.
- Four additional kernel flaws got public exploit code the same day, though no real attacks were reported for them at the time.
- Kernel fixes are in named upstream releases, but distributions number their own versions, so you need your vendor’s advisory rather than the upstream number.
- Patch and reboot is the recommended fix, and disabling features is a backup measure.
This article is for the owner, operations director or IT manager at a company that runs Linux for websites, file services, databases, firewalls or appliances, often without a dedicated Linux administrator. We are the guide and you are the one keeping the business running, so we keep the steps plain.
What the Three Flaws Are
CVE-2025-39682 sits in the code that receives encrypted TLS traffic and can expose sensitive memory, with a network score of 9.8 and a local score of 7.1. CVE-2026-53266 is an out-of-bounds write in an Ethernet bridging filter component, scored 8.8, which can lead to crashes or privilege escalation. CVE-2025-39964 is a race condition in a crypto socket interface, scored 7.8.
You do not need to memorize the names. What matters is that all three live in the networking and crypto parts of the kernel, they are in active use by attackers and fixed kernels exist.
Why the Four Public Exploits Raise the Stakes
On the same day, a researcher published working exploit code for four other local privilege escalation flaws, with bugs between 10 and 21 years old. Three of them need unprivileged user namespaces, a feature many distributions enable by default. Public code lowers the skill needed to attack, so a flaw with no reported attacks today can become routine next month.
Why a Backup Plan Belongs in the Patch Conversation
A kernel update can fail, and a compromised server may need rebuilding, so recovery planning travels with patching. Our business continuity and disaster recovery services explain how we protect the systems you cannot afford to lose, and our guide on how managed IT services reduce downtime shows why scheduled maintenance beats emergency repair.
Why Some Teams Delay Kernel Patches
Kernel updates need a reboot, and a reboot means downtime on a server people depend on. That is a real cost, and it explains why kernel patches slip. The counter-argument is that a planned reboot at night costs minutes while a root-level compromise costs days. Schedule the reboot and tell people in advance.
How to Find Out Whether Your Servers Are Affected
Start with an inventory of Linux systems and their kernel versions, because many companies run more Linux than they realize. Web hosting, backup appliances, firewalls, network storage, security cameras and virtual appliances often run Linux inside.
List Every Linux System
Check your server list, your cloud accounts and any appliance that a vendor installed. For each, run the command that prints the kernel version, or ask your provider to send the list. Include test servers and old systems, since attackers find forgotten machines first.
Compare Against Your Vendor’s Advisory
Upstream fixes landed in kernels including 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Distributions such as Ubuntu, Red Hat and Debian number their own packages and often backport fixes without changing the upstream number. Look up each flaw in your distribution’s security tracker and confirm the package version that contains the fix.
Check Whether You Run Unsupported Systems
If a server runs a kernel or distribution that no longer receives updates, no patch is coming. For those systems the plan is to upgrade or retire, and in the meantime to restrict who can log in and run code. An unsupported server on the network is a standing risk.
What About Appliances You Cannot Patch Yourself
Vendor appliances get kernel fixes through the vendor’s firmware updates, on the vendor’s schedule. Ask the vendor in writing when a fix ships and whether the appliance is affected. Keep the appliance off the internet and limit who can log in until the update arrives.
How to Patch Linux Servers Without Surprises
A calm patch process has five parts: test, back up, patch, reboot and verify. It works the same for one server or fifty, and writing it down once makes every later advisory easier.
Test First on a Copy
Apply the update to a test server or a snapshot that mirrors production. Confirm that your application starts, your services answer and your monitoring still works. A kernel update rarely breaks applications, but a few minutes of testing is cheaper than finding out during a customer’s busy hour.
Back Up and Pick a Window
Take a verified backup or snapshot before you start, and choose a low-traffic window. Tell the people who depend on the server when it will restart and for how long. Keep the previous kernel installed so you can boot back into it if something misbehaves.
Patch, Reboot and Verify
Install the updated kernel package, reboot and then confirm the running kernel version matches the fixed one. Many teams patch and forget to reboot, which leaves the old kernel running and the flaw open. Checking the running version is the step that proves the fix is live.
Use Live Patching Where It Fits
Some distributions offer live kernel patching that applies certain fixes without a reboot. It can help on servers where downtime is hard to schedule, but it does not cover every flaw and does not replace a regular reboot. Ask your vendor which of these three it covers.
How to Reduce the Damage While You Patch
If you cannot patch today, narrow the paths an attacker could use. These measures buy time and do not replace the update.
Limit Who Can Run Code on the Server
Local flaws need a local foothold, so tighten the foothold. Remove unused accounts, require multi-factor authentication for administrators and review which web applications and scheduled jobs run with access to the server. Every account that can run commands is a possible starting point.
Turn Off Features You Do Not Use
Researchers advise disabling unprivileged user namespaces, which mitigates three of the four newly published exploits, and disabling unused networking modules such as AH6, TUN and TAP, PPPoE and SCTP. Test the change first, because containers and some applications depend on user namespaces. Treat this as a stopgap until the patch is installed.
Watch for Signs of Escalation
Look for unexpected new administrator accounts, changes to system files, unusual scheduled jobs and logins at odd hours on systems that normally see none. Forward server logs to a central place so an attacker cannot erase them from the machine they are on. A quiet log from a server that was never monitored proves little.
Add Zero Trust Habits Where You Can
Limiting what each account can reach shrinks the damage from any foothold. Our guide to zero trust security for small business in five steps gives an affordable order of work, and our overview of small business managed IT services shows what ongoing maintenance looks like when someone else carries it.
Make It a Habit
Add kernel updates to a monthly maintenance cycle with a faster path for advisories like this one. A company that patches monthly is rarely caught by a single bulletin, and a company that patches only after incidents is caught by most of them.
How to Build a Kernel Patch Routine That Lasts
A repeatable routine matters more than any one advisory, because kernel flaws arrive several times a year and each one tests how organized your maintenance is. Aim for a process that a new team member could follow from a one-page checklist.
Group Servers by Risk and Impact
Sort servers into three groups: internet-facing systems, internal systems that hold sensitive data and everything else. Patch the first group first and fastest, since it is closest to the outside, and keep a standing window for each group. A written grouping settles arguments about order in the middle of an advisory.
Track Versions in One Place
Keep a simple list with the server name, distribution, running kernel, last patch date and owner. When a bulletin arrives, you can answer which servers are affected in minutes instead of days. Many companies discover during an incident that nobody knows how many Linux systems they run.
Verify, Do Not Assume
After each patch cycle, confirm that the running kernel matches the expected version on every server, and report any that do not. Servers that skipped the reboot or failed the update quietly stay vulnerable, and they are the ones attackers find. A short automated check that compares versions pays for itself the first time it flags a miss.
Pair Patching With Access Hygiene
Because these flaws need a foothold, review who has accounts on each server and what each web application or job can run. Remove stale accounts, require multi-factor authentication for administrators and keep application accounts to the permissions they need. Good access habits make a local flaw harder to use even before the patch lands.
Frequently Asked Questions
Do I need to worry if my servers are not on the internet?
Yes, though your urgency is lower. These flaws raise privileges for someone already on the system, and an attacker can get on through a phished account, a vulnerable application or an insider. Patch internal servers on your normal fast track.
What does CISA’s remediation deadline mean for a private company?
The September 21 deadline applies to federal agencies under CISA’s directive. Private companies are not bound by it, but many use it as a planning benchmark because it reflects real attacks.
Is a reboot really required?
For most kernel fixes, yes. The new kernel only runs after a restart, so verify the running version after patching. Live patching can cover some flaws without a reboot, but not all.
My distribution shows a different version number. Am I protected?
Possibly. Distributions often backport fixes without matching the upstream number, so check your vendor security tracker for each flaw and the fixed package version.
Who can help us check our Linux systems?
Our team can inventory your servers and plan the patch window with you during a free strategy call.
Who Stands Behind This Guidance
Mindcore Technologies manages servers, networks and security for small and mid-sized businesses, including the patching and monitoring that keep Linux systems safe, and we write from that daily work. Matt Rosenthal, our CEO, keeps the company focused on dependable maintenance and plain communication when something urgent comes up. We share what we see so you can act with confidence.
Patch, Reboot and Confirm
The takeaway is that confirmed exploitation turns a routine kernel update into a priority. List your Linux systems, check your vendor’s advisory, patch with a backup in hand and confirm the running kernel after the reboot. Tighten who can run code on the server while you work, and build kernel updates into your monthly cycle. Book a free strategy call and we will help you plan it.
