The Qualys Threat Research Unit (TRU) has discovered two linked local privilege escalation (LPE) flaws.
The first (CVE-2025-6018) resides in the PAM configuration of openSUSE Leap 15 and SUSE Linux Enterprise 15. Using this vulnerability, an unprivileged local attacker—for example, via SSH—can elevate to the “allow_active” user and invoke polkit actions normally reserved for a physically present user.
The second (CVE-2025-6019) affects libblockdev, is exploitable via the udisks daemon included by default on most Linux distributions, and allows an “allow_active” user to gain full root privileges. Although CVE-2025-6019 on its own requires existing allow_active context, chaining it with CVE-2025-6018 enables a purely unprivileged attacker to achieve full root access.
This libblockdev/udisks flaw is extremely significant. Although it nominally requires “allow_active” privileges, udisks ships by default on almost all Linux distributions, so nearly any system is vulnerable. Techniques to gain “allow_active”, including the PAM issue disclosed here, further negate that barrier. An attacker can chain these vulnerabilities for immediate root compromise with minimal effort. Given the ubiquity of udisks and the simplicity of the exploit, organizations must treat this as a critical, universal risk and deploy patches without delay.
The Qualys Threat Research Unit (TRU) has developed proof-of-concept exploits to validate these vulnerabilities on various operating systems, successfully targeting the libblockdev/udisks flaw on Ubuntu, Debian, Fedora, and openSUSE Leap 15.
Imagine a container zombie outbreak where a single infected container scans the internet for an exposed Docker API, and bites exploits it by creating new malicious containers and compromising the running ones, thus transforming them into new “zombies” that will mine for Dero currency and continue “biting” new victims. No command-and-control server is required for the delivery, just an exponentially growing number of victims that are automatically infecting new ones. That’s exactly what the new Dero mining campaign does.
During a recent compromise assessment project, we detected a number of running containers with malicious activities. Some of the containers were previously recognized, while others were not. After forensically analyzing the containers, we confirmed that a threat actor was able to gain initial access to a running containerized infrastructure by exploiting an insecurely published Docker API. This led to the running containers being compromised and new ones being created not only to hijack the victim’s resources for cryptocurrency mining but also to launch external attacks to propagate to other networks. The diagram below describes the attack vector:
The entire attack vector is automated via two malware implants: the previously unknown propagation malware nginx and the Dero crypto miner. Both samples are written in Golang and packed with UPX. Kaspersky products detect these malicious implants with the following verdicts:
nginx: Trojan.Linux.Agent.gen;
Dero crypto miner: RiskTool.Linux.Miner.gen.
nginx: the propagation malware
This malware is responsible for maintaining the persistence of the crypto miner and its further propagation to external systems. This implant is designed to minimize interaction with the operator and does not require a delivery C2 server. nginx ensures that the malware spreads as long as there are users insecurely publishing their Docker APIs on the internet.
The malware is named “nginx” to masquerade as the well-known legitimate nginx web server software in an attempt to evade detection by users and security tools. In this post, we’ll refer to this malware as “nginx”.
After unpacking the nginx malware, we parsed the metadata of the Go binary and were able to determine the location of the Go source code file at compilation time: “/root/shuju/docker2375/nginx.go”.
In this post I’ll show you how I found a zeroday vulnerability in the Linux kernel using OpenAI’s o3 model. I found the vulnerability with nothing more complicated than the o3 API – no scaffolding, no agentic frameworks, no tool use.
Recently I’ve been auditing ksmbd for vulnerabilities. ksmbd is “a linux kernel server which implements SMB3 protocol in kernel space for sharing files over network.“. I started this project specifically to take a break from LLM-related tool development but after the release of o3 I couldn’t resist using the bugs I had found in ksmbd as a quick benchmark of o3’s capabilities. In a future post I’ll discuss o3’s performance across all of those bugs, but here we’ll focus on how o3 found a zeroday vulnerability during my benchmarking. The vulnerability it found is CVE-2025-37899 (fix here), a use-after-free in the handler for the SMB ‘logoff’ command. Understanding the vulnerability requires reasoning about concurrent connections to the server, and how they may share various objects in specific circumstances. o3 was able to comprehend this and spot a location where a particular object that is not referenced counted is freed while still being accessible by another thread. As far as I’m aware, this is the first public discussion of a vulnerability of that nature being found by a LLM.
Before I get into the technical details, the main takeaway from this post is this: with o3 LLMs have made a leap forward in their ability to reason about code, and if you work in vulnerability research you should start paying close attention. If you’re an expert-level vulnerability researcher or exploit developer the machines aren’t about to replace you. In fact, it is quite the opposite: they are now at a stage where they can make you significantly more efficient and effective. If you have a problem that can be represented in fewer than 10k lines of code there is a reasonable chance o3 can either solve it, or help you solve it.
Benchmarking o3 using CVE-2025-37778
Lets first discuss CVE-2025-37778, a vulnerability that I found manually and which I was using as a benchmark for o3’s capabilities when it found the zeroday, CVE-2025-37899.
CVE-2025-37778 is a use-after-free vulnerability. The issue occurs during the Kerberos authentication path when handling a “session setup” request from a remote client. To save us referring to CVE numbers, I will refer to this vulnerability as the “kerberos authentication vulnerability“.
Screen is the traditional terminal multiplexer software used on Linux and Unix systems. We found a local root exploit in Screen 5.0.0 affecting Arch Linux and NetBSD, as well as a couple of other issues that partly also affect older Screen versions, which are still found in the majority of distributions.
In July 2024, the upstream Screen maintainer asked us if we could have a look at the current Screen code base. We treated this request with lower priority, since we already had a cursory look at Screen a few years earlier, without finding any problems. When we actually found time to look into it again, we were surprised to find a local root exploit in the Screen 5.0.0 major version update affecting distributions that ship it as setuid-root (Arch Linux and NetBSD). We also found a number of additional, less severe issues that partly also affect older Screen versions still found in the majority of distributions.
We offer two sets of patches for the issues described in this report, one for screen-4.9.1 and another for screen-5.0.0. These patch sets apply against the screen-4.9.1 and screen-5.0.0 release tarballs, respectively. Due to difficulties in the communication with upstream we do not currently have detailed information about bugfixes and releases published on their end.
The next section provides an overview of the Screen configurations and versions found on common Linux and UNIX distributions. Section 3) discusses each security issue we discovered in detail. Section 4) takes a look at possible further issues in Screen’s setuid-root implementation. Section 5) gives general recommendations for the improvement of Screen’s security posture. Section 6) points out problems we encountered during the coordinated disclosure process for these issues. Section 7) provides an affectedness matrix which gives a quick overview of the situation on various Linux and UNIX systems.
A new campaign employing ClickFix attacks has been spotted targeting both Windows and Linux systems using instructions that make infections on either operating system possible.
A new campaign employing ClickFix attacks has been spotted targeting both Windows and Linux systems using instructions that make infections on either operating system possible.
ClickFix is a social engineering tactic where fake verification systems or application errors are used to trick website visitors into running console commands that install malware.
These attacks have traditionally targeted Windows systems, prompting targets to execute PowerShell scripts from the Windows Run command, resulting in info-stealer malware infections and even ransomware.
However, a 2024 campaign using bogus Google Meet errors also targeted macOS users.
ClickFix targeting Linux users
A more recent campaign spotted by Hunt.io researchers last week is among the first to adapt this social engineering technique for Linux systems.
The attack, which is attributed to the Pakistan-linked threat group APT36 (aka "Transparent Tribe"), utilizes a website that impersonates India's Ministry of Defence with a link to an allegedly official press release.
CVE-2025-37752 is an Array-Out-Of-Bounds vulnerability in the Linux network packet scheduler, specifically in the SFQ queuing discipline. An invalid SFQ limit and a series of interactions between SFQ and the TBF Qdisc can lead to a 0x0000 being written approximately 256KB out of bounds at a misaligned offset. If properly exploited, this can enable privilege escalation.
A supply-chain attack targets Linux servers with disk-wiping malware hidden in Golang modules published on GitHub.
The campaign was detected last month and relied on three malicious Go modules that included “highly obfuscated code” for retrieving remote payloads and executing them.
Complete disk destruction
The attack appears designed specifically for Linux-based servers and developer environments, as the destructive payload - a Bash script named done.sh, runs a ‘dd’ command for the file-wiping activity.
Furthermore, the payload verifies that it runs in a Linux environment (runtime.GOOS == "linux") before trying to execute.
An analysis from supply-chain security company Socket shows that the command overwrites with zeroes every byte of data, leading to irreversible data loss and system failure.
The target is the primary storage volume, /dev/sda, that holds critical system data, user files, databases, and configurations.
“By populating the entire disk with zeros, the script completely destroys the file system structure, operating system, and all user data, rendering the system unbootable and unrecoverable” - Socket
The researchers discovered the attack in April and identified three Go modules on GitHub, that have since been removed from the platform:
github[.]com/truthfulpharm/prototransform
github[.]com/blankloggia/go-mcp
github[.]com/steelpoor/tlsproxy
OUTLAW is a persistent yet unsophisticated auto-propagating coinminer package observed across multiple versions over the past few years [1], [2], [3], [4]. Despite lacking stealth and advanced evasion techniques, it remains active and effective by leveraging simple but impactful tactics such as SSH brute-forcing, SSH key and cron-based persistence, and manually modified commodity miners and IRC channels. This persistence highlights how botnet operators can achieve widespread impact without relying on sophisticated techniques.
This advisory describes an out-of-bounds write vulnerability in the Linux kernel that achieves local privilege escalation on Ubuntu 22.04 for active user sessions.
Credit
An independent security researcher working with SSD Secure Disclosure.
Vendor Response
Ubuntu has released the following advisory and fix: https://ubuntu.com/security/CVE-2025-0927
A few months ago, I stumbled upon a 24 years old buffer overflow in the glibc, the base library for linux programs. Despite being reachable in multiple well-known libraries or executables, it proved rarely exploitable — while it didn't provide much leeway, it required hard-to-achieve preconditions. Looking for targets lead mainly to disappointment. On PHP however, the bug shone, and proved useful in exploiting its engine in two different ways.