DEV Community: Hamvero Technologies

Next.js 16.3 Instant Navigations: What It Actually Does to Your Page Loads

Hamvero Technologies — Thu, 12 Nov 2026 03:35:15 +0000

The long complaint about server-rendered React is navigation speed. A click waits on the server before anything changes on screen, and the app feels slower than a client-side SPA. Next.js 16.3 ships features aimed at that gap. The mechanism matters more than the feature names, because the trade-off is real.

What shipped

Instant Navigations gives each route a strategy: Stream or Cache makes the navigation instant, and Block opts out. "Instant" changes from a global setting to a per-route decision.

Partial Prefetching carries the architectural weight. It caches a reusable shell per route on the client. On click, the shell renders immediately while the page data streams in behind it.

The release also added server-rendered data, optimistic updates, and live client capabilities. The direction is a responsiveness match with client-driven SPAs, without giving up server rendering.

How the shell works

Most routes have a stable outer structure and a variable inner one. Nav, sidebar, layout chrome, and page skeleton stay the same between two product pages. The product data changes.

The framework caches that stable part client-side ahead of time. On click it paints, and the variable part streams into a visible frame instead of a blank screen. Skeletons did this manually. 16.3 makes it automatic per route.

The trade-off release notes skip

Prefetching spends bandwidth and server work on navigations that may never happen.

Prefetch shells for every link in view and you pay for routes the user does not visit. A desktop connection hides that cost. A metered mobile connection with a link-heavy page does not, and the user pays it rather than you, which makes it easy to under-weigh while testing on a fast laptop.

Block exists for this. Treat it as configuration rather than an escape hatch. Routes that cost a lot to prepare, routes people rarely open, and anything behind a confirmation step are reasonable candidates.

Measure prefetch volume on a representative page before turning this on broadly, and check data transfer on a throttled connection instead of a Lighthouse score on an unthrottled one.

Versions and support

16.3.x is the Active LTS line. The August 2026 security release moved to 25 August, fixed two critical vulnerabilities, and shipped 16.3.3 alongside 15.5.24.
15.5.x is Maintenance LTS, still receiving backported security fixes. Staying there is a supported choice.
Next.js 16 dropped Edge runtime support. Canary work removed Edge runtime handling from the use-cache wrapper. Anything depending on Edge runtime needs a migration plan.

Recent 16.3 backports covered next/image disk cache handling (skipping and rejecting 0-byte entries), CSP nonces on script tags in loading and template files, and standalone output emitting whole-app server NFTs with an adapter. The CSP nonce fix matters if you run a strict policy and had been working around missing nonces by hand.

Upgrade or wait

Users complain the app feels slow between pages: upgrade, and try Partial Prefetching first.
Pages are mostly static with little navigation: the gain is marginal and the prefetch cost is not free. Upgrade for the security fixes.
You are stable on 15.5: Maintenance LTS still gets security backports, so there is no rush to change majors for a performance feature.

One signal about direction: 16.2 stabilized the Adapter API and shared tests across providers, and 16.3 added agent-facing tooling including React state introspection from a real browser and a focused MCP server. The framework now invests in two developer experiences, human and agent, which is a bet about who writes this code next.

The full analysis, with the LTS table and backport details: https://www.hamvero.space/blog/nextjs-16-3-instant-navigations/

A New Open-Weight Model Finds Security Bugs for $2.38 a Run, and It's Not More Accurate Than Claude

Hamvero Technologies — Thu, 12 Nov 2026 03:34:33 +0000

Cantina Security released apex-flash-1 on 2 October: an open-weight, MIT-licensed model built to read code, use tools, pursue an exploit, and verify that it worked against a live target. Most coverage led with the cost figure, $2.38 to run a 60-task benchmark against $74.68 for Claude Opus 5 High.

That figure is not a capability claim. Opus solved more tasks. apex-flash-1 solved fewer for a fraction of the money, which is a useful trade and not a win on accuracy.

What the model is

Cantina built it with Yeta Labs as a reinforcement-learning (GRPO) post-train of Z.ai's GLM-5.3-Flash, at 321.3 billion total parameters. Cantina describes it as a worker model: something a larger orchestrating agent directs at a focused investigation, rather than an agent you point at a codebase and leave.

Training data came from Cantina's own security work. Fifty real vulnerability cases, each expanded into three versions with different access and direction, produced 150 training tasks.

The benchmark

Cantina tested three models on 60 held-out tasks drawn from 20 vulnerability cases outside the training set. Each task ran in an isolated environment, and a verifier checked the target's end state instead of trusting the model's report:

Model	Tasks solved	Pass@1	Estimated cost (60 tasks)
Claude Opus 5 High	43/60	71.7%	$74.68
apex-flash-1	40/60	66.7%	$2.38
GLM-5.3-Flash (base model)	36/60	60.0%	$4.56

Opus remains the most accurate of the three. apex-flash-1 closes most of the gap to Opus over the untuned base model, at roughly 31 times lower cost than Opus and about half the cost of its own base model.

Missing three or four more tasks out of 60 in exchange for that bill is a legitimate trade. Needing the last few points of accuracy regardless of cost is also legitimate, and this result does not change which model wins there.

Hardware the name hides

apex-flash-1 needs roughly 640GB of GPU memory for BF16 inference. "Flash" describes the base model lineage, not the machine you run it on. It deploys through vLLM, SGLang, Transformers, or Docker Model Runner, and it is not a workstation experiment.

The second checkpoint

Cantina shipped apex-flash-1-abliterated alongside it, an experimental derivative with modified refusal behavior. None of the published numbers describe that variant, and it has no evaluation at all.

Standardizing on this model family means pinning the exact weights you deploy. A checkpoint with modified safeguards does not inherit the tested behavior of the one with the benchmark attached.

The wider field

Aikido Security's Altar-1 (expert pruning and quantization, reporting 60.4% recall on a 32-CVE internal set) and Cisco's Foundation-Sec-8B-Reasoning (instruction-tuned and RLHF'd on security data) both test the same bet: a model tuned for security work can approach frontier accuracy on narrow tasks for far less money.

The caveat that matters

Every number above comes from Cantina, on Cantina's 60-task internal benchmark, with no independent replication. That does not make the result wrong. It makes 66.7% a vendor figure until somebody else runs it.

If this model matters to your work, run it against your own vulnerability cases before treating the published table as generalizable.

Authorized use

A model trained to pursue an exploit and verify its effect on a running target is dual-use by design. The same capability makes defensive verification work. Cantina frames the release around authorized security research, and the MIT license plus published benchmark show a company being explicit about what it built.

Deploy it in controlled, scoped, authorized environments. Not against systems you do not own.

Before you evaluate it

Test your own cases before trusting 66.7% on your codebase.
Budget for 640GB of GPU memory before planning anything.
Confirm the standard checkpoint, not the abliterated variant, if you need the behavior the benchmark describes.
Treat it as a cost tool for narrow, authorized work, not a replacement for a frontier model where accuracy outweighs cost per task.

The full analysis, with methodology and sources: https://www.hamvero.space/blog/cantina-apex-flash-1-security-model/

Twelve Exploited CVEs in One Year: Why Attackers Keep Coming Back to Langflow

Hamvero Technologies — Thu, 12 Nov 2026 03:33:55 +0000

Twelve Langflow vulnerabilities were exploited in the wild during 2026. In all prior years combined, there was one. Successful exploitation attempts across that set exceed 15,000.

A run like that points at what AI development infrastructure has become worth attacking.

The current flaw

CVE-2026-0768 is a CVSS 9.8 unauthenticated remote code execution flaw in Langflow's custom component editor, specifically the code validator. ZDI published it as a zero-day advisory on 9 January 2026. It affects Langflow 1.4.2 and earlier.

The mechanism is short: the validate endpoint takes a user-supplied code parameter and passes it to Python's exec() without sanitization. No authentication, and execution happens as root.

VulnCheck saw exploitation attempts on its UK honeypots hours before public disclosure. About 50 attempts over a weekend became 360 observed attacks, mostly from Russia. Separate analysis put the exposed population near 7,000 servers.

What gets taken

This is where the story stops being about one CVE. After root execution, the attacker runs reconnaissance and reads environment variables, according to VulnCheck's Caitlin Condon. The target list:

OPENAI_API_KEY and Anthropic tokens
AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, plus GCP and Azure credentials
Langflow superuser authentication keys
Database connection strings
/root/.cache/langflow/secret_key
.ssh access and .bash_history, for lateral movement

Nobody attacks Langflow for the flow diagrams. A server that runs your workflows also holds every credential those workflows need, usually as static values in environment variables.

That is an architectural property of the category. Any self-hosted platform that executes user-defined workflows and stores long-lived provider keys has the same shape. Langflow gets hit because it is popular and exposed.

The 2026 pattern

CVE-2026-33017 (March): unauthenticated RCE in the public flow build endpoint, weaponized within about 20 hours, used to harvest OpenAI, Anthropic, and AWS credentials before pivoting to Monero mining. Added to CISA KEV on 25 March.
CVE-2026-5027 (CVSS 8.8): path traversal and arbitrary file write through the files endpoint, escalatable to RCE, with exploitation observed.
CVE-2026-55255: unauthorized access to workflows, data theft, second-stage malware.
CVE-2026-0770: root-level command execution for credential extraction and malware deployment.
CVE-2026-9198: CISA flagged it after public proof-of-concepts surfaced.

Two problems repeat across that list.

Incomplete patching. CVE-2025-3248, disclosed in April 2025, was a different RCE in the same validate endpoint, fixed in 1.3.0. CVE-2026-0768 is a later injection in the same area. JFrog found versions reported as patched for related CVEs still exploitable after fixes shipped. A version number has not been a reliable signal here.

A shorter window than your process assumes. Twenty hours from disclosure to weaponization in March. Exploitation attempts before public disclosure in the current case. A response plan built on days is already behind.

If you run Langflow

Find exposed instances. Exposure is the biggest risk factor, and many instances reach the internet by accident.
Set LANGFLOW_AUTO_LOGIN to false and enforce authentication at the network edge rather than relying on the app.
Restrict network access. Rarely does a Langflow instance need to be reachable from the open internet.
Rotate exposed credentials: OpenAI, Anthropic, AWS, GCP, Azure, database strings. Assume anything exposed was harvested. Rotation is the only remedy.
Check environment variables, local secret files, and .bash_history for signs of access and lateral movement.

The structural fix and its cost

Patching faster helps and will not close this. Twelve CVEs in a year, with a history of incomplete fixes, calls for a smaller blast radius.

Stop embedding static API keys in flows. Brokered, short-lived credentials through Vault or a cloud KMS shrink the value of a successful exploit. A stolen 15-minute token is an incident. A stolen long-lived OPENAI_API_KEY is a bill and a breach.

The stronger version of the argument holds up too: a server that executes your flows and stores your keys is a high-value target by construction, and the safest architecture has no hosted endpoint executing anything. That trade costs you one-click cloud runs. Whether it pays depends on what the convenience buys your team.

Treating AI tooling as outside vulnerability management stopped being defensible. Twelve exploited CVEs in twelve months puts Langflow-class infrastructure in the same tier as any internet-facing application server, with the same patching cadence, exposure monitoring, and credential hygiene.

The full write-up, with the exploitation timeline and sources: https://www.hamvero.space/blog/langflow-twelfth-exploited-cve/

MCP vs. REST APIs for Agentic Tools: When Each Actually Wins

Hamvero Technologies — Thu, 12 Nov 2026 03:32:58 +0000

Building something agentic means hitting this decision within the first week: connect a REST API the model can call, or expose an MCP server. Most explanations stop at "MCP is for tools, REST is for services", which does not help anyone choose. This one goes further.

The structural difference

A REST API has fixed, known endpoints. The client, here an LLM-driven agent, needs the request and response shape ahead of time, usually through an OpenAPI spec translated into a tool definition. A new capability means a new endpoint and an updated spec.

MCP inverts that. The server exposes list_tools and tells the model at runtime what it can do and which parameters each action takes. No capability has to be baked into the client, and the schema is written for a model rather than adapted from a human-facing API.

Sessions differ too. MCP carries persistent, stateful sessions over stdio or SSE. REST stays stateless, and the client handles session state itself through tokens or cookies.

Where REST wins

Maturity. Two decades of auth standards, caching layers, rate limiting, monitoring, and documentation conventions. MCP has a fraction of that history.
Non-agentic consumers. Web frontends, mobile apps, and internal services all speak REST. An MCP-only build leaves you maintaining a second interface.
Small fixed surfaces. Three endpoints that never change gain nothing from runtime discovery, and a static OpenAPI spec is easier to test and secure.
Infrastructure support. Cloud providers, frameworks, and load balancers understand REST without configuration. MCP hosting patterns are still settling.

Where MCP wins

Runtime discovery. Plugins, user-installed extensions, and evolving toolsets change what is available. Discovery avoids the redeploy cycle.
Model-native schemas. Tool definitions are read by a model directly, which removes the wrapper that turns OpenAPI into a function-calling schema.
Consistency across vendors. An agent connected to several MCP servers gets one interaction pattern. Several independently designed REST APIs mean several auth schemes, error formats, and pagination styles.
Stateful tool use. A server that remembers context across calls in a session is native to MCP. REST needs session code written on top.

A worked example

You are building an agent that triages support tickets. It reads ticket details, searches a knowledge base, and occasionally creates a follow-up task in a project tool.

Ticket reads and knowledge base search are stable operations the whole team already depends on. Keep them on REST. The endpoints exist, they are documented, and other parts of the product call them.

Creating a follow-up task means calling a third-party project tool where the available actions expand over time: comment, reprioritize, assign, and whatever ships next quarter. That belongs on MCP. You get discovery of whatever the tool exposes without writing a wrapper per action.

The agent's reasoning loop benefits from MCP's session awareness, since it may need something it looked up two calls ago without your code threading that state through.

Nothing migrated wholesale in that example. Stable infrastructure stayed on REST. The agent-facing, changing surface went to MCP.

Migrating without a rewrite

If a REST API already exists, put a thin MCP server in front of it. Translate list_tools and call_tool into calls against the endpoints you have. The agent gets discovery and model-native schemas, your business logic and auth stay in one place, and the web and mobile clients notice nothing.

You maintain a translation layer. That costs less than rebuilding core services, and far less than running two full interfaces.

Four things to check before committing

Security. MCP's permission and vetting ecosystem has not caught up with the access a typical server receives. REST auth patterns are better understood. Vet an MCP server the way you vet a new dependency.
Implementation quality. Server quality varies widely on a young spec. A popular server is not automatically a careful one.
Latency by transport. A local stdio server can beat a network call. Remote SSE servers bring their own profile, so benchmark rather than assume.
Debugging. curl, Postman, and browser devtools have covered REST for years. MCP tooling is thinner.

What the numbers say

TrueFoundry's benchmarks put Streamable HTTP, MCP's current remote transport, at roughly 10ms per call under load, holding 290 to 300 requests per second at full success in a shared-session deployment. The older SSE transport dropped to 7 to 30 requests per second under the same load with latency in the hundreds of milliseconds, which is why Streamable HTTP replaced it in the spec.

Library bugs can outweigh all of that. A 2026 benchmark traced about 40ms of fixed overhead on every HTTP tool call to rmcp v0.16, a Rust MCP library that hardcoded SSE-style framing for stateless replies that should have returned plain JSON. That inflated latency roughly 35 times over the tool's actual I/O time. It was fixed in v0.17.0.

A slow MCP server may be measuring the protocol or one library's bug. Only your own benchmark separates the two.

The short version

Default to REST for stable, high-traffic operations with consumers beyond the agent. Use MCP at the tool-calling boundary where capabilities change at runtime. Keep core services on REST and build the agent-facing layer on MCP.

The full breakdown, including transport benchmarks and sources: https://www.hamvero.space/blog/mcp-vs-rest-apis-agentic-tools/

Why Rust Quietly Became the Backbone of AI Agent Infrastructure

Hamvero Technologies — Thu, 12 Nov 2026 03:32:15 +0000

Most "why Rust" pieces reach for speed. Speed is true and irrelevant to why infrastructure teams picked Rust for the layer under AI agents. The reason has more to do with what happens when you hand software root access and let it run unsupervised.

The growth numbers

GitHub's fastest-growing AI agent repositories in Q1 2026 show a clear shift. Rust AI tools from 2023 and 2024 averaged about 25 stars a day. The 2026 wave of Rust AI infrastructure projects averaged roughly 404 stars a day, a 16x jump that holds when you exclude corporate-backed repos and look only at community projects.

That pattern describes infrastructure teams making a language choice for a specific job, not Rust enthusiasts building niche LLM tooling.

The job changed

Early agent frameworks, LangChain and AutoGPT and CrewAI in their original form, called APIs and returned strings. A failure produced a malformed response.

Agents in 2026 run shell commands, manage files, spawn processes, and drive browsers, often with permission modes that skip manual approval for speed. Software at that access level runs autonomously for hours. Memory safety moves from preference to requirement.

Rust's ownership model and borrow checker provide memory safety without a garbage collector. Predictable behavior matters more than raw throughput when a tool call can delete a branch or reach production credentials. Avoiding a GC pause is a small win. Avoiding a use-after-free in a process holding your keys is the whole point.

Where the pattern shows up

Vector databases. Qdrant, widely used in RAG pipelines, is written in Rust for throughput and memory efficiency in high-volume similarity search.
Tooling that runs constantly. Astral's ruff and uv replaced slower Python equivalents for the work happening in the background of every developer session.
Agent frameworks. Rig gives Rust developers one trait-based interface across LLM providers, where switching from OpenAI to Anthropic comes close to a one-line change.

The common thread is Rust at the systems, execution, and sandboxing layer. That is where a bug becomes an incident rather than a wrong answer.

What this does not mean

Your agent stack does not need a rewrite. Python still runs agent logic, RAG pipelines, and most of the framework ecosystem, because the LLM tooling, examples, and hiring pool live there.

Production systems in 2026 look mixed: Python for reasoning, Go or similar for API and governance routing, Rust for the sandboxed executor where agent-generated actions reach the machine.

The cost is real. Engineers who know both Rust systems work and agent tooling are rare, which pushes compensation up at well-funded companies. Rust's agent ecosystem is smaller than Python's, so you write more yourself and find fewer examples to copy.

Four companies, one boundary

Microsoft made Rust a Tier-1 language for new projects internally, alongside C++ and C#.
OpenAI rewrote Codex CLI from TypeScript to a native Rust binary and removed the Node.js runtime.
Cloudflare built Kitesurf, an agent-first browser engine in Rust compiled to WebAssembly, using roughly 7x less memory than Chromium for the same work.
Vercel made a comparable infrastructure bet in the same window.

None of the four rewrote their AI logic. All four moved the execution, sandboxing, or runtime layer. Four unrelated teams drawing the same architectural line tells you something about where the risk sits.

What to do with this

An agent that runs shell commands, touches the filesystem, or holds real permissions earns a Rust rewrite at the execution layer faster than anywhere else. An agent that calls APIs and returns text does not, and Python's ecosystem depth still wins there.

For a cheaper entry point, adopt the Rust tools already in the workflow. ruff and uv deliver the performance and reliability argument without a line of Rust.

The data and the four examples are in the full write-up: https://www.hamvero.space/blog/rust-ai-agent-infrastructure/

GitSpawn: Your AI Coding Agent Runs Attacker Code Before You Type Anything

Hamvero Technologies — Thu, 12 Nov 2026 03:31:28 +0000

Open a folder with Claude Code and it runs git status before you type anything. It runs before the workspace-trust prompt appears, and on some agents before you have authenticated. A folder that came from somewhere else decides what that command executes.

Manifold Security disclosed the flaw in early September as GitSpawn: eight findings across seven command-line AI coding agents.

Git does the work, not the model

Manifold's framing explains the case better than any summary: nothing here is new, and nothing here lives in the model. The bug sits in the subprocess an agent starts at session startup to work out where it is.

Agents need context constantly. Which branch is this? What changed? What is staged? Several products answer those questions by invoking Git in the background. Git reads repository-local configuration when it runs, and some settings, core.fsmonitor among them, name a command that Git executes.

A malicious .git/config needs one section:
source links: https://www.hamvero.space/blog/gitspawn-ai-agents-git-config-rce/

Auditing MCP Servers for Supply-Chain Risk with Bumblebee

Hamvero Technologies — Thu, 12 Nov 2026 03:30:07 +0000

Install a dozen MCP servers in a few months and you lose track of what any of them do. Most of us run one install command from a Discord recommendation, grant filesystem or terminal access, and move on. Bumblebee, an open-source CLI from Perplexity, targets that gap.

What it checks

Bumblebee is a read-only scanner written in Go with no external dependencies. That matters more than it sounds: a security tool carrying twenty transitive dependencies is a supply-chain risk pretending to solve one. It covers four surfaces:

Package manifests across npm, PyPI, Go modules, RubyGems, and Composer
Installed MCP servers, matched against known-malicious and suspicious registries
VS Code extensions installed on the machine
Browser extensions in your inventory

It changes nothing. It reads, compares against threat registries, and reports. You do not want the scanner to be the component with write access to your environment.

Where it sits next to npm audit and Snyk

npm audit, Dependabot, and Snyk handle package manifests well. None of them look at MCP servers, editor extensions, or browser extensions, and that gap grew as MCP servers started receiving broad permissions.

npm audit and Dependabot track dependency vulnerabilities inside one ecosystem and run in CI.
Snyk has a broader vulnerability database and better remediation guidance. It is paid beyond basic use, and it does not cover MCP servers as of this writing.
Bumblebee has the narrower scope. It will not tell you how to fix a flagged package, and it is the only one of the three checking installed MCP servers, editor extensions, and browser extensions against threat data.

Most teams end up running more than one. Bumblebee covers the surfaces the others ignore.

Who needs it now

Solo developers installing MCP servers from GitHub and Discord links. Least existing tooling covers this gap.
Teams on shared dev machines or shared CI runners. A compromised server there becomes a lateral-movement problem.
Anyone running servers with filesystem or terminal permissions. That access level is what makes a bad server dangerous.
Teams enforcing extension allowlists through MDM. Lower priority, though a second check still helps.

Why MCP specifically

Auditing npm and PyPI packages is old ground. The MCP server check is new. MCP adoption ran ahead of its vetting culture, and the ecosystem resembles npm around 2015: many small, single-maintainer servers, thin review, and users granting filesystem access, terminal execution, and API keys without much thought.

A compromised MCP server is a program that can read your codebase and send data anywhere it likes. People grant that access in one click.

Running it

1. Install. Go 1.25 or newer.
source links: https://www.hamvero.space/blog/auditing-mcp-servers-bumblebee/

Plugin4Shell

Hamvero Technologies — Thu, 12 Nov 2026 03:25:58 +0000

A plugin pinned to a reviewed commit hash should install that exact code. That assumption underpins how most organizations secure AI coding agents. In September it failed across all four major ones.

The broken check

The AIR Security research lab named the flaw Plugin4Shell. Researchers Or Nevo, Dor Granat, and Niv Hoffman found it in May 2026 and built working exploits against Claude Code, OpenAI Codex, GitHub Copilot, and Gemini CLI. They disclosed to each vendor the following month.

The mechanics are simple enough to explain in a paragraph. A marketplace or your security team reviews a plugin at a specific Git commit and records that commit's SHA hash. The agent should then fetch exactly that code.

The affected agents request the pinned SHA during Git checkout. None of them verify that the checked-out working tree matches it. That gap runs straight into Git reference-name ambiguity: an attacker creates a branch whose name is the same 40-character hexadecimal string as the pinned commit, sets it as the default branch, and Git may resolve the branch instead of the commit. The agent installs attacker code while reporting a successful install of the trusted version.

One missing verification step removes the entire pinning guarantee.

Why nobody has to click anything

Several coding agents update installed plugins automatically. An attacker can publish a benign plugin, pass marketplace review on merit, wait for adoption, and swap the code later. The victim takes no action and makes no mistake.

The researchers made this point directly, and it undercuts the usual "users install sketchy things" defense. Exposure requires only that a plugin is installed, from a marketplace you trust, reviewed and pinned the way the security model intends.

The blast radius follows from what plugins can reach. Agent plugins, skills, and extensions run with the permissions of the developer operating the agent: source code, secrets, cloud environments, production systems, internal services, enterprise data. An attacker gets the same reach as the employee.

AIR calls Plugin4Shell the first true supply-chain vulnerability of the AI agent ecosystem. Earlier agent security research went after the model or the agent's reasoning. This one targets the distribution layer, the marketplaces feeding code to millions of machines.

Patch status differs by vendor

Claude Code: patched by Anthropic in 2.1.179
Codex: patched by OpenAI in 0.146.0
GitHub Copilot: Microsoft received the report and has not shipped a fix
Gemini CLI: Google deprecated the CLI instead of patching it, and points users at Antigravity

Deprecation is not remediation. An install on a developer's machine stays vulnerable after the vendor stops supporting it. If Gemini CLI runs anywhere on your team, migrating off it is now a security task, not a roadmap item.

Marketplaces cannot fix this centrally

You might expect GitHub or whichever marketplace you use to close the gap for everyone. AIR is explicit that it cannot: the verification check runs inside the agent, not at the marketplace. Each vendor has to fix it in the agent.

Updating is the complete fix wherever one exists. Copilot and Gemini CLI have no configuration that restores the pinning guarantee.

Four things to do now

Update Claude Code to 2.1.179+ and Codex to 0.146.0+. A real fix exists for both.
Treat Gemini CLI installs as a migration task. No patch is coming.
Assume pinning does not protect Copilot. Review which secrets and production access sit in the environments where it runs, and reduce what a successful plugin swap would reach.
Audit installed plugins across your team's agents. A pinned plugin from a trusted marketplace was the failing scenario, so "we only install reviewed plugins" describes the problem rather than the defense.

The same layer failed twice in one month

GitSpawn came earlier in September: a malicious .git/config executed code across Claude Code, Codex, Cursor, and four other agents, and four vendors were still unpatched at a September 1 retest.

The tooling around agents matured faster than the verification underneath it. Marketplaces, SHA pinning, and approval layers all existed. None of them were enforced end to end. Expect more of these, and treat each one as a class of bug rather than an isolated incident.

The full write-up has the vendor-by-vendor patch table and source links: https://www.hamvero.space/blog/plugin4shell-ai-coding-agents/