Last updated: September 29, 2026 at 8:42 AM UTC
All 891 Vulnerability 357 Breach 144 Threat 383 Defense 7
Tag: credential-theft (35 articles)Clear

Amazon Q Developer flaw let a malicious repo steal a developer's cloud keys

Wiz Research found a high-severity flaw in Amazon Q Developer, Amazon's AI coding assistant, that let a malicious code repository run commands and steal a developer's cloud credentials simply by being opened. The bug (CVE-2026-12957) lay in how Amazon Q handled Model Context Protocol servers: it read an MCP configuration file from the open workspace and automatically launched the servers it defined. Because those servers run as local processes that inherit the developer's full environment, a single config file committed to a repo could reach AWS keys, cloud tokens, API secrets, and SSH agent sockets, turning a git clone into a full compromise. Amazon has patched the issue and published an advisory.

Check
Confirm Amazon Q Developer is updated to the patched version, and review whether developers open untrusted repositories in AI coding assistants that can auto-launch Model Context Protocol servers from in-repo configuration files.
Affected
Developers using vulnerable versions of Amazon Q Developer (CVE-2026-12957) who open untrusted repositories; a malicious MCP configuration file could run commands and steal cloud credentials from the developer's environment.
Fix
Update Amazon Q Developer, treat opening a repository in an AI assistant as running its code, disable automatic MCP server launching where possible, and isolate untrusted repos without real credentials.

56 million accounts surface in latest infostealer log compilation

Breach-tracking service Have I Been Pwned has added a fresh batch of stealer logs covering 56,278,397 accounts, harvested by infostealer malware from infected computers. Unlike a single company breach, stealer logs are credentials and session data scraped directly from victims' devices, often capturing the exact website-and-password pairs a person types, plus browser cookies that can let attackers skip login entirely. Because the data comes from malware on individual machines, exposure cuts across countless unrelated services. The scale is a reminder that infostealer infections, frequently spread through cracked software, malicious ads, and fake downloads, remain one of the biggest sources of credential theft.

Check
Check whether your email or your organization's domains appear in Have I Been Pwned's stealer-log dataset, and look for signs of infostealer infection such as unexpected logins or browser-session anomalies.
Affected
Anyone whose device was infected by infostealer malware; exposed data includes saved website passwords and browser session cookies that can bypass logins across many unrelated services.
Fix
Reset passwords for exposed accounts from a clean device, invalidate active sessions, enable phishing-resistant MFA, and run endpoint malware scans to find and remove the underlying infostealer.

IronWorm Rust npm worm hits 36 packages, steals Anthropic/OpenAI/AWS credentials via eBPF rootkit and Tor; GitHub Actions used for exfil

JFrog has documented IronWorm, a new npm supply-chain worm that has infected 36 packages with an infostealer targeting 86 environment variables and 20 credential files - including OpenAI, AWS, Anthropic, and npm credentials, Vault configs, SSH keys, and Exodus wallet files. Written in Rust, it hides behind an eBPF kernel rootkit and communicates over Tor. It self-propagates using stolen npm Trusted Publishing secrets to trojanize the victim's own packages. JFrog found the same commit names as Shai-Hulud (commit author 'claude,' timestamps faked up to 13 years old) and suspects an evolution of TeamPCP's payload. Notably, it exfiltrates secrets by uploading them as innocuous-looking GitHub Actions build artifacts, avoiding external C2.

Check
Audit npm dependencies and CI for the 36 IronWorm-affected packages and preinstall scripts dropping Rust ELF binaries. Search build artifacts for disguised secret files. Rotate npm, AWS, OpenAI, Anthropic credentials.
Affected
Developers and CI systems that installed IronWorm-trojanized npm packages. It steals OpenAI/AWS/Anthropic/npm credentials, Vault configs, SSH keys, and wallets, then self-propagates via stolen Trusted Publishing secrets.
Fix
Remove affected packages, pin via lockfile, and rotate every credential reachable from affected hosts. Hunt for eBPF rootkit artifacts and Tor traffic. Review GitHub Actions build artifacts for exfiltrated secrets.

Nx Console 18.95.0 VS Code extension compromised in 11-minute window - kitty.py persistence and credential theft

The Nx team has confirmed that version 18.95.0 of its VS Code extension was malicious and that a few users were compromised. The bad version was available on the marketplace for only 11 minutes on May 18 (12:36 to 12:47 UTC), but that was enough to plant Python-based persistence under ~/.local/share/kitty/cat.py and a macOS LaunchAgent at com.user.kitty-monitor.plist, then steal tokens, secrets, and SSH keys reachable from the machine. The Nx team has shipped a clean 18.100.0 release and published indicators of compromise. This is the second time Nx has been targeted within a year, after the August 2025 s1ngularity supply-chain attack on its npm packages.

Check
Identify VS Code endpoints with the Nx Console extension. Check for ~/.local/share/kitty/cat.py, ~/Library/LaunchAgents/com.user.kitty-monitor.plist, /var/tmp/.gh_update_state, /tmp/kitty-*, or any process with __DAEMONIZED=1.
Affected
Anyone who installed Nx Console 18.95.0 from the VS Code marketplace during the 11-minute window on May 18 (12:36-12:47 UTC). A few users are confirmed affected.
Fix
Update Nx Console to 18.100.0. Kill malicious processes, delete IoC files, remove the LaunchAgent, and rotate every credential reachable from the developer machine - tokens, secrets, SSH keys.

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).