RSS
Last updated: May 13, 2026 at 5:42 AM UTC
All 208 Vulnerability 72 Breach 41 Threat 88 Defense 7
Tag: credential-theft (11 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.

Hackers bought Google ads pointing to a fake GoDaddy WordPress login page - any site manager who clicked saw their credentials stolen

BleepingComputer reports a phishing campaign that bought Google Ads to push a fake GoDaddy ManageWP login page to the top of search results. ManageWP is GoDaddy's centralized dashboard for managing multiple WordPress sites - so a successful phish gives the attacker simultaneous access to dozens or hundreds of sites under one account. The fake page is a near-perfect clone of managewp.com hosted on a typosquat domain; victims who enter credentials are redirected to the real site to mask the theft. Same Google Ads abuse template used recently against AWS, Notion, and other developer-tool brands.

Check
Brief staff who manage WordPress sites that they should never click Google Ads for login pages. Search proxy logs for visits to ManageWP-themed domains other than managewp.com over the past 30 days.
Affected
GoDaddy ManageWP customers, particularly agencies and freelancers managing multiple client WordPress sites under one account. Acute risk: small WordPress agencies whose ManageWP credentials enable simultaneous access to 50-500+ client sites. Anyone using GoDaddy hosting for WordPress.
Fix
Enable two-factor authentication on ManageWP accounts immediately. Reset ManageWP passwords for any user who recently clicked a Google Ads result for the brand. Add a corporate browser policy to suppress Google Ads on developer-tool searches. For agencies: rotate WordPress site credentials linked through ManageWP. Watch for unfamiliar admin user creation across managed sites.

Attackers poisoned 60+ Ruby gems and Go modules, then waited for CI pipelines to install them and steal credentials

Socket disclosed a fresh wave of supply-chain attacks targeting Ruby gems and Go modules: more than 60 typosquatted packages were uploaded to RubyGems and the Go module registry, designed to look like legitimate dependencies developers might pull into a CI pipeline. Once installed, the packages exfiltrate environment variables (which typically include AWS keys, GitHub tokens, and database credentials in CI environments) to attacker-controlled servers. The targeting is deliberate: typosquats picked names close to popular gems and Go libraries. This is the same operational pattern as the SAP npm compromise covered Wednesday, but targeting Ruby and Go ecosystems.

Check
Review your CI pipelines for any Ruby gem or Go module added in the past month, and confirm every package name matches the canonical upstream exactly.
Affected
Any organization running CI/CD pipelines that install Ruby gems or Go modules without strict pinning. Particularly acute for organizations with broad CI environment variables (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, DATABASE_URL exposed to install scripts). Developer workstations are also exposed when developers run 'gem install' or 'go get' without verifying package names.
Fix
Pin every Ruby gem and Go module to specific versions and verify the upstream name matches. Move CI secrets out of environment variables and into ephemeral credential providers (OIDC for AWS, GitHub's masked secrets, Hashicorp Vault). Review CI logs for installs of packages whose names look like typosquats. Use Socket, Snyk, or equivalent tools to flag suspicious packages before install.

The same supply-chain worm that hit SAP packages on Wednesday spread to PyTorch Lightning and Intercom's npm SDK on Thursday

Update on the Mini Shai-Hulud campaign covered April 30: The same supply-chain worm that hit four SAP npm packages on Wednesday spread to two more major packages on Thursday. PyTorch Lightning, an AI training framework with 31,100 GitHub stars and hundreds of thousands of daily downloads, had malicious versions 2.6.2 and 2.6.3 published on PyPI for 42 minutes before being quarantined. Intercom-client, the official Node.js SDK for Intercom (361,510 weekly downloads), was compromised at 14:41 UTC. Intercom traced its compromise to pyannote-audio pulling Lightning as a dependency - showing the worm propagating through stolen credentials from the SAP victims.

Check
Audit any developer machine or CI runner that ran 'pip install' on PyTorch Lightning or 'npm install' on intercom-client between April 30 and May 1, and rotate every credential on those machines.
Affected
Lightning (PyPI) versions 2.6.2 and 2.6.3 - safe version is 2.6.1. Intercom-client (npm) version 7.0.4 (per Socket) and 7.0.5 (per Wiz). AI/ML environments running Lightning routinely hold GPU cluster credentials, cloud IAM tokens, Hugging Face API keys, and Weights & Biases tokens. Backend services and CI/CD pipelines integrating with Intercom's API are exposed even if they don't use Lightning.
Fix
Pin Lightning to 2.6.1 or earlier; reject 2.6.2 and 2.6.3. Update intercom-client per Intercom's advisory. Rotate all credentials potentially exposed: GitHub tokens, npm tokens, AWS/GCP/Azure keys, environment-variable secrets. Gate npm publish behind environment review (the same pattern that compromised SAP).

Hackers compromised four official SAP developer packages and used them to steal credentials from any developer who installed an update

Attackers compromised four official SAP npm packages on Wednesday and replaced them with versions that quietly steal developer credentials when installed. The packages - mbt, @cap-js/sqlite, @cap-js/postgres, and @cap-js/db-service - are SAP's open-source tools for cloud application development. Anyone who ran 'npm install' between 09:55 and 12:14 UTC on April 29 had their machine grab GitHub tokens, npm credentials, and AWS, Azure, and GCP secrets, then dump them into public GitHub repositories on the victim's own account. The same attackers (TeamPCP) hit Trivy, Checkmarx, and Bitwarden earlier this year. The malware skips Russian-language systems entirely.

Check
Audit your CI/CD pipelines and dev machines for the four compromised SAP packages installed between April 29 09:55 and 13:46 UTC, and rotate every credential on those machines.
Affected
Any developer or CI/CD environment that ran 'npm install' on mbt 1.2.48, @cap-js/sqlite 2.2.2, @cap-js/postgres 2.2.2, or @cap-js/db-service 2.10.1. SAP enterprise shops running CAP are at acute risk because these are core SAP development packages.
Fix
Update to clean SAP versions: @cap-js/db-service 2.11.0, @cap-js/sqlite 2.4.0, @cap-js/postgres 2.3.0. Rotate every GitHub token, npm token, and cloud credential (AWS, Azure, GCP) on machines that touched those packages. Search GitHub for repositories with the description 'A Mini Shai-Hulud has Appeared' belonging to your developers and report them to GitHub.

Hackers raced to exploit a critical LiteLLM flaw 36 hours after disclosure - any attacker who could reach the proxy could read all stored AI API keys (CVE-2026-42208)

LiteLLM, the popular open-source gateway used to centralize API access for OpenAI, Anthropic, and other AI providers, has a critical pre-authentication SQL injection bug that attackers started exploiting just 36 hours after the security advisory went public. The flaw lets anyone who can reach the proxy port read all the API keys stored inside - including master keys, virtual keys, and provider credentials. The bug was in the bearer-token check: the token was concatenated into a SQL query instead of passed as a parameter. Sysdig saw the first attack at 04:24 UTC on April 26, hitting three tables that hold the most valuable secrets.

Check
If you run any internet-facing LiteLLM proxy, patch to v1.83.7-stable today and treat every API key, virtual key, and stored provider credential as compromised.
Affected
LiteLLM versions 1.81.16 through 1.83.6, internet-reachable on the default proxy port. CVE-2026-42208, CVSS 9.3, pre-auth SQL injection. Blast radius is closer to a full cloud account compromise than a typical web app bug because LiteLLM holds OpenAI, Anthropic, and AWS Bedrock credentials.
Fix
Patch to LiteLLM v1.83.7-stable. If you can't upgrade, set 'disable_error_logs: true' under 'general_settings' as a workaround. Rotate every virtual key, master key, and upstream provider credential. Audit upstream provider billing for unexpected API calls since April 24. Block traffic from 65.111.27.132 and 65.111.25.67 (AS200373).

Iran operating like a criminal actor, ex-NSA director says - opportunistic credentials and amplification, not novel exploits

At the Asness Summit in Nashville on April 24, former NSA director Tim Haugh and Mandiant founder Kevin Mandia argued Iran's current cyber posture more closely resembles a criminal actor than a sophisticated APT - reliant on dark-web-purchased credentials, basic security gaps, and information operations to amplify modest intrusions. They cited the March 11 Stryker attack as the template: no malware, no zero-day, just legitimate credentials used to abuse MDM and delete data the attacker had permission to delete. Mandia's CISO advice: assume valid credentials for your staff are already on sale and build detection around their misuse.

Check
Run a credential-monitoring service against your domain this week and put alerts in place for impossible-travel and unusual-MDM-action patterns on admin accounts.
Affected
Any organization with US or Israeli ties, plus their suppliers and contractors, fits the Iranian targeting profile. Acute risk: organizations where MDM, RMM, or any endpoint-management platform can issue destructive commands without out-of-band approval; environments without credential-monitoring services watching dark-web markets for staff logins.
Fix
Subscribe to a credential-monitoring service (HaveIBeenPwned Enterprise, SpyCloud, Flare) and alert on staff credentials surfacing in stealer logs. Require step-up auth on any MDM or RMM destructive action (wipe, uninstall, mass-deploy). Brief comms staff that any Iran-claimed breach should be verified before public response - operators routinely overclaim to amplify modest access.

Smart Slider 3 Pro update system hijacked - backdoored version pushed to 800,000+ WordPress sites via official channel

Attackers compromised Nextend's update infrastructure and pushed a fully weaponized version of Smart Slider 3 Pro (3.5.1.35) through the official WordPress and Joomla update channel on April 7. Sites with auto-updates enabled received a multi-layered remote access toolkit disguised as a legitimate plugin update. The malicious version was live for approximately six hours before detection. Patchstack's analysis found: unauthenticated remote command execution via crafted HTTP headers, a second authenticated backdoor with PHP eval and OS command execution, a hidden administrator account (prefixed wpsvc_) invisible in the admin interface, persistent backdoors planted in the active theme's functions.php and wp-config.php, and automated credential theft sent to an external server. Traditional defenses like firewalls, nonce verification, and role-based access controls are irrelevant here because the malicious code arrived through the trusted update channel. Affected sites should be considered fully compromised.

Check
Check if any of your WordPress or Joomla sites run Smart Slider 3 Pro. If you updated to version 3.5.1.35 on or after April 7, your site is compromised.
Affected
WordPress and Joomla sites running Smart Slider 3 Pro version 3.5.1.35 that updated between April 7, 2026 and detection ~6 hours later. The free version is not affected. Sites with auto-updates enabled were most at risk.
Fix
If you installed 3.5.1.35: restore from a backup dated April 5 or earlier (to account for time zones). If no backup is available: update to 3.5.1.36, remove the hidden admin user (check for wpsvc_ prefix), clean wp-config.php (remove WP_CACHE_SALT define), clean .htaccess (remove WPCacheSalt line), remove persistence files from theme's functions.php, delete backdoor files in /cache and /media directories, remove malicious wp_options entries (_wpc_ak, _wpc_uid, _wpc_uinfo, _perf_toolkit_source), reset all admin and database passwords, change FTP/SSH and hosting credentials, and enable 2FA for all admin accounts. Sites should be treated as fully compromised - credential theft means passwords are already in attacker hands.

CPUID website hijacked to serve RAT malware through official CPU-Z and HWMonitor downloads

Attackers compromised a backend API on CPUID's website and replaced the official download links for CPU-Z and HWMonitor with trojanized versions containing the STX RAT. The attack lasted approximately six hours between April 9-10, timed to when the lead developer was on holiday. The malicious packages used DLL sideloading - legitimate CPUID executables (still properly signed) were bundled alongside a malicious CRYPTBASE.dll that masquerades as a standard Windows library. When users launched HWMonitor or CPU-Z, the malicious DLL loaded and deployed the RAT entirely in memory, with four independent persistence paths. The primary goal was browser credential theft, specifically targeting Chrome's IElevation COM interface to dump and decrypt saved passwords. The same threat group previously compromised FileZilla downloads in early March 2026. CPUID's signed original files were not tampered with - this was an infrastructure attack redirecting download links to attacker-controlled Cloudflare R2 storage.

Check
Check if anyone in your organization downloaded CPU-Z or HWMonitor from cpuid.com between April 9-10. These are popular IT diagnostic tools that sysadmins and technicians frequently download.
Affected
Anyone who downloaded CPU-Z 2.19, HWMonitor 1.63, or other CPUID utilities from cpuid.com during the approximately six-hour compromise window (April 9-10, 2026). If the installer showed Russian-language prompts or was named HWiNFO_Monitor_Setup.exe instead of the expected CPUID filename, the system is compromised.
Fix
If you downloaded during the compromise window: consider the host fully compromised and re-image the machine. The malware has 4 independent persistence paths and may have delivered additional C2 payloads. At minimum: rotate all browser-saved passwords immediately (Chrome passwords are the primary theft target), scan for the CRYPTBASE.dll sideloading indicator, and block supp0v3[.]com at the network level. For ongoing protection: verify file hashes against known-good CPUID releases before running.

766+ Next.js hosts breached in automated React2Shell credential theft campaign (CVE-2025-55182)

Cisco Talos uncovered a large-scale automated campaign by threat cluster UAT-10608 that exploits React2Shell - a CVSS 10.0 pre-auth RCE flaw in React Server Components used by Next.js. One crafted HTTP request is all it takes to get code execution, no credentials needed. The attackers scan with Shodan and Censys, breach Next.js apps, then deploy the NEXUS Listener framework to harvest database credentials, SSH keys, AWS tokens, Stripe API keys, Kubernetes secrets, and GitHub tokens at scale. At least 766 hosts across multiple cloud providers were compromised within 24 hours.

Check
Check if you run any Next.js applications using React Server Components, especially internet-facing deployments on AWS, GCP, or Azure.
Affected
React Server Components packages versions 19.0, 19.1.0, 19.1.1, and 19.2.0. Any Next.js application using the App Router with these React versions is vulnerable.
Fix
Update React Server Components to a patched version immediately. Rotate all credentials on any server running a vulnerable Next.js deployment - database passwords, SSH keys, AWS keys, Stripe keys, GitHub tokens. Enforce AWS IMDSv2 to prevent cloud metadata credential theft. Enable secret scanning in your repos. Monitor for outbound connections to NEXUS Listener C2 infrastructure.