Security incidents and advisories

1. OpenCode says a breach hit 1.4 percent of Console users who had linked an Anthropic, OpenAI or Google account

   18 Oct

   On 18 October OpenCode, the open source AI coding agent, posted on X: "We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users. We have notified them all this morning via email. The incident is ongoing so we cannot share more details at this point but we are working with Anthropic, OpenAI, and Google to remediate." StepSecurity, which reproduced the statement, says the affected users are those with external AI providers linked, that OpenCode has not published a root cause, the data accessed or the affected versions, and that, according to the vendor, anyone who did not get an email was not affected.

   So what

   If anyone on your team uses OpenCode with a linked provider, rotate those keys today, not after the root cause is published. Check for the OpenCode email first, including spam, then list what each machine has linked: StepSecurity gives ~/.local/share/opencode/auth.json on macOS and Linux and %USERPROFILE%\.local\share\opencode\auth.json on Windows, and every provider in that file is a credential worth rotating. Then open each provider's usage dashboard and look for requests nobody on the team made, because unexpected spend is how misuse of a stolen key shows up. The installed version does not tell you whether you were affected, since the scope is Console accounts with linked providers.

   Source: StepSecurity, OpenCode security breachIssue 7 · Week of 19 October 2026

2. An npm Trusted Publishing flaw let anyone who claimed a freed GitHub repository name publish as the owner, across more than 1,500 packages

   13 Oct

   Help Net Security reports research from Bloom Security showing that npm Trusted Publishing recorded the repository allowed to publish a package by its name, owner and repo, and did not check the permanent numeric IDs GitHub puts in the identity token. When a maintainer renamed, transferred or deleted the repository, or renamed or deleted the owner account, the name became free: anyone could create a repository at that name with a workflow file of the matching filename and receive a publish credential for a package they did not own. Bloom counted more than 1,500 packages exposed, with more than 10 million downloads in total, is not publishing their names, and says it is unknown whether anyone exploited the flaw. GitHub announced on 2 October that unvalidated Trusted Publishing configurations now expire 48 hours after creation and cannot authorise publishing, and that a configuration is validated by its first successful publish. GitHub's statement does not say whether configurations that had already published were bound retroactively. Bloom says the GitLab integration has the same weakness.

   So what

   Maintainers: open the trusted publisher settings of every package you publish this way and look for a repository you have since renamed, transferred or deleted. Remove that binding and recreate it from the current repository so the first publish validates it, and in future remove the binding before you rename, transfer or delete a repository. Consumers: Help Net Security notes that a release published through the flaw carries a valid provenance attestation naming the attacker's repository, so the check that works is that the attestation names the repository the project is supposed to come from. GitHub also now rejects trusted publishing tokens from issue_comment events, so move any publish job that runs on a comment to push, release or workflow_dispatch.

   Source: Help Net Security, npm Trusted Publishing flawIssue 7 · Week of 19 October 2026

3. GitHub secret scanning now blocks Anthropic API keys by default, including on free public repositories

   13 Oct

   On 13 October GitHub added secret scanning detectors for two Anthropic key types, anthropic_service_api_key and anthropic_user_api_key, plus a Cloudsmith key, and made push protection block both Anthropic types by default. The changelog says repositories with secret scanning enabled, including free public repositories, will have commits containing them automatically blocked. User secrets raise alerts in public or private repositories, while partner secrets such as the new Salesforce Marketing Cloud OAuth2 token are reported to the issuer when found in public repositories so it can revoke or rotate them.

   So what

   Check that secret scanning and push protection are switched on for your private repositories too, because the default only applies where secret scanning is enabled. Then treat the block as a seatbelt and not a scan: it stops a key at push, and it does not touch a key already in your history, a build log or a pasted ticket. Run a history scan once, and rotate any Anthropic key that has ever been committed, whether or not GitHub alerted you.

   Source: GitHub, secret scanning blocks Anthropic keys by defaultIssue 7 · Week of 19 October 2026

4. The postponed Next.js fixes landed on 14 October: two critical remote code execution flaws, in 16.4.1 and 15.5.28

   14 Oct

   Vercel published the out of band Next.js security update on 14 October, as 16.4.1 on Active LTS and 15.5.28 on Maintenance LTS. It fixes three upstream vulnerabilities, two critical and one high, and the pre-announcement said two of the fixes were postponed from the September security release. The first critical flaw, GHSA-673q-mjm6-r5xr, is unauthenticated remote code execution in applications using App Router with Cache Components when a use cache function returns multiple typed arrays, and the post says "There is no known workaround for affected applications." The second, CVE-2026-96889 / GHSA-2464-fhr4-w9xw, is remote code execution in the Image Optimization API when using SVG, which the post scopes to Next.js running on glibc based Linux and gives a workaround for: sharp 0.35.5 or later. The high severity flaw, GHSA-p3m5-59mp-jv5r, is a denial of service in App Router applications with at least one Server Action, and the post says applications using Pages Router or no Server Actions are not vulnerable. The post names only 16.4.1 and 15.5.28, and npm lists no 16.3 release after 16.3.8.

   So what

   Upgrade today: next@16.4.1 on the 16.x line and next@15.5.28 on 15.5. If you are on 16.3, the post does not name a patched 16.3 release and npm has none, so the move is to 16.4.1. For the use cache flaw the post says to upgrade immediately even if your application has no similar functions, so do not spend time deciding whether you are exposed. If the image flaw is the one you can reach first, check that sharp resolves to 0.35.5 or later in your lockfile, and do not assume the upgrade does it for you: the package metadata for next@15.5.28 accepts sharp ^0.34.3 || ^0.35.5, so an existing lockfile pinned at 0.34.x can stay there, while 16.4.1 requires ^0.35.5. Also check which libc your container image uses, because the post limits that flaw to glibc based Linux. Then redeploy preview and branch deployments, which keep serving the build they were created from. Affected version ranges are not in the post, and the advisories it links carry them, so take the ranges from there.

   Source: Next.js, security update for upstream vulnerabilitiesIssue 6 · Week of 12 October 2026

5. The compromised tensorlake 0.5.144 package is built to delete your home directory if you revoke the GitHub token it stole

   8 Oct

   StepSecurity reports that tensorlake 0.5.144 on npm steals credentials at install time, tries to spread to other packages and repositories, and sets a trap. The first malicious commit reached the main branch of tensorlakeai/tensorlake at 01:20 UTC on 7 October under a maintainer name, seven more followed without pull requests, and the repository release workflow published 0.5.144 at 01:12 UTC on 8 October. Because it was built from the repository, the release carries a valid npm provenance attestation, and StepSecurity notes "It doesn't say the code is safe." A preinstall hook runs setup.mjs, which skips CI, fetches the Bun runtime and runs an obfuscated 856 KB payload that collects GitHub and npm tokens, cloud keys, Kubernetes and Vault secrets, SSH keys, saved browser logins and configuration for AI tools including Claude, Cursor and Windsurf. If it holds a GitHub token it installs a service called gh-token-monitor, which checks the token every 60 seconds for up to 24 hours and runs rm -rf ~/ if GitHub rejects it. It also writes .claude/settings.json and .vscode/tasks.json into repositories it can reach. npm no longer lists version 0.5.144.

   So what

   If 0.5.144 was ever installed on a machine, do not revoke the GitHub token first. StepSecurity says to back up anything you cannot lose, remove the monitor, which lives under ~/.config/gh-token-monitor/, and only then rotate every credential that machine could reach: GitHub and npm tokens, cloud and SSH keys, Kubernetes and Vault credentials, .env secrets and AI tool keys. Then check for spread: new public repositories with the description "Shai-Hulud: Here We Go Again", commits from claude@users.noreply.github.com, and .claude or .vscode files you did not add. Check lockfiles with npm ls tensorlake, and note that StepSecurity suggests pinning 0.5.143. The wider lesson is that a provenance attestation and a green release workflow are not evidence of safety, so set ignore-scripts=true in .npmrc, which stops install hooks like this one.

   Source: StepSecurity, tensorlake compromise analysisIssue 6 · Week of 12 October 2026

6. CISA put five old flaws on its exploited list in one day, including Strapi, and the newest is from 2023

   8 Oct

   CISA added five vulnerabilities to its Known Exploited Vulnerabilities catalogue on 8 October: ISC BIND CVE-2015-5477, Apache Struts CVE-2016-3081, ProFTPD CVE-2015-3306, ONLYOFFICE Docs CVE-2021-3199 and Strapi CVE-2023-22894. The Strapi entry describes cleartext storage of sensitive information that lets attackers with access to the admin panel discover sensitive user details through the query filter, notes that the product could be end of life, advises users to "discontinue use and/or transition to a supported version", and says it can be chained with CVE-2023-22621 to achieve remote code execution. The ONLYOFFICE Docs entry describes a path traversal when JWT is used, via a /.. sequence in an image upload parameter, that could allow remote code execution. Later in the week the catalogue gained Ivanti Connect Secure and a Windows Shell flaw on 13 October, then Cisco Secure Email Gateway, two chained Ahsay AhsayCBS flaws and Palo Alto PAN-OS on 14 October.

   So what

   The pattern matters more than any one entry: flaws from 2015 to 2023 are being exploited today, which means attackers are working through software that never got patched rather than hunting new bugs. If you self host Strapi, check your version against the vendor advisory and move to a supported release, because the catalogue entry itself says the product may be end of life and the chain with CVE-2023-22621 reaches code execution. Do the same for anything you run on a long lived server, such as ONLYOFFICE Docs, an FTP daemon or an old DNS resolver. A dependency scanner will not catch a service that sits outside your lockfile, so list what you run on servers as well as what you import.

   Source: CISA, Known Exploited Vulnerabilities catalogueIssue 6 · Week of 12 October 2026

7. GitHub now blocks Anthropic API keys on push by default, for every repository with secret scanning on, including free public ones

   13 Oct

   GitHub announced on 13 October that secret scanning detects two new Anthropic secret types, anthropic_service_api_key and anthropic_user_api_key, and that both are included in push protection by default. The changelog says repositories with secret scanning enabled, "including free public repositories", will have commits containing these secrets automatically blocked. It also adds Salesforce as a secret scanning partner with the type salesforce_marketing_cloud_api_oauth2_token, and a Cloudsmith detector, cloudsmith_api_key. Under the partner program, secrets found in public repositories are reported to the issuer so it can revoke or rotate them.

   So what

   A blocked push is a good failure, but it only protects repositories where secret scanning is on, so check that setting on everything you own rather than assuming a default. Tell your team what the error means before it appears in a deploy, because scripts and CI jobs that commit generated files will hit it first. The block applies to new pushes, so a key that is already in your history needs to be found and rotated by you. Better still, keep Anthropic keys out of client code and committed .env files in the first place.

   Source: GitHub, changelogIssue 6 · Week of 12 October 2026

8. The Next.js security release is 16.3.8, not 16.3.7, and 15.5.27 does not fix the same things

   30 Sep

   Vercel published 16.3.7 on 29 September. Its release notes say it is "backporting bug fixes" and list one change to the Turbopack backend, with no security content. The security release followed on 30 September: "Updates are now available in v16.3.8 (Active LTS) and v15.5.27 (Maintenance LTS)". The pre-announcement carries two dated notes, one saying 16.3.7 "does not include the security fixes planned for September 30", and one saying the release "now addresses seven vulnerabilities instead of nine. The remaining two (one critical, one high) are pending upstream coordination". The headline fix is CVE-2026-94483, server-side request forgery in Image Optimization, rated high at CVSS 8.3. The release notes for 15.5.27 list only three of the seven, so the 15.5 line does not get the SSRF fix.

   So what

   Upgrade to 16.3.8 on the 16.x line, and note that stopping at 16.3.7 leaves you unpatched. On the SSRF, the blog says plainly that if no images.remotePatterns are configured your application is not affected, so check that first and only audit allow-listed hosts if it is populated. Read the per-issue scoping rather than assuming: one cache poisoning item says applications deployed on Vercel are not affected, one affects only next dev, and one does not affect Turbopack builds. None of that is a blanket exemption. Then keep watching, because one critical and one high are still unfixed as of today, with no CVE, no version and no date published.

   Source: Next.js, September 2026 security releaseIssue 5 · Week of 28 September 2026

9. A critical LiteLLM flaw lets an ordinary user become proxy admin and run commands

   30 Sep

   LiteLLM published three advisories. The critical one, GHSA-7hp6-4w63-5g45 at CVSS 9.9, says "An authenticated user with internal_user privileges can escalate to proxy_admin and achieve remote code execution." The root cause is that "The proxy uses one encryption key for two purposes: sealing secrets at rest and minting session tokens", so a user can have the proxy encrypt forged admin metadata and present it back as a bearer token. Patched in 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0rc2. A high severity issue published 1 October, GHSA-g5ff-637f-6q2m at CVSS 8.1, lets an authenticated user read arbitrary local files through a vertex_ai_credentials alias the blocklist missed, fixed in 1.95.0, and the advisory says "There is no reliable configuration workaround on affected versions." A moderate reflected XSS in the SSO debug callback is fixed in 1.85.0. None has a CVE assigned.

   So what

   Upgrade to the highest patched release on your line, then rotate. Both the critical and the high end in exposure of LITELLM_MASTER_KEY and the provider API keys the proxy holds, so after upgrading change the master key, rotate every upstream provider key, and reissue virtual keys. If you cannot upgrade today the advisory offers EXPERIMENTAL_UI_LOGIN=false, but it says that also breaks CLI SSO and Claude Code gateway login, so do not flip it blind. One range detail worth checking: 1.87.0 through 1.90.x is exploitable only if that flag was explicitly set to true, so a version below 1.91.0 is not automatically safe.

   Source: LiteLLM, security advisoriesIssue 5 · Week of 28 September 2026

10. Two Zammad flaws are being actively exploited, with a KEV deadline of 5 October

    2 Oct

    CISA added CVE-2026-102489 and CVE-2026-102490 to its Known Exploited Vulnerabilities catalogue on 2 October with a remediation deadline of 5 October. The first is a session fixation issue that "can lead to remote code execution as the zammad user", the second an improper privilege management issue that "can allow the local zammad user to escalate privileges to root", and CISA notes each can be chained with the other. The Dutch security organisation DIVD says its own systems were reached on 21 September through the pair, in its words allowing "session hijacking, remote code execution and privilege escalation from the Zammad user to root, in seconds". DIVD gives the remotely exploitable range as Zammad 6.3.0 to 6.5.4, and Zammad staff on the project forum say exploitation is only possible on 6.5 and older and that 7.0 and later are not affected by the remote execution issue.

    So what

    If you self-host Zammad for your support desk, update to 7.2.0 now. The 6.3.0 to 6.5.4 band is the remotely exploitable one, and 7.0 to 7.1.3 still carries the root escalation. DIVD publishes a log check script for its indicators of compromise, so run that before you assume you are clean. If anything matches, rotate what the Zammad host could reach rather than just the application: database credentials, SMTP and API keys in its environment, and any SSH or cloud credentials on that box. Note that neither CVE has a GitHub Security Advisory yet, so a dependency scanner will not catch this for you.

    Source: CISA, Known Exploited Vulnerabilities catalogueIssue 5 · Week of 28 September 2026

11. UpGuard says it found 16,326 Supabase databases exposing readable tables, and blames how the projects were configured

    1 Oct

    Research from UpGuard dated 1 October says it "gathered ~300,000 unique domains with indicators of Supabase usage" and "identified 16,326 databases exposing readable tables", with "over half of the databases" showing indicators of some PII and a smaller share including passwords or authentication tokens. UpGuard attributes the exposure to application-side configuration rather than a product flaw, noting that "Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default", alongside policies that do not adequately restrict access and public keys used in client code as if they were secret. It credits Supabase with having "made product changes to implement RLS by default for tables created in the Table Editor UI". Supabase's chief information security officer Bil Harmer told TechCrunch the company provides "secure defaults and tooling, and customers control how their own projects are configured".

    So what

    The gap UpGuard identifies is specific and worth checking today: a table your coding agent created through the API does not get row level security by default, while one you created in the dashboard now does. Run a query over pg_class for every project and confirm relrowsecurity is true on every table in the public schema, then confirm each one actually has a policy, because RLS enabled with no policy and RLS disabled are very different states. Separately, grep your client bundles and mobile builds for a service_role key. The anon key is meant to be public. The service role key is not, and if it shipped, rotate it.

    Source: UpGuard, researchIssue 5 · Week of 28 September 2026

12. Next.js shipped an out-of-band 16.3.6 for a critical remote code execution flaw in next/og

    22 Sep

    On 22 September Vercel released Next.js 16.3.6 and 15.5.26 out of band. The advisory GHSA-vcvr-r3jv-pc5j is titled Remote Code Execution in next/og ImageResponse, carries CVE-2026-94545 at CVSS 9.5, and gives the affected range as 16.2.0 up to but not including 16.3.6. The entry point is an improper escaping bug in Satori, fixed in 0.33.5, which combined with flaws in other upstream dependencies could lead to code execution. The release post says version 15.5.26 includes related hardening but that Next.js 15.x is not affected by the remote code execution issue, and that applications using the Edge ImageResponse implementation are not affected.

    So what

    Upgrade if you are on any 16.2 or later build, then check whether an OG image route interpolates a slug, a search parameter or a username into SVG content, attributes or styles, because that is the exact precondition the advisory names. Applications that pass no attacker-controlled values into SVG are not affected. Preview and branch deployments keep serving the vulnerable build until you redeploy or delete them, which is the step most teams skip.

    Source: Next.js, security releaseIssue 4 · Week of 21 September 2026

13. Malicious npm and PyPI package versions shipped a Go implant that harvests developer credentials

    23 Sep

    OSV records MAL-2026-16476 and MAL-2026-16475, both published 23 September, describe malicious versions of the npm package memos-cloud-openclaw-plugin under the memtensor scope, at 0.1.21, 0.1.23 and 0.1.25, and of the PyPI package memoryos at 2.0.34. Both carry a Go implant called sckit that runs when the package loads. OSV says it targets .npmrc, .pypirc, .git-credentials, .netrc, SSH private keys, .vault-token and token caches, and collects credentials from the home directory and sends them to servers under skyleen[.]fr. In GitHub Actions it appends a BASH_ENV entry to GITHUB_ENV to capture PyPI publishing tokens. An open issue on the project repository, filed by an outside researcher, says the package's npm publish token appears to have been compromised. The maintainers have not publicly commented.

    So what

    If either package appears in a lockfile or in an agent's dependency tree, rotate npm and PyPI tokens, GitHub personal access tokens, SSH keys and any cloud credentials readable from that machine or runner, then check CI logs for outbound connections to skyleen[.]fr. The general lesson is the scope: a package install runs code as you, so what is at risk is every credential your home directory can read, not only the ones the package legitimately needs.

    Source: OSV, MAL-2026-16476Issue 4 · Week of 21 September 2026

14. Brevo says an attacker used a compromised Cloudflare API key to inject a script into customer-embedded files

    14 Sep

    Brevo published a post-mortem on a 14 September incident in which, in its words, an attacker used a compromised Brevo Cloudflare API key to deploy a Cloudflare Worker on its account. Brevo says the Worker injected a malicious script into pages of brevo.com and sibforms.com and into three JavaScript files that customers embed on their own websites, showing selected visitors a fake Cloudflare human verification page that told them to press Win+R and paste a command. It gives the impact window as 15:01 to 20:30 UTC, with the lure live on the listed customer URLs from 16:07. Brevo states that app.brevo.com was not affected and that no Brevo systems were modified at their source, the content being altered in transit at its CDN edge. The stated root cause is a long-lived Cloudflare API key with full account permissions stored in application source code.

    So what

    Brevo asks anyone who ran the pasted command to treat that computer as compromised, to check WordPress sites for a plugin installed on 14 September, and to change Brevo passwords and review API keys. The transferable part is the root cause rather than the vendor: search your own repositories for long-lived full-permission CDN and DNS tokens and replace them with scoped ones. A third-party script tag is a standing grant to run code on every visitor you have, and it is worth knowing how many of those grants you have issued.

    Source: Brevo, incident write-upIssue 4 · Week of 21 September 2026

15. Cloudflare disclosed a cross-tenant vulnerability in Containers, and asks customers to do nothing

    24 Sep

    On 24 September Cloudflare disclosed a vulnerability affecting Cloudflare Containers and Cloudflare Sandboxes, which is built on Containers. Cloudflare says it would potentially have allowed a customer with a Workers Paid account to recover residual data from storage blocks previously used by other customers' Containers on the same underlying host, potentially exposing filesystem metadata, directory structures, database pages and application data. Oren Yomtov of Accomplish reported it on 4 September, fixes finished rolling out on 7 September, and cleanup of affected cached snapshots completed on 19 September. Cloudflare says it has no evidence that customer data has been compromised, and that remediation does not require any further action by Cloudflare customers.

    So what

    There is genuinely nothing to do, which is the interesting part. What is worth filing is the shape of the risk: Containers and Sandboxes are multi-tenant and you do not choose the host, so whatever you write to a container disk sits on shared storage. Keep secrets in bindings rather than on disk, treat a container filesystem as scratch space, and note that Workers itself is not what was affected here.

    Source: Cloudflare, blogIssue 4 · Week of 21 September 2026

16. An operator scanned 1.8 million Android apps for hardcoded secrets, Anthropic's threat report says

    10 Sep

    Anthropic's September threat intelligence report, covering December 2025 to August 2026, describes a suspected ShinyHunters affiliate who ran a pipeline on 10 AWS EC2 workers that downloaded 1.8 million Android APKs, decompiled them and scanned them for hardcoded secrets with TruffleHog. Anthropic says that pipeline and a separate GitHub token harvester supplied the initial-access credentials for most of the confirmed breaches tied to that operator, and that it banned accounts linked to the group, which used Claude to speed up its operations.

    So what

    Treat anything compiled into a shipped mobile app or a browser bundle as public, because finding it is now a cheap automated job. Scan your built APK, IPA and JavaScript output, not only your repository, for Supabase service_role keys, Stripe secret keys, LLM API keys and cloud credentials. Separately, F5 Labs reported a surge in scanning of exposed Vite dev servers for .env files in August: patch Vite to 7.3.2 or 8.0.5 and never bind a dev server to a public interface.

    Source: Anthropic, threat intelligence reportIssue 3 · Week of 14 September 2026

17. Brevo SSO flaw let an attacker into 138 customer accounts and send phishing that passed email authentication

    10 Sep

    Brevo's incident write-up says an attacker exploited how it handled SAML SSO to reach 138 customer accounts. Brevo identified the issue at 06:30 UTC on 10 September and at 08:30 UTC closed the route and signed out every user on the platform. It says six accounts were used to send phishing and contacts were exported from 43. Trezor, one affected customer, said about 347,000 phishing emails went to its subscribers from its own Brevo account.

    So what

    SPF, DKIM and DMARC all pass when the mail genuinely comes from your own hijacked sending account, so authentication records are no defence here. If you use Brevo, review team members, SSO settings, exports and sending logs for 9 and 10 September and rotate API keys. If you ship SAML SSO in your own product, test that an identity provider configuration can only ever grant access to the organisation that owns it.

    Source: Brevo, incident write-upIssue 3 · Week of 14 September 2026

18. The deadline to patch exploited LiteLLM and Starlette flaws passed on 16 September

    16 Sep

    CISA added two flaws common in AI backends to its Known Exploited Vulnerabilities catalogue on 2 September, with a federal remediation deadline of 16 September. CVE-2026-59822 lets an unauthenticated attacker open an MCP session in LiteLLM below 1.84.0 with a made-up Bearer token. CVE-2026-48710 lets a crafted Host header bypass path-based middleware checks in Starlette 1.0.0 and earlier.

    So what

    The deadline binds US federal agencies, but a listing in that catalogue means the flaw is being exploited in the wild, which is the part that matters to everyone else. Check every Python service and image: LiteLLM needs 1.84.0 or later and Starlette 1.0.1 or later, and FastAPI depends on Starlette, so FastAPI apps are in scope too. Then look for middleware that authorises on request.url.path.

    Source: CISA, KEV alertIssue 3 · Week of 14 September 2026

Other topics