RSS
Last updated: May 13, 2026 at 5:42 AM UTC
All 208 Vulnerability 72 Breach 41 Threat 88 Defense 7
Tag: linux (6 articles)Clear

New Linux backdoor 'PamDOORa' silently steals SSH credentials from every user logging into a compromised server - and erases its tracks from the logs

Group-IB and Flare disclosed PamDOORa, a new Linux backdoor for sale on the Russian-speaking Rehub cybercrime forum at $900 (down from $1,600). PamDOORa hijacks the Linux Pluggable Authentication Module (PAM) framework that handles SSH logins - so it intercepts every legitimate user's password as they authenticate, before any application-level logging fires. The backdoor injects a malicious pam_linux.so module into the authentication stack rather than replacing files. It also tampers with lastlog, btmp, utmp, and wtmp to erase attacker login traces - meaning incident response teams who SSH in to investigate will have their own credentials silently stolen. Group-IB notes the abuse method is not yet in MITRE ATT&CK.

Check
Audit /etc/pam.d/ for unfamiliar pam_*.so modules, particularly pam_linux.so. Compare loaded PAM modules against your distribution's default set. Hunt /tmp for files with random names containing XOR-encrypted credential captures.
Affected
All x86_64 Linux servers running OpenSSH for remote access. PamDOORa is post-exploitation, so attackers must already have root - but once installed it captures every SSH credential and persists invisibly. Acute risk: any Linux server compromised at any point in the past, regardless of remediation - PamDOORa survives standard cleanup unless PAM-specific auditing was performed.
Fix
Enable SELinux or AppArmor in enforcing mode to constrain PAM module loading. Install Auditd with DISA-STIG rules to alert on /etc/pam.d/ changes. Deploy rkhunter or chkrootkit for routine PAM rootkit detection. Treat any compromised Linux server as having fully exposed credentials - rotate every SSH key, password, and token.

New 'PCPJack' worm hunts down and removes competing malware before stealing cloud credentials - exploits five different vulnerabilities to spread

BleepingComputer and The Hacker News disclosed a new credential-stealing worm called PCPJack that hunts and removes the well-established TeamPCP malware family before installing itself - the first observed case of one cybercrime operation systematically displacing another at scale. PCPJack exploits five separate vulnerabilities to spread worm-like across cloud and Linux environments, then steals SSH keys, AWS credentials, GitHub tokens, and other secrets. Operators replace TeamPCP files in place rather than just disabling them, suggesting an attempt to inherit TeamPCP's existing victim base. The pattern signals a maturing cybercrime market.

Check
Search EDR and cloud logs for sudden disappearance of TeamPCP indicators on hosts that previously had them - that is the likely PCPJack handover signature. Hunt for outbound credential-theft traffic patterns matching the five CVEs PCPJack exploits.
Affected
Linux servers, cloud workloads (AWS, GCP, Azure), and CI/CD runners that previously had TeamPCP cryptominer infections. Any host running unpatched versions of the five CVEs PCPJack exploits is in scope. Cloud accounts where SSH keys, IAM access keys, or GitHub tokens are stored on compromised workloads face credential-theft escalation.
Fix
Patch all five CVEs PCPJack exploits per the Wiz and Datadog IoC publications. Rotate cloud credentials, SSH keys, and GitHub tokens on any host that may have had TeamPCP - do not assume TeamPCP cleanup means safety. Block PCPJack C2 domains at egress. Shift to short-lived IAM credentials via OIDC and remove static keys from VMs entirely.

9-year-old Linux kernel bug 'Copy Fail' lets any user with shell access become root in seconds - works on every major distribution since 2017 (CVE-2026-31431)

Researchers at Theori and Xint disclosed Copy Fail yesterday, a Linux kernel bug introduced in 2017 that lets any unprivileged user with shell access become root in seconds. The exploit is a 732-byte Python script that works without version-specific tweaks on every major Linux distribution since 2017 - Ubuntu, Amazon Linux, RHEL, SUSE. Unlike previous kernel bugs (Dirty Cow, Dirty Pipe), Copy Fail has no race condition and no per-kernel offsets. It also leaves no trace on disk because it only modifies the in-memory page cache. The bug was found using AI-assisted reverse engineering and has been hiding in the open for nearly nine years.

Check
Update the kernel on every Linux server, container host, and CI runner you operate today, especially anything that runs untrusted code or hosts multiple tenants.
Affected
Every Linux distribution since 2017 with kernel 4.14 or later. CVE-2026-31431, CVSS 7.8. Acute risk: shared-kernel multi-tenant environments (Kubernetes nodes, Docker hosts), CI/CD runners that execute untrusted PR code (GitHub Actions self-hosted, GitLab runners, Jenkins agents), notebook hosts, and anything using Linux containers as a security boundary. Firecracker microVMs and gVisor are not affected.
Fix
Apply the kernel update from your distribution that includes commit a664bf3d603d. Until patched, blacklist the algif_aead module: 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf' then 'rmmod algif_aead'. The disable does not break dm-crypt, kTLS, IPsec, or SSH. For multi-tenant Kubernetes clusters, treat container boundaries as broken until patched.

Broken VECT 2.0 ransomware is silently destroying any file larger than 131 KB on Windows, Linux, and ESXi - paying the ransom recovers nothing

Researchers found a serious bug in VECT 2.0, a new ransomware family making the rounds: the encryption routine corrupts any file larger than about 131 KB instead of encrypting it reversibly. Files smaller than the threshold encrypt and decrypt normally; everything bigger gets permanently destroyed. Operators don't seem to know yet, so victims who pay get a working decryption tool that recovers small files and tells them the large ones are 'corrupted' - which they are, because VECT broke them on the way in. The bug affects Windows, Linux, and VMware ESXi variants. Any large file on a VECT 2.0-hit system is irrecoverable regardless of whether the ransom is paid.

Check
Make sure every host that handles documents, databases, or virtual machine images has tested, off-network backups - because if VECT 2.0 hits, restore from backup is your only path.
Affected
Any Windows, Linux, or VMware ESXi system running unpatched RDP, SMB, or VPN exposure that VECT 2.0 operators are using as initial access. The 131 KB threshold catches almost everything important: Office documents, PDFs, databases, virtual machine disks, source code repos. Small config files survive, which makes the attack look partially recoverable until victims realize the scope.
Fix
Verify backups are off-network (immutable storage, air-gapped tape, S3 object lock) and test restore for at least one large file from each business-critical system. If hit by VECT 2.0, do not pay the ransom - large files cannot be recovered even if the operator delivers a working decryption tool. Restore from clean backup. Watch for VECT 2.0 indicators in EDR feeds; the bug may be patched in future versions.

New Linux variant of GoGra backdoor uses Microsoft Graph API for stealth C2 - blends in with legitimate Office 365 traffic

Security Affairs covered new research on April 23 documenting a Linux port of the GoGra backdoor, originally seen as Windows-only. The Linux variant retains GoGra's defining feature: it uses Microsoft Graph API as its command-and-control channel, fetching commands from Outlook drafts in an attacker-controlled Microsoft 365 tenant and writing results back to the same drafts. Because the C2 traffic is HTTPS to graph.microsoft.com - the same endpoint legitimate clients hit constantly - it is invisible to most network-layer detections. The Linux port targets enterprise Linux servers with Outbound 443 access to Microsoft cloud services, broadening reach onto build servers and jump hosts.

Check
Audit which Linux servers in your environment have outbound HTTPS access to graph.microsoft.com and restrict it to hosts with a documented Microsoft 365 use case.
Affected
Linux servers with outbound HTTPS access to graph.microsoft.com - in most enterprise networks that means almost all of them, since egress filters routinely allow the entire Microsoft 365 endpoint range by default. Build servers, jump hosts, developer workstations, and DMZ services with Linux are the highest-value targets because they often hold credentials and source code.
Fix
Restrict graph.microsoft.com egress to only hosts that genuinely need it (mail relays, M365 integrations). On all other Linux hosts, log and alert on outbound graph.microsoft.com connections. In your M365 tenant, enable audit logging for application registrations and OAuth grants and alert on tokens used from unfamiliar IPs. Rotate credentials for any Linux server that had unsanctioned graph.microsoft.com traffic.

12-year-old 'Pack2TheRoot' bug in PackageKit gives any local user root on default Ubuntu, Debian, Fedora, and RHEL/Cockpit installs (CVE-2026-41651)

Deutsche Telekom's Red Team disclosed CVE-2026-41651, a local privilege escalation in the PackageKit daemon that has shipped in default Linux installations since November 2014. Any unprivileged local user can invoke 'pkcon install' without a polkit prompt, install or remove arbitrary packages, and escalate to root. CVSS 8.8. Confirmed-vulnerable defaults include Ubuntu Desktop and Server LTS, Debian Trixie, Rocky Linux 10.1, and Fedora 43; any RHEL server running Cockpit is also exposed because Cockpit loads PackageKit on demand via D-Bus. PackageKit 1.3.5 fixes it. The researchers credited Anthropic's Claude Opus with helping guide the discovery.

Check
Inventory every Linux endpoint and server for PackageKit, patch to 1.3.5 today, and audit historical journalctl output for the assertion-failure IoC.
Affected
PackageKit versions 1.0.2 through 1.3.4 (every release between November 2014 and the April 22, 2026 fix). Default Ubuntu Desktop and Server LTS, Debian Trixie 13.4, Rocky Linux 10.1, Fedora 43. Plus any RHEL or CentOS server running Cockpit, which loads PackageKit on demand via D-Bus.
Fix
Update PackageKit to 1.3.5 across the fleet. Verify with 'dpkg -l | grep packagekit' or 'rpm -qa | grep packagekit'. A process-list grep is insufficient because PackageKit is D-Bus-activated. Hunt past exploitation via 'journalctl -u packagekit | grep emitted_finished' for assertion-failure crashes. Where patching is delayed, mask the systemd unit and disable Cockpit.