dependency management
7 articles with this tag
Ethersphere bee-js 13.3.0 and Swarm Desktop 0.56.2 Shipped Malware (November 2026): Affected Versions and What Users Should Do
Version 13.3.0 of the npm package @ethersphere/bee-js, from Ethersphere, the developer of the Swarm decentralized storage network, contained malicious code. A GitHub advisory (GHSA-hh7j-5m3j-23pf) published on November 9, 2026 lists 13.3.0 as the only affected version and says there is no patched version. It says any computer that has the package installed or running should be considered fully compromised, and that all secrets and keys on it should be rotated immediately from a different computer. Removing the package may not clear all malicious software the install caused. For Swarm Desktop, Ethersphere's release notes say version 0.56.3, released on November 9, replaces the compromised 0.56.2. According to a security firm's analysis, bee-js 13.3.0 appeared on npm at about 00:09 UTC on November 9 (09:09 Japan time) and was removed about 75 minutes later. Swarm Desktop 0.56.2 was public for about 8.5 hours and was also delivered by auto-update to Windows x64 and Apple Silicon. bee-js 13.2.0 and earlier, and Swarm Desktop 0.56.1, are reported as not affected. The same analysis says the Bee node's configuration file (which holds a plaintext password) and its wallet key were targeted, and that credentials used by the official release automation were abused. Our conclusion: rebuild any machine or CI environment that installed an affected version, move the wallet to a new key and move funds, and rotate credentials from a different machine.
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 outside this compromise, and the company asks users to pin 1.106.2 or another explicit earlier version. On October 24 (UTC) the company published 1.103.8, 1.104.6, 1.105.4 and 1.106.3, and from these releases Docker images and Helm charts are signed with a new cosign key (the previous key no longer verifies them). On October 23 the company published a root cause analysis and corrected its first belief that the tokens were taken from the logs of an internal LiteLLM deployment. According to the analysis, a configuration file committed by mistake to a public repository on May 27 contained the master key of an internal agent platform; the commit was overwritten but the key was never revoked. On October 10 the attacker used that key to call the platform's API and obtained the GitHub CLI token of a GitHub organization owner configured there. With it, the attacker exfiltrated CI secrets to obtain two more maintainers' tokens, and on October 21 disabled branch protection, changed the release workflow and approved the release. 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.
osv-scanner in Practice — pnpm, Ignoring CVEs, Offline Mode, and the Errors You Hit
Only the second-day questions, answered against the official docs. pnpm-lock.yaml is supported; ignores live in osv-scanner.toml under IgnoredVulns and can carry an expiry; offline mode is three flags with three different jobs. This site's view: a scanner reports known vulnerabilities, and says nothing about a version you pinned yourself going stale — that needs a separate mechanism.
Express (Node.js) security — a production hardening reference
Express is minimalist — it guards almost nothing by default, so you add the defenses. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — security headers (helmet) + disabling x-powered-by, npm dependency CVEs, input validation and injection (SQL/NoSQL operator), authentication and owner-scoped authorization, rate limiting and size caps, sessions/cookies/CSRF, SSRF, production error handling (no stack exposure), NODE_ENV, and (3) a self-verification checklist. Defensive only — no attack steps.
Next.js security — a production hardening reference
Next.js's defaults are fairly safe, but incidents happen at the server/client boundary. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — the boundary and env vars (NEXT_PUBLIC_), dependency CVEs (including core RCE), Server Actions / Route Handlers authorization + input validation, SSRF on server-side fetches, security headers/CSP, auth/session/cookies, rate limiting, and (3) a self-verification checklist. Defensive only — no attack steps.
Ruby on Rails security — a production hardening reference
Rails ships conventions and safe defaults (CSRF protection, Strong Parameters, an ORM), but production incidents come from operations. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — secrets and credentials (master key/secret_key_base), production config (force_ssl, no exception exposure), gem CVEs, Strong Parameters/Mass Assignment, authorization (Pundit, owner scope), injection and dangerous methods (where interpolation/send/constantize), sessions/cookies/CSRF, SSRF/uploads, and (3) a self-verification checklist. Defensive only — no attack steps.
Spring Boot security — a production hardening reference
Spring Boot is a stable framework, but incidents come from dependencies, config, and authorization. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — dependency CVEs (Log4Shell-class, judge by running version), production config and externalized secrets, Spring Security authorization (default-deny/method security/owner checks), Actuator/management exposure reduction, unsafe deserialization, injection, headers/CSRF/session, SSRF, and (3) a self-verification checklist. Defensive only — no attack steps.