Closed logSaturday, October 24, 2026·Last watch 20:56 ET
Compromised releases, malicious packages and exploited bugs that touch your dependencies and pipelines, with what to do about each. Checked four times a day.
Node2Shell widens: the Brotli bug now reaches Python, Bun, Envoy and curl builds (HTTP2Shell). Plus a narrower x402 SDK fix.
LiteLLM publishes its root cause: a master key leaked in May led to stolen CI secrets from Oct 10. No new critical threats; Brotli, PHP2Shell and GitLab threads unchanged.
PHP2Shell: still no confirmed break-ins, but a private ASLR-bypass exploit raises the stakes. eMudhra CA fix now spans certifi, pip, uv, Node.js and Go trust stores; Brotli entry refined.
Logged Railway's build-infrastructure breach (rotate secrets stored there). No new critical threats; PHP2Shell, Brotli, GitLab, LiteLLM and eMudhra threads unchanged.
Threats not yet marked resolved. Open one for its full timeline.
Paste package names (one per line), or load a manifest or lockfile: package.json, package-lock.json, requirements.txt, poetry.lock, Pipfile.lock, Cargo.lock, go.mod, Gemfile.lock, composer.json. Matching entries get a "Matches your stack" label on every page, and you can filter to just those.
Your list stays in this browser (local storage). Files are read on your device and never uploaded. Matching is by package name, not version, so a match means "check this", not "you are vulnerable".
Two days into mass scanning for CVE-2026-109618 and CVE-2026-109619, no successful in-the-wild compromise has been confirmed: Sophos withdrew an earlier report of one, Wordfence and Hunt.io saw only failed attempts, and Sansec now says public exploits fail on default PHP settings. That window may not last. VulnCheck reports a working exploit for CVE-2026-109618 that leaks memory to defeat ASLR on x86-64 with error display off, the usual production setup; it is limited to its paying customers for now. Amazon's honeypots logged an attempt on Oct 17, four days before disclosure, so log reviews should start there. Fixed releases are unchanged (8.5.12, 8.4.27, 8.3.36, 8.2.35); PHP 8.1 and older get no fix, and neither CVE was in CISA KEV as of Oct 23.
php < 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35php -v | head -1docker images --format '{{.Repository}}:{{.Tag}}' | grep -iE 'php|wordpress|laravel|drupal'grep -rl 'PHP_SESSION_UPLOAD_PROGRESS' /var/log/nginx /var/log/apache2 /var/log/httpd 2>/dev/nullKeep patching to the fixed PHP releases and rebuild PHP base images; for end-of-life PHP, block multipart uploads at the edge if you can, and hunt for POST bodies containing PHP_SESSION_UPLOAD_PROGRESS from Oct 17 onward.
ReferencesCVE-2026-109618, CVE-2026-109619
SourcesSecurityWeek, AWS Security Blog
CVE-2026-111497 sits in Google's Brotli C decoder (versions 1.0.3 to 1.2.0), not only in Node.js, so anything that decodes untrusted Brotli data with a bundled or linked copy is exposed. On Oct 23-24 researchers confirmed the PyPI packages Brotli (fixed in 1.2.1) and brotlicffi (fixed in 1.2.1.0) are affected; urllib3/requests, httpx, aiohttp and Scrapy load them automatically when installed and will decode br responses. Bun 1.4.4, Envoy 1.40.0/1.39.3/1.38.6/1.37.8 and Istio 1.29.9/1.30.6/1.31.2 carry the fix; libcurl and Git for Windows builds linking Brotli 1.2.0 are also in scope. Bundled copies in the .NET runtime, the PHP brotli extension, the Ruby brotli gem, DuckDB, ClickHouse and Apache Arrow were still listed as unpatched on Oct 24. Upstream Brotli fixes are 1.0.10, 1.1.1 and 1.2.1, Debian 13 ships 1.1.0-2+deb13u1, and the cdxgen SBOM tool is fixed in 12.8.9 and 13.5.0. Public proof-of-concept code reportedly crashes stock builds; code execution has only been shown in Imperva's lab on an official Node.js 24.22.0 arm64 build and that exploit is unreleased. No in-the-wild exploitation is confirmed, and GitHub's advisory did not list the PyPI packages on Oct 23, so Dependabot may not flag them.
Brotli < 1.2.1brotlicffi < 1.2.1.0bun < 1.4.4envoy < 1.37.8 / 1.38.6 / 1.39.3 / 1.40.0istio < 1.29.9 / 1.30.6 / 1.31.2libbrotli 1.0.3-1.2.0cdxgen < 12.8.9 / 13.5.0pip show Brotli brotlicffi 2>/dev/null | grep -E '^(Name|Version)'grep -rniE '^"?(brotli|brotlicffi)\b' --include='requirements*.txt' --include='poetry.lock' --include='uv.lock' --include='Pipfile.lock' --include='pyproject.toml' .bun --version 2>/dev/null; envoy --version 2>/dev/null | head -1bundle list 2>/dev/null | grep -i brotliUpgrade Brotli to 1.2.1 and brotlicffi to 1.2.1.0 in every Python environment and image, update Bun, Envoy/Istio and OS libbrotli packages, then rebuild images and bundled binaries. Where you cannot patch yet, reject Content-Encoding: br at the edge.
Deployment platform Railway says an attacker escalated privileges through its build infrastructure on Oct 20-21, pulled encrypted customer environment variables, decrypted a subset, and obtained credentials for Railway's own CI environment. Its preliminary report puts potentially exposed environment variables at no more than 1.85% of workspaces, but it asked all users to rotate keys and sent AI providers broad key-revocation lists. Railway says the attacker was hunting AI provider API keys and that access was cut off by Oct 22; builds and deployments, paused during triage, were restored later that day, though commits pushed during the pause were not deployed. The entry point is not yet disclosed and a full report is pending; TechCrunch notes OpenCode reported a similar key-theft breach the same week.
railway (deploy platform)ls railway.json railway.toml nixpacks.toml 2>/dev/nullgrep -rnE 'RAILWAY_(TOKEN|API_TOKEN)' .github/workflows .gitlab-ci.yml .circleci 2>/dev/nullrailway --version 2>/dev/null; ls ~/.railway 2>/dev/nullRotate every secret stored in Railway (API, database, cloud and registry credentials), recreate Railway CLI and CI tokens, redeploy the latest commit, and review GitHub, Docker Hub and AI provider audit logs for use since Oct 20.
The eight eMudhra intermediate CA keys disclosed on Oct 20 were generated so weakly that anyone can recover them, which means a network attacker could mint certificates those intermediates sign; exposure dates back to April 2025, though no misuse has been found. Browsers block them already, but package managers, CI jobs and API clients that carry their own CA bundle keep trusting the chain until updated. Fixed bundles: certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Node.js 22.23.4/24.22.1/26.12.1, Go 1.27.3/1.26.10, rustls-webpki 0.103.16, webpki-roots 1.0.10, composer/ca-bundle 1.4.16/1.6.0, plus Ubuntu, Debian, Alpine, Fedora and Wolfi ca-certificates. Bun, FreeBSD and Java's JDK cacerts were still unfixed or unconfirmed on Oct 23, and container images keep the old roots until rebuilt.
certifi < 2026.10.19pip < 26.2.2uv < 0.13.4node < 22.23.4 / 24.22.1 / 26.12.1go < 1.27.3 / 1.26.10webpki-roots < 1.0.10rustls-webpki < 0.103.16composer/ca-bundle < 1.4.16ca-certificates (distro)pip show certifi pip 2>/dev/null | grep -E '^(Name|Version)'grep -c 'emSign' "$(python3 -m certifi)"grep -c 'emSign' /etc/ssl/certs/ca-certificates.crtnode -v; go version; uv --version; grep -A1 -E 'name = "(webpki-roots|rustls-webpki)"' Cargo.lock 2>/dev/nullBump certifi, pip, uv, Node.js, Go and Rust webpki crates to the fixed versions, rebuild container images on patched base images, and check Java and Bun services separately; the system bundle should contain no emSign entries after updating.
ReferencesCVE-2026-111943, GHSA-6q48-6c7w-9gw2
SourcesEndor Labs, BleepingComputer
V12 reported three flaws in the x402 agent-payment SDKs, published Oct 22-23. The TypeScript fetch and axios clients had no default spending cap, so a hostile API could ask an agent to sign away its full balance; @x402/svm 2.0.0 to 2.22.0 accepted a Solana token approval as payment; and the sign-in extension could sign a login for another site. TypeScript packages are fixed in 2.23.0 (current is 2.28.0); the Python and Go clients were fixed in their Aug 18 releases, with exact versions not stated. There is no CVE or GHSA, npm audit does not flag the old releases, and no attacks have been reported.
@x402/fetch < 2.23.0@x402/axios < 2.23.0@x402/svm 2.0.0-2.22.0@x402/extensions < 2.23.0npm ls @x402/fetch @x402/axios @x402/svm @x402/extensions 2>/dev/nullgrep -rniE 'x402' --include='requirements*.txt' --include='poetry.lock' --include='uv.lock' --include='go.mod' .If your agents pay with x402, move the @x402 packages to 2.23.0 or later (and the Python/Go clients to current releases) and set an explicit per-request spending limit.
SourcesThe Hacker News
LiteLLM's Oct 23 write-up says a master key for its Agent Platform was committed to a public repo in May and never revoked. On Oct 10 the attacker used it to pull an org owner's unscoped GitHub CLI token, then ran throwaway CI branches that shipped repository secrets to a webhook, yielding two more maintainer tokens; the owner token overrode branch protection to point the Oct 21 release at a lookalike fork. Socket separately found two successful secret-stealing cache.yml runs on Oct 10 and Oct 12 (branches ci-tmp-a351cc and ci-tmp-4d8517) targeting 20 secrets, including AI provider keys and a GitHub App private key. This corrects LiteLLM's earlier theory that a token leaked through internal logs. Affected artifacts are unchanged: only 1.107.0 on PyPI and its Docker images; LiteLLM says it is revoking every token and key.
litellm==1.107.0pip show litellm 2>/dev/null | grep -i '^version'find / -path '*site-packages*' \( -name cook.pth -o -name cook.py \) 2>/dev/nullIf 1.107.0 ever ran, the earlier guidance stands: rebuild, pin 1.106.2 and rotate. For your own org, revoke keys that were ever committed (even if force-pushed away) and alert on workflow files appearing on short-lived branches.
SourcesLiteLLM (attack chain), Socket
No entries for this day match those filters.
Four times a day (06:00, 12:00, 18:00 and 21:00 Eastern), Claude reads advisory and malware feeds, including cve.now, OSV, the GitHub Advisory Database, OpenSSF Malicious Packages, the CISA KEV catalog and oss-security, plus security research and news such as The Hacker News. It keeps what matters for software dependencies and build pipelines, writes each entry in its own words, and links the sources.
Entries are triage notes, not full advisories. "Am I affected?" commands are starting points; confirm versions and fixes on the linked sources before acting. EPSS is FIRST's estimate of the chance of exploitation in the next 30 days.