secrets management
14 articles with this tag
LiteLLM 1.107.0 Shipped a Credential Stealer (October 2026): Affected PyPI Release and Docker Images, and What Users Should Do
On October 21, 2026 (UTC), BerriAI, the company behind LiteLLM, announced that its release pipeline had been compromised and that a v1.107.0 containing malware that steals credentials and loads remote-code-execution tools had been published. Affected were litellm==1.107.0 on PyPI (11:39 to 13:23 UTC) and the v1.107.0, latest, main-latest and main-stable tags on Docker Hub (11:46 to 14:20 UTC) and GHCR (from 11:46 UTC until taken down by 13:51 UTC, about two hours). The official v1.107.0 source tag on GitHub does not contain the malicious files; the artifacts were built from an attacker-controlled lookalike repository. All earlier versions are safe, and the company asks users to pin 1.106.2 or another explicit earlier version. The company says GitHub CLI OAuth tokens belonging to three developers were stolen and used to disable branch protection and change the release workflow, and believes the tokens were taken from the logs of an internal LiteLLM deployment. How the attacker got into that deployment is still being investigated. This site's conclusion: rebuild any environment that installed or started 1.107.0 during the window, and rotate every key it could reach, including LLM provider keys, the proxy master key, the database password and cloud roles.
543,699 credentials published on GitHub still worked (2026 study): why you must revoke, not delete, and what developers should do
A security company that sells secret-scanning tools examined a snapshot of about 224 million public repositories collected for LLM training and reported that 543,699 credentials still authenticated in late July 2026. The median time since exposure was 784 days. Almost all npm and GitHub tokens had been invalidated, while 75-88% of database connection strings still worked. More than 199,000 of the live credentials appeared after GitHub turned push protection on by default, and over half of the live ones were types push protection does not block by default. This site's conclusion: a credential pushed to a public repository cannot be recalled by deleting the file or rewriting history, so revoke it first. Whether a leaked credential is revoked automatically depends on the issuer; connection strings and many API keys stay valid until you stop them.
The TanStack, Nx Console and GitHub Compromise Chain (May 2026): What Developers Should Check
On May 11, 2026, the publishing pipeline of TanStack's Router/Start repository was abused to push credential-stealing code into 42 npm packages, 84 versions. An Nx contributor who installed one of them had a GitHub CLI token stolen, and on May 18 a tampered Nx Console extension (v18.95.0) was published. The same day, GitHub said an employee device had been compromised by a poisoned VS Code extension and GitHub-internal repositories were exfiltrated. In all three cases the attack went through legitimate accounts and distribution channels, so the defense is to make sure a single stolen publishing credential (token) is not enough to release a new version, and to verify that the safeguards you configured actually run.
Trivy Supply-Chain Compromise (March 2026): What to Do If You Run Trivy in CI
On March 19, 2026, a malicious v0.69.4 of Trivy, the open-source vulnerability scanner developed by Aqua Security, was released, and the GitHub Actions trivy-action (76 of 77 tags) and setup-trivy (all 7 tags) were repointed to malicious commits. According to Aqua, the malicious code collected secrets from CI runners and sent them out; the cause was credentials taken in a compromise that began in late February, which the attacker could keep using because the March 1 rotation was not done all at once. This site's take: the lesson is not only to pin actions by commit ID (SHA) instead of by tag. An action pinned by SHA can still call another component by tag, which lets a malicious version in. Leaked credentials must be replaced all at once, or the attacker can keep using them. Run scanners in jobs that hold no deployment secrets.
Vercel Security Incident (April 2026): What Developers Should Do About Exposed Environment Variables
On April 19, 2026, Vercel disclosed unauthorized access to certain internal systems. According to Vercel, a compromised third-party AI tool used by an employee let the attacker take over that employee's Google Workspace account, reach their Vercel account and a Vercel environment, and enumerate and decrypt environment variables of a limited subset of customers that were not marked sensitive. Vercel contacted affected customers directly and confirmed its published npm packages were not compromised. This site's take: whether a variable leaked depended on its label, readable (its value can be displayed again after saving) or write-only (it can be overwritten but never displayed). Store every secret you never need to read back as write-only (a Secret in today's Vercel), and inventory the AI tools employees connect to company accounts through OAuth (which lets outside apps access company accounts) the same way you inventory dependencies.
npm Supply-Chain Worms: How Credentials Are Stolen at Install Time, and How to Defend
Adding a dependency means running someone else's code with your privileges, so the defense belongs at install time. This site's view: signatures and provenance did not stop this campaign, so they cannot be the basis of trust. What works is disabling install scripts by default, letting dependencies age a few days before adopting them, and keeping tokens short-lived and narrowly scoped. And if you suspect infection, the order in which you revoke matters.
Stop secrets before they commit with gitleaks: catch API-key leaks before the push
Secrets can't be 'deleted after they leak.' Once committed, a secret stays in Git history, and once pushed it must be treated as leaked — the key needs revoking/rotating. gitleaks is a free tool that scans the whole repo and commit history with regex/entropy to find API keys, private keys, and tokens. The core of the defense is two checks: a pre-commit hook that stops it locally before the push, and CI/cron that catches what slips through. .gitignore only prevents new tracking — it can't detect, so you still need a scanner.
Are password managers safe? How they work, cloud vs local, and how to choose
A password manager helps you use a strong, unique password for each service. Zero-knowledge encryption is designed to protect contents even if encrypted data leaks from the provider, but safety also depends on master password strength, encryption settings, and device security. Use MFA to prevent unauthorized logins, and choose cloud or local by use.
Did you leave a secret file in a public directory? Audit your webroot
Anything in your webroot is fetchable by URL by anyone. A leftover token/credential JSON, .env, or backup means instant exposure — and if it came from a shared template, every site has the same file. Fix: put only publicly-shareable things in the public dir, keep secrets outside the webroot at perms 600, and once you find one, audit every site and host.
The security baseline for indie devs and small operators: standard controls in priority order
The baseline isn't 'all equally important.' This site's priority order: 1) admin accounts, domain and email (MFA), 2) secrets and code, 3) the app itself, 4) patch, detect, recover. With finite time, fill it top-down. Most serious breaches come not from novel attacks but from a gap in these basic controls.
Security inventory: 7 checks people running several servers overlook
For solo/small operators, incidents come less from missing controls than from untracked state. The boundary is the PC holding your keys. Prioritize 2FA by which account can recover the others (email first), list which SSH key opens which server and delete duplicates, unused keys and leftover registrations, remove plaintext passwords from the cloud, remediate reversibly one at a time, and keep secrets out of the ledger. Inventory before adding tools.
Self-hosted Git vs GitHub: which is actually more secure?
Self-hosting Git doesn't make you 'more secure' — it relocates the risk. The accidental-public-exposure class disappears, but patching the server, backups, and pre-commit secret detection move onto you. The right call if you keep doing that work; worse than GitHub if you neglect it. This site's view: self-hosting only works bundled with its compensating controls.
Is storing your passwords in Google Drive safe? How to keep them properly
Keeping passwords in a plaintext Google Doc/Sheet is dangerous: one Google account becomes the single point of failure for every password — account takeover, a rogue connected app, or phishing leaks them all at once. The safest option is a dedicated password manager (contents stay encrypted even when synced). If you must use Drive, store only an encrypted vault file and put phishing-resistant MFA on the account.
Codecov breach (2021) — when a CI tool was tampered with and secrets leaked
A trusted CI tool (the curl|bash Bash Uploader) was altered upstream. Because your own code was untouched, it went unnoticed for ~2 months while CI secrets leaked; a checksum check caught it. In your CI: verify fetched artifacts, least-privilege secrets, rotation, egress monitoring.