Linux Kernel Vulnerabilities: Proactive Breach Detection

Copy Fail and DirtyFrag: Linux Page Cache Bugs & Broader Cybersecurity Threats in 2026

Recent disclosures show a dynamic cybersecurity field, marked by intricate kernel-level exploits and complex supply chain compromises. Among these, the Copy Fail and DirtyFrag vulnerabilities in the Linux kernel are a reminder of underlying system risks, while campaigns like "Mini Shai-Hulud" and the Hugging Face infostealer show the persistent threat to software development environments. These incidents, with a recent ransomware attack targeting the Australian mining sector, collectively show diverse and impactful threats.

Understanding these varied attack vectors is important for cybersecurity professionals and business leaders responsible for digital infrastructure. PurpleOps provides real-time cyber threat intelligence platform capabilities to handle complex and rapidly changing threat environments. This analysis dissects the technical aspects of these recent events, offering insights into their mechanisms, detection, and mitigation strategies.

Kernel Privilege Escalations: Copy Fail and DirtyFrag

What are Copy Fail and DirtyFrag, and how do they exploit Linux systems?

Copy Fail (CVE-2026-31431) and DirtyFrag are Linux kernel privilege escalation vulnerabilities that exploit subtle page cache corruption bugs, creating paths to root access. These issues are concerning because they use legitimate kernel interfaces and local execution.

Copy Fail is a logic bug identified within the Linux kernel's authencesn cryptographic template. The vulnerability chains AF_ALG (Algorithm-level socket) and splice() system calls to achieve a controlled 4-byte write into the page cache of any readable file. This corrupts the in-memory view of a setuid binary, such as /usr/bin/su, allowing privilege escalation without altering the file on disk. The exploit code is concise, functioning across various Linux distributions.

DirtyFrag extends this bug class into the networking stack. It presents two page-cache write variants. The ESP path uses XFRM security associations via AF_NETLINK to perform in-place crypto operations on spliced pages, overwriting critical files like /usr/bin/su with a minimal root-shell ELF. The RxRPC fallback path employs AF_RXRPC with pcbc(fcrypt) to corrupt /etc/passwd, specifically clearing the root's password field. Both DirtyFrag paths require unshare(CLONE_NEWUSER | CLONE_NEWNET) to gain namespace capabilities before triggering the page-cache write. A distinction is that DirtyFrag does not depend on the algif_aead module, meaning systems that applied only the Copy Fail mitigation may still be exposed.

How can Copy Fail and DirtyFrag be detected?

Detection efforts for Copy Fail and DirtyFrag focus on identifying underlying syscall primitives and behavioral patterns, instead of relying solely on signatures of specific exploit implementations. This approach addresses the existence of multiple public reimplementations.

Syscall-Level Primitives (Auditd)

Both Copy Fail and DirtyFrag rely on socket(AF_ALG) to access the kernel crypto subsystem and splice() to inject read-only file pages into network buffers, where in-place cryptographic operations corrupt the page cache. DirtyFrag also uses socket(AF_RXRPC) as a fallback. These primitives are visible through auditd syscall auditing, particularly socket calls with a0 hex values of 26 (for AF_ALG) or 21 (for AF_RXRPC), and splice calls originating from non-root processes. These serve as early-stage signals, correlated via EQL sequences with the final privilege escalation step of a non-root caller gaining effective UID 0.

Example Auditd rules for increased visibility:

-a always,exit -F arch=b64 -S socket -k socket_syscall
-a always,exit -F arch=b32 -S socketcall -k socket_syscall
-a always,exit -F arch=b64 -S splice -k splice-syscall
-a always,exit -F arch=b32 -S splice -k splice-syscall
-a always,exit -F arch=b64 -S bind -k socket_bound
-a always,exit -F arch=b32 -S bind -k socket_bound

Namespace Creation (DirtyFrag-Specific)

DirtyFrag's exploit chain relies on unshare(CLONE_NEWUSER | CLONE_NEWNET) to gain namespace capabilities. Monitoring this event, correlated with a root process execution or a setuid(0) syscall shortly afterward, can indicate DirtyFrag exploitation.

Generic SUID Binary Abuse (Process Exec Events)

A common final step for both exploits involves corrupting or influencing the in-memory execution of a SUID binary such as su, sudo, pkexec, passwd, chsh, or newgrp, making it execute attacker-controlled code as root. Detection logic identifies suspicious executions where the process runs as effective UID 0, the real user is non-root, the parent process is also non-root, the SUID binary is launched with minimal arguments, and the parent process is a scripting runtime, shell one-liner, or executable from a user-writable path.

Proactive Threat Hunting with ES|QL

Both Copy Fail and DirtyFrag produce a distinct burst of interleaved socket(AF_ALG) and splice() syscalls from the same process. Copy Fail iterates 48 times to write 192 bytes, and DirtyFrag follows a similar pattern. ES|QL queries can aggregate these syscalls by process and surface any non-root process combining AF_ALG or AF_RXRPC sockets with splice calls at volume. PurpleOps' breach detection capabilities use such behavioral analytics to identify anomalous activity, which indicates compromise.

What are the mitigation strategies for Copy Fail and DirtyFrag?

Patching and system hardening are important to address these kernel vulnerabilities. The primary remediation for both Copy Fail and DirtyFrag is to update the Linux kernel once distribution patches are available.

Targeted Module Blocking

Where immediate patching is not possible, targeted module blocking can reduce the attack surface.

• For Copy Fail, disabling the algif_aead module prevents the AF_ALG AEAD path used by the exploit.

    echo "install algif_aead /bin/false" > /etc/modprobe.d/copyfail.conf
rmmod algif_aead 2>/dev/null

• For DirtyFrag, disabling the affected networking modules blocks both the ESP and RxRPC exploit paths.

    printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null

These mitigations should be tested in a staging environment prior to production deployment, as disabling kernel modules may impact IPsec VPNs, crypto applications, or other services.

Dropping the Page Cache

After applying module mitigations, dropping the page cache ensures any previously corrupted in-memory pages are discarded. This can be done with echo 3 > /proc/sys/vm/drop_caches. This action causes a brief I/O spike and should be avoided during peak load.

Restrict Unprivileged User Namespace Creation

Restricting unprivileged user namespace creation hardens against DirtyFrag and similar exploits. This can be achieved with sysctl -w kernel.unprivileged_userns_clone=0. On RHEL/Fedora, user.max_user_namespaces=0 is the equivalent setting. Evaluate compatibility before applying, as this may affect applications relying on unprivileged namespaces, such as certain container runtimes and browser sandboxes.

Cross-Ecosystem Supply Chain Attacks: The "Mini Shai-Hulud" Campaign

The "Mini Shai-Hulud" campaign is another dangerous class of cyber threat, focusing on the software supply chain. This complex cross-ecosystem attack compromised widely used packages across Python, Node.js, PHP, and Composer environments. This shows the importance of supply-chain risk monitoring.

What attack vectors did "Mini Shai-Hulud" exploit?

The "Mini Shai-Hulud" campaign used compromised maintainer credentials and CI/CD tokens to inject malicious updates into legitimate packages. This let attackers release trojanized versions under trusted package names, and bypass traditional vulnerability exploitation.

The root cause of the incident stemmed from several systemic weaknesses:

• Compromised Maintainer Credentials: Attackers gained access to legitimate publisher accounts, enabling the release of malicious versions without immediate suspicion.
• Abuse of CI/CD Tokens: Automated pipelines were exploited using stolen or misconfigured tokens (e.g., GitHub Actions OIDC), and turned trusted automation into a malware delivery mechanism.
• Insufficient Package Publishing Controls: A lack of strict safeguards, such as multi-party approval or release gating, allowed malicious updates to be rapidly distributed.
• Lack of Release Integrity Verification: Consumers did not enforce strong verification mechanisms like signed artifacts or provenance validation.

The campaign compromised components in the Python (PyPI), Node.js (npm), and PHP (Composer) ecosystems:

• PyPI (Python Ecosystem): The Lightning (PyTorch Lightning) package, versions 2.6.2 and 2.6.3, contained malicious code embedded directly into the distributed wheel files. This payload executed automatically upon package import. The last known safe version is 2.6.1.
• npm (Node.js Ecosystem): The intercom-client package, version 7.0.4 (released April 30, 2026), included a malicious preinstall hook that allowed attacker-controlled code execution during installation. This compromise originated from a stolen GitHub Actions token. Users should downgrade to 7.0.3.
• Composer (PHP Ecosystem): The intercom-php package, version 5.0.2, was compromised via a malicious Git tag on April 30, 2026. Systems that pulled the package during that window might be affected; downgrading to 5.0.1 or clearing dependency caches is advised.

This attack demonstrated worm-like behavior, scanning local npm caches for valid authentication tokens and attempting to automatically publish compromised versions of other packages if found. This spread laterally across developer environments and ecosystems, as discussed in prior analyses of npm worm attacks and credential theft. More information on such threats can be found in our deep dives on Shai Hulud npm Worm attacks and Crowdstrike's npm worm attack.

How did the "Mini Shai-Hulud" payload operate?

The "Mini Shai-Hulud" payload executed as a multi-stage operation. It was designed for stealth, broad credential harvesting, and propagation across diverse environments.

Code-Level Analysis

1. Import-Time Execution (Python Entry Point): The attack initiated by abusing Python's import mechanism. The malicious logic, found in a function like _run_runtime, dynamically resolved the package installation path and launched a hidden start.py script using subprocess.Popen. This process ran in the background as a daemon thread with stdout and stderr redirected to DEVNULL. This ensured invisibility.
2. Runtime Bootstrapper (Bun Loader Logic): After initial execution, the malware prepared a consistent runtime environment. It checked for a local or system-installed Bun runtime, downloading it from GitHub if unavailable. Executing its ENTRY_SCRIPT (e.g., router_runtime.js) via Bun decoupled the payload from the host language, letting it run across Python, Node, and PHP ecosystems. The use of Bun, often less monitored than Node.js or Python, aided in evasion.
3. Payload Orchestration (Central Control Logic): The malware activated its central control logic using Promise.all to coordinate parallel data collection routines such as collectFilesystemSecrets(), collectShellAndEnv(), and collectGitHubRunnerSecrets(). This parallel execution minimized its detection window.
4. Credential Harvesting (Local + Cloud + CI): This stage was the primary objective, collecting sensitive data from various sources.

• Local Environment: It executed CLI commands (e.g., gh auth token) and dumped all environment variables (process.env), capturing API keys, database credentials, access tokens, and session data.
• File-Based Secret Discovery: The payload scanned common "hotspot" locations like .env, ~/.aws/credentials, ~/.npmrc, and ~/.ssh/id_rsa for cloud credentials, SSH keys, and package registry tokens.
• Cloud Credential Access: It queried cloud-related sources, including AWS Instance Metadata Service (IMDS), Azure CLI token cache, GCP Application Default Credentials (ADC), and other cloud provider-specific token caches.
• CI/CD Environment Targeting: The malware detected execution inside CI/CD pipelines (e.g., via process.env.GITHUB_ACTIONS) and extracted secrets directly from runtime memory, bypassing file-based and masking protections. These often high-privilege CI/CD tokens are important targets for credential intelligence.

1. Encrypted Exfiltration (Stealth Communication): Collected data was compressed using gzip. It was then symmetrically encrypted with AES-256. The AES key was encrypted using RSA with a public key, which ensured strong confidentiality. The final encrypted payload was sent over HTTPS to It blended with legitimate web traffic.
2. GitHub as Covert Channel: In addition to traditional C2, the malware abused GitHub for data exfiltration and token retrieval. It searched GitHub commit history for encoded markers like EveryBoiWeBuildIsAWormyBoi to extract attacker-controlled credentials. It also created new public repositories, and uploaded stolen data as structured JSON files, often with descriptions like "A Mini Shai-Hulud has Appeared".
3. Supply Chain Propagation (npm Infection): The attack evolved into a self-propagating threat by modifying package contents. It injected a malicious preinstall script (e.g., node setup.mjs) into package.json. It incremented the patch version to appear as a legitimate update, repackaged the modified tarball, and uploaded it to the registry. It used GitHub Actions OIDC to exchange identities for npm publishing credentials, allowing unauthorized publication without direct password theft. This worm-like propagation spread the infection, as detailed in our analysis of Shai Hulud npm worm.
4. Repository Infection & Persistence: For long-term persistence, the malware modified source code repositories. It injected or overwrote files in .vscode/, .claude/, .github/workflows/, and other configuration directories, and embedded hidden execution paths. It copied core payload files. This ensured that any developer cloning the repository would inherit the malware. These changes were committed under benign messages, such as "chore: update dependencies", to avoid suspicion during code reviews.

Security monitoring systems (SIEM/EDR/IDS) should flag the presence of router_runtime.js or start.py inside Python wheels or node_modules, unexpected process execution (like Bun during package installation), suspicious GitHub activity, and anomalies in build integrity. PurpleOps' dark web monitoring service and underground forum intelligence help identify similar threat indicators and campaign chatter.

A malicious repository on Hugging Face, named Open-OSS/privacy-filter, briefly reached the platform's trending list by impersonating OpenAI's legitimate "Privacy Filter" project. This repository delivered information-stealing malware to Windows users through a multi-stage process involving typosquatting and a complex loader.

• Initial Compromise: The malicious repository cloned the model card of OpenAI's legitimate project, but shipped a loader.py Python script.
• Payload Delivery: The loader.py script included fake AI-related code to appear harmless. In the background, it disabled SSL verification. It decoded a base64 URL pointing to an external resource, then fetched and executed a JSON payload containing a PowerShell command.
• Execution and Persistence: The PowerShell command, executed in an invisible window, downloaded a batch file (start.bat). This start.bat file performed privilege escalation, downloaded the final payload (named sefirah), added it to Microsoft Defender's exclusions, and then executed it.
• Infostealer Functionality: The final sefirah payload was a Rust-based infostealer designed to target a wide range of sensitive data. This included:
• Browser data from Chromium- and Gecko-based browsers (cookies, saved passwords, encryption keys, browsing data, session tokens).
• Discord tokens, local databases, and master keys.
• Cryptocurrency wallets and wallet browser extensions.
• SSH, FTP, and VPN credentials and configuration files (including FileZilla).
• Sensitive local files and wallet seeds/keys.
• System information.
• Multi-monitor screenshots.
• Exfiltration and Evasion: The stolen data was compressed and exfiltrated to a command-and-control (C2) server at recargapopular[.]com. The malware incorporated extensive anti-analysis features. It checked for virtual machines, sandboxes, debuggers, and analysis tools to evade detection.

• Kernel vulnerabilities like Copy Fail (CVE-2026-31431) and DirtyFrag demonstrate that even system components remain targets for privilege escalation, requiring diligent patching and careful configuration of kernel modules and namespaces.
• Supply chain attacks, exemplified by "Mini Shai-Hulud" and the Hugging Face infostealer, increasingly target trusted development processes, maintainer credentials, CI/CD pipelines, and artifact repositories as primary vectors for distributing malware and lateral movement.
• Credential theft remains a central objective across diverse attack types, spanning local system files, cloud environments (AWS, Azure, GCP), CI/CD secrets, and developer tooling, and led to widespread compromise and persistent unauthorized access.
• Advanced payloads, such as the "Mini Shai-Hulud" campaign's use of the Bun runtime and multi-layered encryption, are designed for stealth, cross-platform execution, and evasion.
• Proactive threat hunting and continuous behavioral monitoring are necessary. Anomalies like unexpected process execution (e.g., bun during package installation), suspicious syscall patterns (socket and splice), unusual GitHub activity, and anomalies in build integrity can indicate compromise where signature-based detection falls short.