This week at a glance
The story to carry out of this week is that Shai-Hulud has stopped being a campaign and become tooling. Three intrusions reported in the space of four days share the self-spreading worm lineage and share almost nothing else — different ecosystems, different entry points, different operators — and the temptation to collapse them into one continuing attack is the mistake to avoid. CrowdSec disclosed on 18 September that the May 2026 TanStack npm compromise — 84 malicious versions of 42 packages, tracked as CVE-2026-45321 — harvested a GitHub OAuth token from a then-employee’s laptop, and that on 22 May the attacker used it to copy 170 private repositories, leaving no trace in any log CrowdSec could read. Separately, Mandiant published an incident report in which an attacker took control of a developer’s live AI coding-assistant session, had the assistant recommend a poisoned PyPI package, stole GitHub OAuth tokens and deployed Shai-Hulud across roughly 100 internal repositories — entry via PyPI rather than npm, and Mandiant is explicit that the available evidence does not link this to the March 2026 or August 2026 npm worm activity, which it calls separate campaigns. And Socket’s threat research team traced PolinRider into Packagist, where four dev-branch versions of a Laravel Nova two-factor component with more than 700,000 cumulative downloads were poisoned by force-pushing rewritten Git history through a compromised developer account. One shared lesson runs through all three: the registry was downstream. The credential and the Git account were the objective.
The second thread is that the coding agent is now a component of the build chain with none of a build chain’s controls. Plugin4Shell, from Air Security, exploits the fact that Git will resolve a requested commit SHA as a branch or tag name: a repository owner creates a ref that looks like a hash, points it at different code, and the agent installs that code while reporting the pin matched. It affects Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI; a working proof-of-concept existed in May 2026 and vendors were told in June. As of 18 September — roughly three months later — Claude Code is fixed in 2.1.179 and Codex in 0.146.0, Copilot and Gemini CLI are not fixed, and no CVE has been assigned and no public vendor advisory issued. Underneath that sits the credential layer the agents run on: Hush Security located roughly 82,000 MCP configuration files in public GitHub repositories and found 12% of credential slots holding a hardcoded secret, of which 55% had no vendor-recognisable token format and 31% were opaque bearer tokens for internal MCP servers — which is to say pattern-based secret scanners would miss most of them. 53% granted organisation-, account-, workspace- or database-wide access, and of those with any expiration policy, 80% did not expire by default. In a sample of 7,681 credential-bearing configurations read back through seven revisions, 243 still held secrets in history that had been deleted from the current file.
The rest of the week divides between the surfaces we keep leaving exposed and the arithmetic of AI-assisted development. On the surfaces: F5 Labs observed mass scanning in August 2026 against CVE-2026-39364, a CVSS 8.2 flaw in the Vite dev server whose advisory landed in April — an HTTP GET to /@fs/ with ?raw appended defeats the server.fs.deny check and returns the file in plaintext, and the files being requested are .env configurations, AWS credential files, terraform.tfstate and Azure profiles. The exposed asset is a development server reachable from the internet, so the remediation is at least as much about what is listening as about the patch. On the arithmetic: GitClear’s analysis of 623 million code changes from 2023 to 2026 found block duplication up 81% against a 2023 baseline, from 40.3 to 73.0 instances per million changed lines, while “moved code” — its proxy for refactoring — fell from 21% of changed lines in 2022 to 3.8% in 2026. Read the comparisons carefully, because the headline welds three of them together. Meanwhile the institutions moved: an OpenSSF Governing Board commitment signed by twelve organisations put enterprise funding for package registries on the table against 1.8 million malicious packages flagged in 2026 and a projected 3-5x rise in publish events, and the Ninth Circuit — not a district court, whatever the headlines said — held that AI-generated code lacking copyright management information does not by itself violate DMCA §1202.
On our watch list
- Whether GitHub Copilot and Gemini CLI ship a Plugin4Shell fix, and whether anyone assigns a CVE. Disclosure was June 2026 and both were still unpatched on 18 September, with Gemini CLI being retired in favour of Antigravity — which raises the question of whether a retiring product gets fixed at all. No CVE and no public advisory means there is nothing for a scanner or a procurement questionnaire to key on.
- Whether the plugin-pinning fix lands in Git clients or only in the agents. GitHub already blocks branch and tag names that look like commit hashes, which is why plugins hosted there are harder to attack; plugins on other Git hosts have no such protection. Watching whether other hosts adopt the same restriction, or whether the agents start verifying that a resolved ref is genuinely an object ID.
- Whether Shai-Hulud tooling turns up in a fourth ecosystem. The lineage has now been seen operating through npm and, in the Mandiant intrusion, PyPI, while PolinRider has touched npm, PyPI, Go modules, Packagist and Chrome extensions. Watching which registry is next, and whether any of them can produce the publish-event telemetry to spot it early.
- Whether CrowdSec’s exposed consensus thresholds change anything downstream. The leak included the consensus algorithm and previously undisclosed thresholds used to build CrowdSec blocklists, which roughly 150,000 users consume. Watching for evidence of evasion tuned to those thresholds, and for whether CrowdSec publishes a rotation.
- Whether registries move to scoped, short-lived publish credentials. Every one of this week’s three intrusions turned on a long-lived token or account rather than a registry vulnerability, and the CrowdSec token use left no trace in logs the victim could access. Watching for publish tokens that expire by default and for org-level audit records the token holder cannot suppress.
- Whether secret scanners learn to read MCP configuration. Hush Security found 55% of the hardcoded secrets had no vendor-recognisable format and 31% were opaque bearer tokens for internal servers. Watching whether scanning vendors ship MCP-aware and entropy-based detection, and whether anyone starts scanning Git history rather than only the working tree — 243 of 7,681 sampled configurations had secrets that survived deletion.
- Whether F5 Labs or anyone else publishes an exposure count for Vite. The campaign is documented; the number of internet-reachable dev servers is not. Watching for a figure, and for the same query-parameter filter-bypass pattern being tried against other development servers, since the technique is about defeating a path-deny check rather than anything specific to Vite.
- Whether GitHub Actions’ cache-mode gets adopted or stays an option. A setting that limits cache poisoning only helps where it is turned on. Watching whether it becomes a default for new workflows, and whether organisations start requiring it in their reusable workflow templates.
- Whether the OpenSSF registry commitment produces money. The statement names no funding amounts. Signatories anticipate a 3-5x increase in publish events, partly from AI-discovered vulnerabilities generating more patch releases, against 1.8 million malicious packages flagged this year. Watching for the first enterprise-tier pricing announcement from any of the named registries, and whether free access for individuals survives it.
- Whether the core copyright claims in Doe v. GitHub now move. The Ninth Circuit decided the DMCA §1202 question only; it did not decide whether training on open-source code infringes, whether that is fair use, or whether matching output infringes. Those claims remain before the district court. Watching the district-court schedule, and resisting the reading that the case is over.
- Whether GitClear’s next edition separates its comparisons. The 25% output gain is heavy AI users against their own prior velocity; the 4-10x is against non-AI users; the 81% duplication rise is dataset-wide against a 2023 baseline. Watching whether the next report reports them apart, and whether the “moved code” proxy for refactoring gets defended against the methodology criticism it drew in 2024 and 2025.
This week’s topic map — the supply-chain spine through the centre joining registry and Git-account compromise, the Shai-Hulud worm, npm, PyPI, GitHub, stolen OAuth tokens and source and secret theft; the CrowdSec cluster to its left with TanStack and CVE-2026-45321; the PolinRider cluster at the lower left with Socket, Karlo Zanki, Packagist, Composer dev branches, force-pushed history, EtherHiding drops and North Korea; the agent cluster on the right around AI coding agents, Plugin4Shell, Air Security, commit-SHA pinning, Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI; the credential cluster around the Model Context Protocol, Hush Security, hardcoded credentials and secret-scanning gaps; the dev-surface cluster at the lower right joining the Vite dev server, CVE-2026-39364, F5 Labs, exposed dev servers, cloud credential theft, AWS and Terraform state; the pipeline group around the CI/CD attack surface, GitHub Actions, cache poisoning, buildpacks, container controls and pipeline consolidation; the commons cluster around OpenSSF, registry sustainability, Maven Central, crates.io, malicious packages, AWS OSS credits, the EU Cyber Resilience Act and CRA readiness; the litigation cluster at the top with Doe v. GitHub, the Ninth Circuit, DMCA §1202, open source licensing risk, the Software Freedom Conservancy and Bruce Perens; and the AI-coding-effects cluster at the upper right around AI productivity, GitClear, code duplication, refactoring collapse, AI reliance, review and comprehension, requirements-first working and software factories.
View interactive topic map →
Article index
The worm lineage: three intrusions, one toolset
Distinct operators, distinct ecosystems, shared self-spreading tooling. In all three the package registry was downstream of a stolen credential or a compromised Git account — not the objective, the delivery mechanism.
The coding agent is now part of the build chain
Pinned plugins, live agent sessions and MCP configuration files all inherit developer privilege without inheriting developer review. Two of the four agents affected by Plugin4Shell were still unpatched three months after disclosure, and there is no CVE to track it by.
The exposed dev surface, and the controls that run on the pipeline
A development server was never meant to be a production-facing surface, and a CI/CD pipeline holds more privilege than most of the systems it deploys to. The constructive half of this group is about where security controls actually live — in the build, not in a scan afterwards.
Who funds the registries, and who governs the commons
The institutional layer moved on three fronts at once this week: enterprise funding for the package registries everybody depends on, a readiness path for the EU Cyber Resilience Act, and an appellate ruling that narrows one legal theory open source developers had been counting on.
What AI-assisted coding is doing to the codebase
Output is up and the measurements of what that output costs are getting better. The useful move this week is away from velocity metrics and towards duplication, comprehension and what a human is actually still the gate on.
| Article |
Source |
Published |
| 16. Your AI coding spend bought 25% more output. Duplication rose 81%. |
The New Stack
Author is employed by a CI/CD vendor; research is GitClear’s |
Sep 14, 2026 |
| 17. Study: Developers are addicted to AI, and managers are making it worse |
The New Stack
Coddy survey; n just over 300, self-selected |
Sep 17, 2026 |
| 18. Why human oversight is shifting from writing code to defining requirements |
The New Stack |
Sep 17, 2026 |
| 19. Software Factories, Light and Dark |
O’Reilly Radar |
Sep 18, 2026 |
| 20. Inside OpenAI’s Agentic Software Factory |
The Pragmatic Engineer |
Sep 15, 2026 |
| 21. Migrating the GitHub Copilot runtime to Rust, using Copilot |
The GitHub Blog
Vendor engineering blog |
Sep 17, 2026 |
Detailed write-ups
1. CrowdSec: a laptop compromised in May, 170 private repositories copied eleven days later
The Hacker News · September 19, 2026
This is the cleanest published account this year of what a stolen developer credential is actually worth, and the timeline is the part to read closely. On 11 May 2026, 84 malicious versions of 42 TanStack npm packages were published — the compromise tracked as CVE-2026-45321 — and those versions harvested credentials from developer machines: GitHub tokens, SSH keys, cloud credentials. One of the machines belonged to a CrowdSec employee, later a former employee. The attacker took a GitHub OAuth token from that account, and on 22 May used it to copy 170 private CrowdSec repositories. The account was removed from the CrowdSec GitHub organisation on 25 May — three days after the copy, which is a perfectly respectable offboarding interval and made no difference whatsoever. Critically, the token use left no trace in any log CrowdSec could access. The company learned what had happened when the archive surfaced on an online forum on 16 September, nearly four months later, and published its report on 18 September.
What was in the archive matters as much as how it left. Alongside web console code, data-science scripts and models and automation scripts sat the consensus algorithm CrowdSec uses to build its blocklists, including previously undisclosed thresholds — for a company whose product is a community-sourced blocklist consumed by roughly 150,000 users, that is the detection logic itself, not incidental source. The personal data is the other half: 83 user email addresses and 51 investor names, emails and investment context dating back to 2020. CEO Philippe Humeau took that one personally and said so: “for this I personally apologize.” The credential exposure, by contrast, held up better than most organisations should expect — the only usable credential in the dump was an AWS SNS token scoped to publishing to a single topic, and an unauthorised attempt to use it was observed on 17 August. Narrow scoping is the control that worked here, and it worked because somebody had already done it.
Two things not to over-read. First, the reporting ties the laptop compromise to the TanStack npm attack, and that campaign sits in the same npm worm lineage as the Shai-Hulud activity elsewhere in this issue, but it is not the same incident and nobody has claimed it is. Second, the 170 repositories were copied, not published — this is an exfiltration, not a leak site. The same TanStack wave is reported to have touched Mistral AI and two OpenAI employee devices, which is the useful scale signal: one poisoned dependency wave reaching across organisations that have nothing to do with each other, because they all run npm install on developer laptops that hold organisation-wide tokens.
The operational lesson is about detection surface, not about npm. A stolen OAuth token used against your own organisation produced no evidence you could see, and the gap between the copy and the discovery was four months and depended on a third party posting the archive publicly. If your GitHub organisation cannot answer “which repositories did this identity read last month,” you are in the same position CrowdSec was. Audit-log retention at the organisation tier, short-lived and scoped tokens, and treating a departing employee’s credentials as compromised rather than merely revoked are the three controls this incident argues for.
Sources: https://thehackernews.com/2026/09/crowdsec-says-tanstack-npm-attack-led.html
2. Mandiant: the attacker took the agent session, and the agent recommended the poisoned package
The Hacker News · September 16, 2026
This is the first widely reported intrusion in which a live AI coding-assistant session is the initial foothold rather than an incidental detail, and the chain is worth memorising in order. The attacker gained control of a developer’s running assistant session. The assistant then recommended a poisoned package, and the recommendation was accepted. An infostealer was installed through a poisoned PyPI package using the developer’s active session. GitHub OAuth tokens were stolen. And the self-spreading Shai-Hulud worm was deployed across roughly 100 internal repositories. The attacker then poisoned a package inside the company’s own official namespace, and a second employee pulled the compromised version — a secondary infection generated entirely inside the organisation, from its own trusted registry path.
The research is a Mandiant (Google Cloud Security) incident report, and Mandiant has withheld a great deal: the victim is an unnamed SaaS provider, the intrusion date is not given, and neither the AI coding assistant product nor the poisoned PyPI package name nor any download counts are disclosed. Those gaps are worth respecting rather than filling. Claude Code and Visual Studio Code appear in the reporting as context for how agent sessions work, not as the compromised product, and no published evidence names which assistant was involved. What Mandiant does say plainly is what was taken: “stole repository secrets and source code for the company’s products.”
The detail that changes the threat model is the ecosystem. Shai-Hulud is known from npm; here the entry was PyPI. That is tooling being retargeted, and it is the reason to stop treating this lineage as a single ongoing campaign. Mandiant is unusually explicit on the point: it describes the August 2026 Keyv-linked npm worm campaign and the March 2026 activity as separate campaigns, and states that the available evidence does not link them to this intrusion. Three operators, one worm, several registries — that is the correct shape of the problem, and it means ecosystem-specific defences will keep arriving one ecosystem late.
For anyone running coding agents in production, the actionable reading is that the agent session is a privileged execution context with a recommendation channel attached. It can install software, it holds whatever the developer holds, and a compromise of it converts directly into a supply-chain foothold in your own namespace. Treat an agent session like a shell with an opinion: scope its credentials separately from the developer’s, require human confirmation for any dependency addition regardless of who suggested it, and make publishing to your own internal namespace a gated action rather than an authenticated one.
Sources: https://thehackernews.com/2026/09/attacker-hijacks-ai-coding-assistant.html
3. PolinRider: the registry entry was never the target, the Git account was
Socket · September 17, 2026
Research by Karlo Zanki of the Socket threat research team, building on the team’s July 2026 work on the same operators, and the central case is specific enough to act on. The package is visanduma/nova-two-factor on Packagist — a Laravel Nova two-factor-authentication component with more than 700,000 cumulative downloads. Four versions were poisoned, and all four are branch-tracking: dev-nova4support, dev-main, dev-using-inertia and dev-nova5. That is the whole mechanism in one line. Composer’s dev-branch resolution means a consumer tracks a moving Git ref rather than an immutable release, so rewriting history changes what everybody installs, retroactively, with no new version number to notice.
The entry point was the compromise of the developer GitHub account LaHiRu inside the Visanduma GitHub organisation, identified in mid-June 2026. From there the sequence is: compromise a developer’s Git account; force-push rewritten history to insert the malicious code; conceal payloads in configuration files or in .woff2 font files; trigger execution on build, or simply on opening the folder in an IDE; fetch staged payloads through dead-drop resolvers — EtherHiding and NullReceiver — and pull later-stage infostealers from command-and-control. Socket attributes the operators as North Korea-linked, and notes the campaign has touched npm, PyPI, Go modules, Packagist and Chrome extensions. How many accounts were compromised beyond LaHiRu is not established, because much of the activity took place in private repositories.
Zanki’s framing is the sentence to take into an architecture review: “Package-registry compromise is often a consequence of a broader Git-based intrusion rather than the campaign’s primary objective.” Read alongside the CrowdSec and Mandiant incidents above, that is three for three this week — the registry was the distribution channel, and the credential or the account was the target. Defences aimed at the registry catch the last step of a chain that started somewhere you were not watching.
The concrete control here is dependency resolution policy, and it is unglamorous. If your composer.json resolves any dependency to a dev branch, you have no immutability guarantee at all — pin to released versions, commit a lock file, and verify it in CI rather than regenerating it. The execution-on-IDE-open detail deserves its own note: a developer does not have to run a build to be compromised, which makes “only open untrusted repositories in a container” a real control rather than a nicety. And the .woff2 payload trick is a reminder that font and asset files are executable content in a build context and belong in whatever scanning you already run over source.
Sources: https://socket.dev/blog/polinrider-github-packagist
4. Plugin4Shell: the pin says it matched, and it did not
The Hacker News · September 18, 2026
Research by Air Security, and the underlying fact is a property of Git that has been true for years: Git can resolve a requested commit SHA as a branch or tag name. A repository owner creates a branch or tag whose name looks like a commit hash and points it at different code. An AI coding agent asked to install a plugin at that pinned SHA fetches and installs that code, and reports that the pinned version matched. The swapped plugin then runs with the same privileges as the user running the agent. Pinning, in other words, has been providing the appearance of immutability without the guarantee — and pinning is exactly the control most teams adopted to make agent plugins safe.
Four agents are affected: Anthropic Claude Code, OpenAI Codex, GitHub Copilot and Google Gemini CLI. A working proof-of-concept was built in May 2026 and disclosed to vendors in June 2026. As of publication on 18 September the fix status is: Claude Code fixed in 2.1.179 and later; Codex fixed in 0.146.0 and later; GitHub Copilot unpatched; Gemini CLI unpatched and being retired in favour of Antigravity. No CVE identifier had been assigned and no public vendor advisories had been issued — roughly three months after disclosure. That last point is the one with programme consequences: with no CVE, this does not appear in a vulnerability feed, does not trip a scanner, and cannot be asked about in a supplier questionnaire by identifier. You have to track it by hand.
There is a partial mitigation, and it comes from an unexpected direction. GitHub itself blocks branch and tag names that look like commit hashes, so plugins hosted on GitHub are materially harder to exploit. Plugins hosted anywhere else get no such protection. That is worth stating evenly: the platform whose own agent is currently unpatched is also the platform whose naming restriction blunts the attack for everything hosted on it. The practical read is that your exposure depends less on which agent you run than on where the plugins it installs are hosted.
Do three things this week. Establish which agents your engineers run and get Claude Code to 2.1.179+ and Codex to 0.146.0+. For Copilot and Gemini CLI, inventory the plugins in use and restrict installation to GitHub-hosted sources until a fix ships. And treat a version pin in any agent configuration as an unverified claim until the agent can demonstrate the resolved ref was an object ID rather than a name — the same scepticism you would apply to an unsigned artifact whose manifest asserts its own integrity.
Sources: https://thehackernews.com/2026/09/plugin4shell-lets-repository-owners.html
5. 82,000 MCP config files, and the secrets in them are the kind your scanner cannot see
Help Net Security · September 18, 2026
The research is Hush Security’s report The State of MCP Configuration: The Identity Security Gaps, written up by Anamarija Pogorelec at Help Net Security, and the attribution matters because the headline conclusion doubles as the vendor’s thesis. With that said, the methodology is disclosed and the numbers are specific. Hush located roughly 82,000 MCP configuration files in public GitHub repositories by searching known MCP config filenames, and found that 12% of credential slots in those files held a hardcoded secret — predominantly vendor API keys, bearer tokens and database passwords. Note the denominator: that is 12% of credential slots, not of files and not of repositories.
The finding with the most operational bite is about detectability rather than volume. 55% of the secrets had no vendor-recognisable token format, and 31% were opaque bearer tokens for internal MCP servers. Conventional secret scanning works by pattern-matching known provider formats — an AWS key looks like an AWS key — which means the majority of what is sitting in these files is invisible to the tooling most organisations already believe covers this. Hush used provider-specific patterns plus Shannon entropy to find them, which is the technique difference in one line. Micha Rave, Hush’s CEO, puts the argument this way: “The instinct every security team has trained for years – to scan for secrets, block the commit, and rotate what leaked – isn’t nearly enough here.” That is a product pitch and also, on these numbers, true.
Blast radius is the third column of the report and the one to quote in a risk conversation. 53% of the exposed credentials granted organisation-, account-, workspace- or database-wide access. 24% were broad-scope and non-expiring by design. Of the credentials that had an expiration policy at all, 80% did not expire by default. And the history finding closes the loop on remediation: in a sample of 7,681 credential-bearing configurations examined back up to seven revisions, 243 contained secrets that had been deleted from the current file but remained in Git history — deleted, therefore assumed handled, therefore never rotated.
The authors are careful about limits and so should we be: forks were excluded and GitHub search limits apply, so these are explicitly treated as lower bounds; no credential was tested against a live service, and raw secret values were not retained. None of that softens the conclusion. If your organisation has adopted MCP servers in the last year — and most engineering organisations have, often without a decision being taken — then the config files describing them are a credential store that nobody designated as one. Inventory them, move the credentials into whatever secret manager you already run, scope them to something narrower than the workspace, and scan history rather than the working tree.
Sources: https://www.helpnetsecurity.com/2026/09/18/hush-security-mcp-credential-exposure-report/
6. The Vite dev server was never supposed to be on the internet, and it is being scanned at volume
The Hacker News · September 15, 2026
CVE-2026-39364 is a CVSS 8.2 flaw in the Vite development server, disclosed through a Vite GitHub security advisory in April 2026. The mechanism is a filter bypass and it is trivially simple: an HTTP GET to the /@fs/ endpoint referencing a sensitive file path, with ?raw, ?import&raw or ?import&url&inline appended. The query-parameter suffix defeats the server.fs.deny check, and the file body comes back in plaintext. Three preconditions have to hold together: the dev server is exposed with --host or server.host; the target file sits under a server.fs.allow directory; and the file matches a server.fs.deny pattern. That last one is the unpleasant part — the protection list is the target list.
F5 Labs observed the mass-scanning campaign in August 2026, roughly four months after the advisory. Scanner traffic originated largely from Google Cloud Platform ranges (34.x and 35.x), with additional sources in the United States, Belgium, the Netherlands, Singapore and Taiwan. The files being requested tell you exactly what this is for: .env configurations, AWS credential and config files, AWS backups, terraform.tfstate, serverless.yml, Azure profiles, plus /etc/passwd and /proc paths for good measure. This is credential harvesting at scale against development infrastructure, and no threat actor attribution has been made — “mass-scanning campaign” here means opportunistic scanning, not a named crew.
Two numbers are missing from the reporting and should not be invented: the affected and fixed Vite version numbers are not given, and there is no count of exposed servers. Check your own versions against the Vite advisory rather than against a figure in a news article. What the reporting does establish is the shape of the exposure, and the shape is the story: a development-time tool reachable from the internet. A dev server is designed to read arbitrary files off the developer’s disk on request, because that is what a dev server is for. There is no configuration of it that is safe to expose.
So the remediation is two-sided and the second half is the durable one. Patch Vite, yes. But also go and find out why a dev server was listening on a routable address at all — that is usually a container published with --host 0.0.0.0 for convenience, a cloud workstation with a permissive security group, or a preview environment that outlived its ticket. Put development servers behind authentication or a private network as a standing rule, and treat any dev-time tool reachable from the internet as a finding independent of whether it currently has a CVE. The four-month gap between advisory and mass exploitation is the window you are actually defending.
Sources: https://thehackernews.com/2026/09/mass-scanning-campaign-exploits-vite.html
7. Enterprises say they will pay for the package registries. No amounts yet.
OpenSSF · September 16, 2026
A joint enterprise commitment published by the OpenSSF Governing Board, and the signatory list is the news: Arm, Datadog, Dell Technologies, Ericsson, GitHub, Google, IBM, Kusari, Microsoft, Red Hat, the Rust Foundation and Sonatype — twelve organisations, several of them the largest consumers of the infrastructure in question. The registries named in scope include PyPI, Maven Central, crates.io, RubyGems, npm, NuGet, OpenVSX and Packagist. The scale figures explain why the conversation is happening now: those registries collectively serve trillions of downloads annually, with download volumes growing 30-50% year over year, and 1.8 million malicious packages were flagged across them in 2026 to date.
The forward projection is the interesting number. Signatories anticipate a 3-5x increase in publish events, driven in part by AI-discovered vulnerabilities generating more patch releases. That is a direct statement that AI-assisted security work is about to become an infrastructure cost borne by volunteer-funded registries — more scanning produces more findings produces more releases produces more bandwidth, storage and moderation load, and none of that lands on the organisation that ran the scanner. Set that beside the 1.8 million malicious packages and the registries are being asked to absorb both the legitimate and the hostile side of the same growth curve.
The commitment itself is five points, and they are principles rather than cheques: keep free access for individual developers and small organisations; explore enterprise-based funding for high-volume consumers and premium capabilities; treat registry fees as a business and security investment rather than a cost to avoid; support registry-run funding experiments; and respect each registry’s independence in choosing its own model. The Governing Board’s framing is blunt enough: “Registries cannot deliver the scale, availability, security, and observability enterprises need without sustainable funding.” The piece follows open letters from 2025 and May 2026, so this is the third public step in a sequence.
No funding amounts are disclosed, which is the honest summary of where this has got to: a statement of intent from organisations that could fund it, with the mechanism left to each registry. The part worth planning around is the “enterprise-based funding for high-volume consumers” clause, because if it becomes real, someone in your organisation is going to be asked to pay for dependency downloads that currently appear on no budget line. Now is a good time to be able to answer how many packages you pull, from where, and how much of it is your CI pulling the same artifact repeatedly because nothing caches it — an internal proxy or mirror is the answer to both the cost question and, incidentally, a fair amount of the availability question.
Sources: https://openssf.org/blog/2026/09/16/were-in-enterprise-commitment-to-sustainable-package-registries/
8. The court was the Ninth Circuit, the ruling was narrow, and the case is not over
DevOps.com · September 18, 2026
Start with the correction, because it changes how much weight the decision carries: the 16 September 2026 ruling in Doe v. GitHub came from the Ninth Circuit Court of Appeals, not a district court, whatever the headline says. An appellate ruling binds lower courts across the circuit; a district-court ruling does not. Judge Eric Miller held that AI-generated code lacking copyright management information does not by itself violate DMCA §1202, reasoning that “one who creates a new work and fails to include CMI cannot be said to have ‘removed’ or ‘altered’ anything.” Read that sentence literally, because the whole holding lives in it: §1202 is a provision about stripping attribution metadata, and the court found that generating a new work without attribution is not stripping.
Now the limits, which are extensive and which the coverage has mostly under-reported. The ruling did not decide whether training on open-source code infringes copyright. It did not decide whether such training is fair use. It did not decide whether matching output infringes. And it did not decide whether AI vendors must honour licence obligations. The core copyright claims remain live before the district court. Karen Sadler of the Software Freedom Conservancy has specifically warned against overreading the decision, and she is right to: this removes one statutory theory from the plaintiffs’ toolkit and leaves the central question — what a licence means when a model has read it — entirely open.
The worry from the open-source side is nonetheless real and worth taking seriously on its own terms. Duane O’Brien of the OSI and Bruce Perens are the concerned voices in the reporting, and the concern is structural rather than legal: copyleft licences depend on attribution and notice travelling with the code, and a ruling that generated output carries no CMI obligation weakens the mechanism by which a licence announces itself downstream. If attribution does not propagate, enforcement becomes a matter of proving provenance after the fact — which is exactly the problem the rest of this issue is trying to solve with build attestation and SBOMs.
What to do with it in an engineering organisation this quarter is modest but concrete. This does not change your obligations when you use open-source code — licence compliance for dependencies you pull is untouched by this ruling. It does mean that “the model will surface the licence” is not a control you can rely on: if your engineers use coding assistants, the output arrives without provenance and your compliance process has to establish it some other way. And if you have been tracking this case as the one that would settle AI training and open-source licensing, reset that expectation — the questions that matter are still in front of the district court.
Sources: https://devops.com/us-district-court-decision-in-ais-favor-worries-open-source-developers/
9. 623 million code changes: duplication up 81%, refactoring down to 3.8%
The New Stack · September 14, 2026
The underlying research is GitClear’s Maintainability Gap report, published June 2026 and drawing on 623 million analysed code changes spanning 2023 to 2026 — a code-change-operation database that classifies each change and derives duplication, hotspot and refactoring signals, with duplication normalised as block-duplication instances per million changed lines. That is a large and consistently measured dataset, and it is the reason this is worth more of your attention than the average productivity survey. But the headline welds together three different comparisons, and separating them is the whole job of reading it properly.
Comparison one: heavy AI users gained 25% against their own prior velocity. Not against a control group — against what those same developers used to produce. Comparison two, entirely separate: heavy AI users outproduced non-AI users by 4x to 10x. Comparison three: block duplication rose 81% against a 2023 baseline, from 40.3 to 73.0 instances per million changed lines — and that is a dataset-wide figure measured against a point in time, not a measurement of the same cohort that produced the 25%. So the sentence “AI made your code 81% more duplicated” is not something this research establishes. What it does establish is that the corpus got substantially more duplicated over the period in which AI-assisted development became normal.
The finding that would worry a staff engineer most is the refactoring collapse: “moved code” fell from 21% of changed lines in 2022 to 3.8% in 2026, and the behavioural read is that developers who previously chose refactoring over copy-and-paste at roughly two to one are now about five times likelier to copy and paste. That is a plausible mechanism — generating a near-duplicate is now cheaper than restructuring to avoid one — but apply the caveat the author of the report has earned: GitClear’s 2024 and 2025 editions drew methodology criticism for equating “moved code” with refactoring quality, and the same limitation applies to the 3.8% figure. Moved code is a proxy, not a measurement of whether the codebase got better.
The cost framing around it is thinner but points somewhere useful. Gary Cohn, IBM’s Vice Chairman, says AI return on investment “has not been nearly as high as people might think”, and Rippling has shipped an AI spend console giving CFOs and CTOs visibility into per-seat AI tooling spend — which tells you the finance function has arrived and is going to ask for a number. The defensible answer is not throughput. Track duplication and change-failure rate alongside output, because those are the measures that will tell you whether the 25% is compounding or being repaid with interest later, and both are computable from the repository you already have.
Sources: https://thenewstack.io/ai-coding-duplication-rose/
Calls to action
- Upgrade the two agents that have a fix, and constrain the two that do not. Claude Code is fixed in 2.1.179 and later, Codex in 0.146.0 and later. GitHub Copilot and Gemini CLI are unpatched for Plugin4Shell — inventory the plugins those agents install and restrict them to GitHub-hosted sources, which blocks branch and tag names that look like commit hashes. There is no CVE, so nothing in your scanning stack will raise this for you.
- Find every development server listening on a routable address, today. Patch Vite against CVE-2026-39364, then go after the cause: containers published with
--host 0.0.0.0, cloud workstations with permissive security groups, preview environments that outlived their ticket. A dev server reads arbitrary files off disk by design; there is no safe configuration of it on the internet, patched or not.
- Inventory your MCP configuration files and treat them as a credential store. 12% of credential slots in 82,000 public configs held a hardcoded secret, 53% of those granted organisation-, account-, workspace- or database-wide access, and 55% had no vendor-recognisable format — so pattern-based scanning will not find them. Move the values into the secret manager you already run, scope them below workspace level, and add entropy-based detection.
- Scan Git history, not just the working tree. In a sample of 7,681 credential-bearing configurations, 243 held secrets deleted from the current file but still present in history. A deleted secret that was never rotated is a live secret with a false sense of closure. Rotate on discovery rather than on exposure.
- Eliminate dev-branch dependency resolution. If anything in your
composer.json — or the equivalent in any ecosystem — resolves to a moving Git ref, a force-push changes what you install with no version bump to notice. Pin to released versions, commit the lock file, and verify it in CI instead of regenerating it on every build.
- Turn on cache-mode in GitHub Actions. It limits cache-poisoning exposure and it does nothing until it is set. Put it in your reusable workflow templates so new pipelines get it by default rather than by memory.
- Make sure you could answer “which repositories did this identity read last month?” The stolen OAuth token that copied 170 CrowdSec repositories left no trace in any log the company could access, and the breach surfaced four months later because someone posted the archive. Enable organisation-tier audit logging with retention you control, and alert on bulk clone or read activity from a single identity.
- Treat a departing employee’s credentials as compromised, not merely revoked. The CrowdSec account was removed from the organisation three days after the copy and it made no difference. Offboarding should revoke OAuth grants and personal access tokens at the identity provider and the forge, not just remove org membership.
- Scope every publish and service token to one action. The only usable credential in the CrowdSec dump was an AWS SNS token limited to publishing to a single topic — an unauthorised attempt to use it in August went nowhere because of that limit. Narrow scoping is the control that demonstrably worked this week; apply it to registry publish tokens first.
- Gate dependency additions that originate from an agent. In the Mandiant intrusion the assistant recommended the poisoned package and the recommendation was accepted. Require human confirmation for any new dependency regardless of who proposed it, give agent sessions credentials scoped separately from the developer’s, and make publishing into your own internal namespace a gated action rather than an authenticated one.
- Add duplication and change-failure rate to whatever you report on AI coding. Throughput is the number your finance function will ask for and the least informative one available. Block duplication rose from 40.3 to 73.0 instances per million changed lines across 623 million changes; both duplication and change-failure rate are computable from the repository you already have, and they are what tells you whether a velocity gain is compounding or accruing debt.
- Work out what you pull from the public registries, and put a proxy in front of it. Enterprise funding for high-volume consumers is now an explicit OpenSSF Governing Board position, so someone will eventually ask what your download volume is. A caching mirror answers the cost question, removes a class of availability incident, and gives you a chokepoint to enforce policy at.
|