KeyRotateLeak news archive
Every breach advisory KeyRotate has sent, once it is more than 30 days past its last date. Old does not always mean finished: a key that leaked months ago and was never replaced still works for whoever took it.
Current advisories are on Leak news
0 archived advisories
October 2026
CriticalAffected 21 Oct 2026 · contained 22 Oct 2026Railway environment variables exposed (October 2026)
An attacker reached the system where Railway stores environment variables and decrypted some of them: API keys, database passwords and private registry credentials. Railway believes the attackers were after AI provider keys. Rotate every secret you keep in Railway variables, paste the new value into Railway and redeploy, then revoke the old one at its vendor.
Keys most likely to be affected: OpenAI, Anthropic, OpenRouter, xAI (Grok), Stripe, GitHub
What to do (8 steps)
- Rotate every API key, token and password in your Railway variables (service and shared), paste the new values into Railway, redeploy, then revoke the old keys at each vendor.
- Check OpenAI, Anthropic, OpenRouter, xAI (Grok) and Stripe for usage you don't recognise since 21 October 2026.
- Change the passwords of PostgreSQL, MySQL, MongoDB and Redis databases whose connection strings were in Railway variables.
- Replace the private container registry credentials saved in Railway.
- Create new Railway API tokens. Railway invalidated every token on 22 October, so scripts and CI using the old ones have stopped working. ↗
- Redeploy services that use Railway Buckets so they pick up the new bucket credentials, and reconnect GitHub.
- Check GitHub, AWS and Google Cloud audit logs for access you don't recognise.
- Watch for Railway's email saying whether your account was affected, and treat any message asking for your Railway password or tokens as phishing.
ModerateAffected 21 Oct 2026 · contained 22 Oct 2026Node.js security release: Brotli code execution and TLS checks (October 2026)
Node.js 26.12.1, 24.22.1 and 22.23.4 (21 October 2026) fix ten flaws. The worst, CVE-2026-111497, lets malformed Brotli data passed to node:zlib corrupt memory, which can mean remote code execution in a server that decompresses what others send it. Three more let a TLS certificate be accepted for the wrong IP address, so a client could send its API key or password to an impostor. The release also stops trusting the compromised eMudhra intermediates. No attacks have been reported. Node.js 20 and older get no fix.
What to do (5 steps)
- Update every Node.js install (servers, containers, CI images, Lambda and other pinned runtimes) to 26.12.1, 24.22.1 or 22.23.4 or later, then restart the apps. ↗
- Move apps still on Node.js 20 or older to a supported version; they will not be fixed.
- Update desktop apps and tools that bundle their own Node.js (Electron apps, CLIs) when their makers ship the fix.
- If an internet-facing app decompresses Brotli from requests and ran an unfixed version, rotate the secrets in its environment and .env files.
- Apps that send an API key or password over TLS to a service addressed by IP: after updating, rotate those credentials if the network between them isn't trusted.
CriticalAffected 21 Oct 2026 · contained 22 Oct 2026LiteLLM 1.107.0 release carried credential-stealing malware (October 2026)
LiteLLM 1.107.0 on PyPI (21 October 2026, 11:39–13:23 UTC) and the Docker Hub and GHCR images tagged v1.107.0, latest, main-latest and main-stable (until 14:20 UTC) were built by an attacker and steal credentials: AI provider keys, including those stored in a LiteLLM proxy's database, cloud and Kubernetes credentials, SSH and Git keys, and Claude, Codex, Gemini and Cursor sign-ins. The code runs every time Python starts, even if LiteLLM is never imported. If a machine or container installed it, assume everything it could reach was stolen: clean it first, then rotate. The attackers got in with GitHub tokens found in logs that had recorded Claude Code output.
Keys most likely to be affected: OpenAI, Anthropic, Google (Gemini), OpenRouter, GitHub
What to do (8 steps)
- Look for litellm 1.107.0 in every virtualenv, CI job and container, and for images pulled on 21 October from the latest, main-latest or main-stable tags. Files named cook.pth, cook.py or sitecustomize.py in site-packages confirm it.
- Don't run pip first: any Python start runs the malware again. Delete cook.pth, cook.py, sitecustomize.py and their __pycache__ files from every site-packages, stop the Python process holding /tmp/remote_code_loader.lock, then rebuild or reinstall with litellm==1.106.2. ↗
- Rotate every provider key stored in the LiteLLM proxy (config, environment and database), the master key, every virtual key and the DATABASE_URL password.
- Rotate every other secret the machine could reach: cloud roles and access keys, GitHub and Git tokens, SSH and GPG keys, database passwords and any secret in a process's environment. Rotate again anything you replaced before the machine was cleaned.
- Sign out of Claude Code, Codex, Gemini CLI and Cursor on that machine and sign in again, and change the passwords saved in its browsers.
- Check AWS CloudTrail for GetCallerIdentity calls, Bedrock use, IAM enumeration and new access keys since 11:00 UTC on 21 October 2026, and AI provider usage for requests you didn't make.
- Block the domain litellm.dev in DNS or at your firewall; the malware sends what it steals there.
- Search logs that record AI tools' output (Claude Code transcripts, proxy request logs) for GitHub tokens and other secrets, and revoke any you find.
HighAffected 12 Oct 2026 – 21 Oct 2026 · contained 22 Oct 2026GitLab self-managed: critical remote code execution flaw (October 2026)
GitLab fixed CVE-2026-110264 (CVSS 10.0) on 21 October 2026: anyone, without signing in, could run code on a self-managed GitLab server with a crafted regular expression. Every version since 7.0 is affected; GitLab.com and GitLab Dedicated are already fixed. It is one of several regular-expression flaws GitLab fixed this month, and one fixed on 12 October already has a public exploit. GitLab has not reported attacks, but a server taken over this way gives away its CI/CD variables, tokens and repositories. Update now; if the server was reachable from the internet, rotate its secrets too.
Keys most likely to be affected: GitLab
What to do (5 steps)
- Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13 or later. Single-node servers are offline while migrations run. ↗
- If the server could be reached from the internet before you updated, treat it as possibly taken over: look for "Onigmo native worker crash" and bursts of Org-mode render errors in the logs, and for admin users, tokens or SSH keys you don't recognise.
- Rotate the secrets in CI/CD variables (project, group and instance), deploy tokens, personal and project access tokens, runner tokens and webhook secrets, then revoke the old ones.
- Check pipelines for jobs you didn't start, and repositories for commits, tags or branch-protection changes you didn't make.
- On GitLab.com or GitLab Dedicated there is nothing to update.
ModerateAffected 19 Oct 2026 – 22 Oct 2026 · contained 22 Oct 2026ThreeTrader: possible unauthorised access (October 2026)
ThreeTrader emailed customers about possible unauthorised access to its systems, in the same days as the Onamae.com Desktop Cloud VPS attack and unauthorised trades at other FX brokers. It has published no details. Change your client portal password and the password of every MetaTrader account, and turn on two-factor authentication. The notice linked here is Myforex's summary; ThreeTrader's own email is the primary source.
What to do (5 steps)
- Change your ThreeTrader client portal password.
- Change the password of every MetaTrader (MT4/MT5) account.
- Turn on two-factor authentication where it is offered.
- Check trading history and balances, and contact ThreeTrader about anything you don't recognise.
- Check that any email about this comes from threetrader.com, and go to the portal directly rather than through its links.
HighAffected 19 Oct 2026 – 21 Oct 2026 · contained 22 Oct 2026Gaitame Finest: logins with leaked passwords and unauthorised trades (October 2026)
Gaitame Finest found third parties logging in to some customers' accounts and trading, using IDs and passwords that may have leaked from other companies' services; it says nothing leaked from its own systems. It has restricted the affected accounts and will contact those customers. Change your My Page and MT4/MT5 passwords, set up one-time passwords and check your history.
What to do (4 steps)
- Change your My Page password and your MT4/MT5 trading passwords. ↗
- Change the password on any other service where you used the same one.
- Check login and trading history, and call Gaitame Finest on 0120-217-033 (weekdays 10:00–17:00 JST) about trades you didn't make.
- Set up one-time passwords for your account.
CriticalAffected 19 Oct 2026 – 22 Oct 2026 · contained 22 Oct 2026FXTF trading logins stolen through a VPS service (October 2026)
FXTF (Goldenway Japan) found that some customers who trade from a VPS had their trading account ID and password taken in an attack on another company's VPS service, and that they may have been used to log in and trade. FXTF says its own systems were not breached. It asks VPS users to change their trading password now and recommends everyone else does too, and makes one-time passwords mandatory for MT4/MT5 from 23 October.
What to do (6 steps)
- Change your FXTF trading account password now, from a device other than the VPS. If you can't, call FXTF support on 0120-445-435. ↗
- Register a passkey at My Page and turn on passkey login.
- Log out of FXTF MT4, FXTF MT5, FXTF GX and My Page everywhere, so no one else keeps a session.
- Check trading history and balances for trades you didn't make, and report them to FXTF.
- Set up the one-time password FXTF requires for MT4/MT5 logins from 23 October.
- Change the password on any other service where you used the same one.
ModerateAffected 21 Oct 2026 – 22 Oct 2026 · contained 22 Oct 2026DigiD and MijnOverheid taken offline over the PHP flaw (October 2026)
On 21 October 2026 Logius took DigiD.nl, MijnOverheid.nl and other government sites offline as a precaution against the critical PHP flaws (PHP2Shell), and brought them back once they were fixed. The DigiD app and DigiD logins elsewhere kept working. No DigiD account or data is reported to have been taken, and the NCSC saw no abuse. Scammers use outages like this: be wary of messages offering another way to log in or asking you to reactivate DigiD.
What to do (4 steps)
- Log in only through digid.nl, the DigiD app or the site of the organisation you're dealing with, never through a link in an email or text. ↗
- Use the DigiD app or the SMS check rather than a username and password alone.
- Check the usage history in Mijn DigiD for logins you don't recognise.
- If you entered your DigiD details on a site you reached through a link, contact the DigiD helpdesk straight away.
ModerateAffected 16 Oct 2026 – 21 Oct 2026 · contained 21 Oct 2026State Bank of India customer data on the dark web (October 2026)
State Bank of India told the stock exchanges on 21 October 2026 that 3,897 customer records with personal details (name, gender, date of birth, mobile number, email, address, branch and CIF identifiers) were among about 375,000 records offered on the dark web. Passwords were not reported. SBI does not yet know where the data came from and has not said it has told the customers affected. Expect convincing phishing calls, texts and emails that quote these details.
What to do (5 steps)
- Never share an OTP, PIN, password or card details by phone, text or email; SBI does not ask for them.
- Treat calls and messages that quote your account details as possibly fake; call SBI back on the number on its website or your card.
- Change your internet banking password and MPIN if you use them anywhere else.
- Check that SMS and email alerts are on and that the registered mobile number and email are still yours.
- Report fraud straight away to SBI and to India's cybercrime helpline (1930) or cybercrime.gov.in. ↗
CriticalAffected 19 Oct 2026 – 21 Oct 2026 · contained 21 Oct 2026Onamae.com Desktop Cloud FX servers hacked; trading logins stolen (October 2026)
Someone planted malware on servers of Onamae.com Desktop Cloud (お名前.com デスクトップクラウド), GMO's VPS for automated FX trading; up to 26,739 servers may be affected. Trading-account logins saved in MT4/MT5 and other tools on the servers were taken and used to trade from customers' accounts, and losses of millions of yen have been reported. GMO stopped every server from 04:00 JST on 21 October and has not said when they will restart or when the intrusion began. From a different device, change the password of every trading account and every other login used on the server, then end all sessions.
What to do (8 steps)
- From a device other than the VPS, change the password of every trading account and trading tool used on the server (MT4/MT5, cTrader, the broker's My Page). ↗
- Then log off every session, at the broker's My Page or support desk if the platform can't, so the stolen login can't be used.
- Check trading history and balances, and tell the broker straight away about trades you didn't make.
- Turn on two-factor authentication, one-time passwords or passkeys wherever the broker offers them.
- Change every other password used, saved or written down on the server (browser, notepad, email), and on any service where you used the same one.
- With the server stopped your EA isn't running: manage or close open positions yourself.
- Read your broker's notice: OANDA, Titan FX, AXIORY, IronFX, IS6FX, XMTrading and FXTF have published instructions.
- Ignore emails that claim to come from the attackers, and any message asking for passwords or card details; GMO says it never asks by email or phone.
CriticalAffected 17 Oct 2026 – 19 Oct 2026 · contained 20 Oct 2026OpenCode Console provider keys exposed (October 2026)
An intruder reached a legacy OpenCode Console system and may have read the OpenAI, Anthropic and Google keys that about 1.4% of Console users had linked in their workspaces; some saw large unauthorised charges within hours. OpenCode on your Mac (CLI and desktop app) keeps keys locally and was not affected. Revoke every provider key you linked in OpenCode Console at the provider, create a new one, and update the apps that used it.
Keys most likely to be affected: OpenAI, Anthropic, Google (Gemini)
What to do (6 steps)
- Revoke every OpenAI, Anthropic and Google key you linked in an OpenCode Console workspace, using each provider's own dashboard, then create new keys and update every app that used the old ones.
- Check OpenAI, Anthropic and Google Cloud usage and billing since 16 October 2026 for requests you didn't make, and report fraudulent charges to the provider and to OpenCode.
- Set a monthly spending limit or budget alert at each provider so a stolen key can't run up a large bill.
- If Google Cloud suspended a project for hijacked resources, rotate its keys first, then appeal the suspension in the Google Cloud console. ↗
- Look for OpenCode's email to affected users (OpenCode says that if you didn't get one, your keys weren't affected), and don't link providers in Console again until OpenCode says the incident is over.
- Go to provider dashboards directly rather than through links in breach emails, and treat any message asking for your API keys or OpenCode sign-in as phishing.
HighDisclosed 17 Oct 2026eMudhra certificate authority keys compromised (October 2026)
Eight eMudhra intermediate certificate authorities (EM DV, OV and EV TLS CA - G3B and G3C, and EM OV CS CA - G3B and G3C) were made in April 2025 with private keys anyone could work out. Until they were blocked, anyone could have issued a trusted website or code-signing certificate in any name. Browsers, Apple and Microsoft blocked them from 17 to 20 October 2026 and eMudhra revoked them. Replace every certificate they issued, and update anything that keeps its own list of trusted authorities.
What to do (5 steps)
- Replace every certificate issued by one of these intermediates. eMudhra has stopped issuing from them and is moving customers to its RSA hierarchy (emSign Root CA - G1); a certificate from another authority works too.
- Re-sign software signed with a certificate from EM OV CS CA - G3B or G3C, and stop trusting older builds signed with it.
- Search Certificate Transparency for your domains for any certificate from these intermediates that you didn't request. ↗
- Update macOS, browsers, Python certifi, Node.js, Go and Java so they stop trusting the compromised intermediates. ↗
- macOS's built-in curl and other tools that don't check revocation still accept these certificates. Mozilla's advisory explains how to take the emSign roots out of /etc/ssl/cert.pem. ↗
CriticalAffected 30 Sep 2026 – 1 Oct 2026 · contained 15 Oct 2026STUDIO unauthorized access (October 2026)
Third-party API keys and tokens saved in STUDIO's API integrations (Data Connect, API Connect), custom proxy keys, Google Sheets integration credentials and page passwords may have been read, along with the key that decrypts them. Rotate every key you saved in STUDIO, paste the new one into STUDIO, then revoke the old key at its vendor.
Keys most likely to be affected: OpenAI, Google (Gemini), Anthropic, Stripe
What to do (10 steps)
- Rotate every API key and token saved in Data Connect or API Connect, paste the new ones into STUDIO, then revoke the old keys at each vendor.
- At each vendor whose key was in STUDIO, check usage, billing and logs from 30 September 2026 for activity you don't recognise.
- Change your STUDIO password (email sign-in only), and the password on any other service where you used the same one. ↗
- Change the password on every password-protected page.
- Forms ▸ Sync to Google Sheets ▸ Stop Sync, remove STUDIO at Google's linked apps, then set the sync up again. ↗
- Custom proxy: switch your server to STUDIO's new proxy key and tell STUDIO, within 30 days of their 16 October email.
- Change every webhook notification URL, and rotate any secret it carries.
- Delete your Live Preview URLs and issue new ones if you still need them. ↗
- Read STUDIO's email about your form submissions; if they held personal data, decide whether the people who sent them need to be told.
- Treat any email or call asking for your STUDIO password as phishing. STUDIO says it will never ask.
ModerateAffected 2 Oct 2026 – 8 Oct 2026 · contained 9 Oct 2026SBI SECURITIES warning: passkeys used through hijacked Google and Apple accounts (October 2026)
SBI SECURITIES warned that criminals are phishing Google and Apple account logins, then using the passkeys and password notes synced to those accounts to sign in to brokerage accounts and trade. The cases were reported at other securities firms; SBI SECURITIES says none of its own accounts have been hit. If your passkeys live in a Google or Apple account, protect that account as carefully as the brokerage login itself.
What to do (5 steps)
- On the Google or Apple account that stores your passkeys, check two-step verification and the recovery email and phone, and remove devices you don't recognise. ↗
- Sign in to SBI SECURITIES with a passkey and turn off the login password.
- Don't keep brokerage passwords in cloud notes or anywhere else a phished account would reveal.
- Don't sign in through links in emails or texts; open the site or app directly.
- Check trading history and the contact details on the account for changes you didn't make.
Nothing here yet. Advisories move here 30 days after their last date.