A new kernel exploit (CVE-2026-46331) gets root without modifying a single file on disk. It poisons the cached copy of /bin/su in memory. The binary on disk stays untouched. File-integrity checks come back clean. The root shell is already open. Details here ↓
1 Like
Again this is a local exploit which means allowing a stranger to have access to your PC:
" No , a local breach of root access in the Linux kernel cannot be carried out remotely in isolation.
-
Vulnerabilities such as CVE-2026-31431 ("Copy Fail") and CVE-2026-23111 are strictly local (AV:L), requiring the attacker to first establish a foothold on the system.
-
An attacker must already possess low privileges with no user interaction, typically via SSH access , a compromised container , or a service account .
-
Once local access is gained, the attacker can exploit these kernel flaws to escalate privileges to root (UID 0), bypassing user-space protections and gaining complete system control.
AI-generated answer. Please verify critical facts."
Another reason why I never use SSH or remote SSH.
2 Likes
Local-only is still worth patching, especially on machines that run containers or any service with a low-privilege account. Disabling unused SSH is good hygiene, but I’d still keep an eye on the kernel updates and reboot after installing them.
For a Zorin box the boring check is usually just uname -r plus the normal Software Updater/apt updates; file integrity tools are not the useful detector for this one.
I’d be careful with the CVE numbers in summaries like this, especially if part of the text came from an AI answer. The practical advice is still boring: apply kernel updates from the normal Zorin/Ubuntu repos and reboot into the new kernel. Local-only does not only mean “someone at the keyboard”; a browser exploit, bad app, container escape path, or exposed service can become the low-privilege foothold first. So disabling unused SSH is good, but it is not the whole mitigation.
Here is a good example via Mojeek's LLM:
" A browser exploit can potentially lead to a compromised Linux system, though the success and extent of the compromise depend on several factors, including the exploit's sophistication, the system's security posture, and the privileges of the exploited process. Modern Linux systems incorporate multiple security mechanisms—such as Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), and sandboxing—that are designed to mitigate the impact of such exploits 8. However, these defenses are not infallible, and advanced exploitation techniques, such as Return-Oriented Programming (ROP), can bypass them under certain conditions 8. Historical examples demonstrate that browser vulnerabilities have been exploited to achieve remote code execution. For instance, vulnerabilities in Google Chrome have been documented where successful exploitation allowed attackers to inject and execute arbitrary code on the target system with the security privileges of the browser process 6. Similarly, other reports highlight that certain vulnerabilities could lead to crashes or arbitrary code execution, which, under specific circumstances, could escalate to system compromise 5. The feasibility of a full system compromise from a browser exploit also depends on the user's privileges. If the exploited process runs with elevated privileges (e.g., as root), the potential for deeper system compromise increases significantly 8. Additionally, post-exploitation steps, such as lateral movement or privilege escalation, may be required to fully compromise the system, depending on the initial access gained 1. In summary, while browser exploits can serve as an entry point for compromising a Linux system, the likelihood and severity of the compromise are influenced by the system's defenses and the exploit's capabilities. Keeping systems updated and adhering to security best practices are critical to reducing such risks.
Summaries are experimental and generated by large language models. Please double check for accuracy. Learn more."
This is why a good distribution forces you to create a separate password for root.
In Zorin's case it is best if you setup a separate Admin account and then set yourself up as a Standard User.