Skip to main content

Root of the Problem: Linux Flaws That Give Attackers Admin Rights

 I realised that I haven’t posted to my blog in a long time and this week an article about CVE’s in linux caught my eye and that was the perfect excuse to write another blog post.

Cybersecurity researchers at Qualys have uncovered two critical local privilege escalation (LPE) flaws that are shaking the foundations of Linux security. These aren't your run-of-the-mill vulnerabilities; we're talking about direct, express lanes to full root access on major Linux distributions.

If you use Ubuntu, Debian, Fedora, openSUSE Leap 15, or SUSE Linux Enterprise 15, you need to pay close attention.

The Double Threat: CVE-2025-6018 & CVE-2025-6019

An article detailing the CVE’s can be found at the link below

(CVE-2025-6018 and CVE-2025-6019 Vulnerability Exploitation: Chaining Local Privilege Escalation Flaws Lets Attackers Gain Root Access on Most Linux Distributions | SOC Prime)    

Qualys has pulled back the curtain on two distinct, yet chainable, vulnerabilities:

  •  CVE-2025-6018: Found in the Pluggable Authentication Modules (PAM) configuration of openSUSE Leap 15 and SUSE Linux Enterprise 15. This flaw allows an unprivileged local attacker to elevate their status to the "allow_active" user. Why is "allow_active" a big deal? Because it grants permission to call Polkit actions normally reserved for a physically present user. Think of it as getting a key to the next, more privileged, room.
  •  CVE-2025-6019: This one affects libblockdev and is exploitable through the udisks daemon, which is practically ubiquitous across Linux distributions. This is the big one. Once an attacker has "allow_active" privileges (which they can get via CVE-2025-6018), this vulnerability allows them to vault straight to full root privileges.

As Saeed Abbasi, Senior Manager at Qualys Threat Research Unit (TRU), puts it, these "modern 'local-to-root' exploits have collapsed the gap between an ordinary logged-in user and a full system takeover." In essence, an attacker who gains any active GUI or SSH session can become root in mere seconds.

The Danger: Full System Compromise

The implications of these flaws are severe. Once an attacker obtains root privileges, they have absolute control over your system. This means:

·       Altering security controls: Disabling firewalls, modifying access policies.

·       Implanting backdoors: Creating hidden access points for future covert operations.

·       Using your system as a springboard: Launching further attacks on other systems or networks.

·       Data theft and manipulation: Accessing, exfiltrating, or corrupting sensitive information.

Qualys has even developed proof-of-concept (PoC) exploits, confirming the active threat on various popular distributions. This isn't theoretical; it's a present danger.

Another Flaw to Watch: CVE-2025-6020 in Linux PAM

As if that weren't enough, maintainers of Linux PAM have also recently patched a high-severity path traversal flaw, CVE-2025-6020 (CVSS score: 7.8). This vulnerability, fixed in PAM version 1.7.1, could also allow a local user to escalate to root privileges if pam_namespace is used with user-controlled paths.

What You Need to Do NOW!

The message is clear: patch your systems immediately.

  •  Apply Vendor Patches: This is your absolute top priority. Linux distribution vendors will be releasing patches to address these vulnerabilities. Check your distribution's official security advisories and apply updates as soon as they are available.
  •  Temporary Workarounds (for CVE-2025-6018 & CVE-2025-6019): If you cannot patch immediately, you can modify the Polkit rule for "org.freedesktop.udisks2.modify-device" to require administrator authentication ("auth_admin"). This adds an extra layer of protection, but is not a permanent fix.

Workarounds for CVE-2025-6020:

  • Disable pam_namespace.
  •    Ensure pam_namespace does not operate on user-controlled paths.
  • Update your namespace.init script if you're not using your distribution's default.

Stay Informed, Stay Secure

These recent disclosures underscore the constant vigilance required in cybersecurity. Don't wait until you're "pwned" to get informed. Regularly update your systems, follow security best practices, and stay abreast of the latest vulnerability disclosures. Your digital security depends on it.

There will be a follow up to this blog post and more on my home lab in the near future, I now have a managed switch and another mini PC to add to my network the plan is to put active directory on the new pc and use the switch for things like VLANS and understanding QoS.

Comments

Popular posts from this blog

From OVA to Rocky: My Wazuh Upgrade Story

  In this blog post I will be covering something I’ve covered in a previous blog post, but I’ve decided to change my home lab and put my Wazuh SIEM on a standalone rocky linux, there are several reasons I chose to do this, Performance & Scalability: The OVA VM is a pre-built virtual machine that may not be optimized for high availability or scalability. A dedicated instance on Rocky Linux allows for better resource allocation and tuning. Customization & Flexibility: The OVA VM comes with predefined configurations. Running Wazuh on Rocky Linux gives you full control over system settings, security policies, and software updates. Compatibility & Stability: Rocky Linux is a stable, enterprise-grade OS, and Wazuh has been tested for compatibility with newer versions like Rocky Linux 9.3. This ensures long-term support and reliability. Security & Isolation: A dedicated instance provides better security isolation compared to a shared virtualized environment. You can impl...

Up the Wazuh: A SIEM-ple Adventure in Troubleshooting

Initial setup To start  I downloaded the .osa file from the  wazuh website ( https://wazuh.com ) and then installed it in my virtualbox hypervisor. Then I booted up my fedora linux VM and the wazuh VM with the dashboard and manager on.  After I had logged in to the wazuh VM with the default credentials I used the ip a command to find out the ip address of the wazuh VM. As from reading the documentation I’d need this later. In my fedora VM I opened a terminal and used the commands on the wazuh website to install the agent on the VM. After some time the installation was completed and I had to update the. conf file with the IP address of the wazuh manager. This is important because  the file is a generic file that needs to be modified to make it specific to each individual setup.  All was going well up to this point. I tried to get the fedora VM to talk to the wazuh VM. The problems I encountered It was here the problems started when I tried to pi...