Amazon Q CVEs, Hijacked npm and Go Packages, AWS WAF HTTP/2 Issues, Lambda MicroVMs, and Why Execution Is the Boundary Now

This week, Amazon Q Developer and the AWS language servers had a pair of trust-boundary CVEs. JFrog found hijacked npm and Go packages using hidden VS Code tasks to run malware when a workspace opens. AWS WAF had HTTP/2 request body inspection issues. And AWS introduced Lambda MicroVMs for running user-generated and AI-generated code in isolated sandboxes.

Put those together, and the shape of the episode is pretty clear. Execution is the boundary now. The repo. The IDE.

The AI assistant. The WAF. The sandbox. They all sit at the point where something gets to run, inspect, block, or decide.

And that is where the risk lives. I'm Brian Teller from Teller's Tech. And this is Ship It Weekly. Welcome back to Ship It Weekly, the show about the DevOps, SRE, cloud, platform, and security stories that actually matter when you're the person who has to keep the thing running at 3 a.

m. If you're new here, follow or subscribe wherever you're watching or listening. And if you want the weekly story list and source links, check out OnCallBrief.com.

For past episodes, full show notes, and more from the show, head over to ShipItWeekly.fm. This week is about execution boundaries. Who gets to run code?

Who gets to load config? Who gets to inspect the request? Who gets to decide whether something is safe? We open with Amazon Q Developer and AWS language server CVEs, then hijacked npm and Go packages using VS Code folder-open tasks.

After that, AWS WAF and HTTP/2 request inspection, then AWS Lambda MicroVMs, because sandboxing untrusted code is becoming a first-class platform problem in the lightning round we'll hit GitHub advisory volume git 2.55 valkey 9.1 and a quick fable 5 callback let's get into it first up AWS disclosed two issues in language servers for AWS and Amazon Q Developer IDE plugins. The first one is CVE-2026-12957.

AWS describes it as improper trust-boundary enforcement. The short version, if a user opened a malicious workspace, commands inside project configuration files could automatically execute. The user had to trust the workspace when prompted, but that is not exactly a giant comfort. Because developers trust workspaces all the time.

They clone a repo. They open it in VS Code. They click through whatever prompts get them back to work. And they assume the repo is code, not a local execution trap.

The second issue is CVE-2026-12958. That one involved symlink validation. A malicious workspace could use a crafted symlink that resolved outside the workspace trust-boundary both bugs point to the same bigger problem the IDE the language server the assistant and the project folder are all negotiating what is trusted and that boundary is messy it includes config symlinks workspace trust MCP server configuration environment variables, local files, cloud credentials, and whatever the assistant or plugin can reach.

That is why this matters. Amazon Q Developer is not just an editor feature. It sits near source code, local credentials, AWS profiles, repo context, terminals, and sometimes production access. So when a workspace can cross into command execution, it can become more than a local bug.

It can become a cloud credential problem, a source control problem, a CI/CD problem. The takeaway? Update Amazon Q Developer and the AWS IDE plugins, but also review the operating model. Do developers understand workspace trust?

Are MCP configs reviewed? can project config execute shell commands do developer machines have long-lived AWS credentials can a malicious repo jump from weird local folder to cloud account access AI coding assistants are becoming part of the local control plane local control planes need boundaries not vibes boundaries second story JFrog found hijacked npm packages using a clever execution path. The malicious versions were not relying on the usual npm lifecycle scripts. No obvious preinstall, no obvious postinstall.

Instead, the payload hid inside a VS Code task, specifically a hidden task configured with run on folder-open. So the trap is not just install the package and npm runs code. The trap is open the project folder in VS Code, trust the workspace, and the IDE runs the task. That is a different threat model.

And it matters because the ecosystem has been hardening the package manager path. npm version 12 is changing install script defaults. Teams are paying more attention. to dependency execution ci pipelines are starting to care about lifecycle scripts that is all good but attackers adapt if npm install gets harder they look for the next execution surface and the IDE is a very good one developers open folders all day example projects reproduction repos proofs of concept vendor samples AI generated apps Random repos from Slack or GitHub issues.

And the editor is not passive. It runs extensions. It loads config. It starts language servers.

It runs tasks. It reads environment. It can access terminals and local secrets. JFrog also found additional Go packages tied to the same malware pattern.

So this is not just an npm story. It is a workspace execution story. The takeaway is to treat IDE workspace trust like a security control. Watch for hidden VS Code tasks.

Pay attention to run on folder-open. Be careful with VS Code tasks in random repos. Do not trust every folder just because it looks like code. And for teams using Cursor, VS Code forks, or AI-heavy editor workflows, this gets even more important.

The package manager is not the only place code runs. Your editor is an execution environment now, so act like it. Third story, AWS disclosed two AWS WAF issues involving HTTP/2 multi-frame request body inspection. The CloudFront case was remediated server-side with no customer action required the application load balancer case is the one that operators should look at under certain conditions a crafted multi-frame HTTP/2 request could cause only part of the request body to be inspected that is the sentence that matters only part of the body gets inspected because when you put waf in front of an application the whole point is that the security layer sees the thing you are trying to block.

If a request is split across frames and the inspection layer does not accumulate enough of it before applying rules, then the security decision may be made on an incomplete view. That is not unique to AWS WAF. This is a classic security control problem. The proxy, load balancer, WAF, app server, and backend framework all have to agree on what the request means.

If one layer parses it one way and another layer parses it differently, attackers get room to move. That is where parser differentials and request smuggling-style problems come from. AWS released a configuration option on ALB so customers can control how WAF inspects HTTP/2 request bodies. So this is not only a provider fixed it story.

If you use WAF with ALB and HTTP/2, there is something to review. The takeaway? Do not just ask, do we have WAF? Ask what it sees.

Where does TLS terminate? Is HTTP/2 involved? Are request bodies inspected the way you think they are? Do your ALB settings match the protection model you are depending on?

Security controls are not magic shields. They are parsers, policies, and defaults. And this week, the parser mattered. Fourth story.

AWS introduced Lambda MicroVMs. This is the positive version of the same theme. If the first three stories are about unexpected execution paths, this one is about building a safer place for execution to happen. AWS describes Lambda MicroVMs as a new serverless compute primitive for running user-generated or AI-generated code in isolated, stateful execution environments.

You get VM-level isolation, fast launch and resume, lifecycle control, state control, and AWS manages the underlying infrastructure. The use cases are easy to imagine. AI coding assistants, interactive code environments, Plugin systems, data platforms, vulnerability scanners. Anything where your product needs to run code that your team did not write.

That is becoming normal. And it is dangerous if handled casually. Containers are useful, but shared kernel isolation is not always the boundary you want for untrusted code. Full VMs are stronger, but heavier.

Traditional Lambda is great. but not built for every interactive or stateful sandbox use case. Lambda MicroVMs are AWS trying to fill that gap. Whether you use this specific product or not, the direction matters.

Running untrusted code is becoming a platform feature, not an edge case, not a just run it in Docker and hope situation, a platform feature. The takeaway. is to inventory your execution surfaces. Where do users, agents, plugins, tests, scripts, or generated workflows run code?

Can that code reach internal services? Can it access credentials? Can it write to shared storage? Can it talk to the internet?

Can state leak between users? Can you kill it? Can you audit it? Can you prove it is gone?

Execution is not going away. the platform has to make execution safer. Quick lightning round. First, GitHub says its advisory database hit a record volume.

In May, GitHub published more than 1,500 reviewed advisories, more than five times the typical monthly output. And even that was not enough. to keep up that is a real DevSecOps problem vulnerability management is becoming a queueing problem the hard part is not getting alerts the hard part is deciding what matters before the queue buries the team second git 2.55 is out the useful bit is incremental MIDX support through git repack That mostly matters for very large repositories and hosting platforms.

But it is a good reminder that developer platforms are infrastructure too. At enough scale, Git performance becomes engineering productivity. Third, Amazon ElastiCache now supports Valkey 9.1.

The main angle is performance and efficiency improvements landing in the managed AWS service. Not every cache needs an urgent upgrade. But cache engines are production systems. Memory efficiency, throughput, command behavior, and isolation matter when the cache is sitting directly in the request path.

Fourth, quick Fable 5 callback. Anthropic's Fable 5 is back online after the export control issue that knocked it offline. And that does not weaken the earlier point. It strengthens it.

The model came back, but the dependency risk was still real AI reliability is not only uptime anymore it is access policy regional rules model behavior fallback behavior and vendor changes so yes fable 5 is back still put AI models in your dependency register the human closer this week is about execution a repo is not just source code if opening it can trigger the assistant language server or task runner an IDE is not just an editor if it can run commands load tools and inherit credentials a waf is not just a checkbox if it only inspects the part of the request it actually sees a sandbox is not just nice to have If your product runs code from users, agents, or plugins, and an advisory feed is not useful just because it is complete, someone still has to decide what matters.

That is the platform work hiding under this episode. Modern systems are full of places where something gets permission to run, inspect, transform, or decide. Sometimes that thing is a package script sometimes it is an IDE task sometimes it is an MCP server sometimes it is a WAF parser sometimes it is a sandbox sometimes it is an AI model the better question is not only is it trusted the better question is what happens when it executes what can it reach what can it read what can it write what authority does it inherit what logs prove what happened And who owns that boundary?

Because execution is where trust becomes real. Before execution, trust is a policy. After execution, trust is a blast radius. So find the places where code runs.

Find the places where tools make decisions. Find the places where security controls parse reality on your behalf. Then make those boundaries explicit. Because execution...

is the boundary now. That's it for this week of Ship It Weekly. We covered Amazon Q and AWS Language Server CVEs, hijacked npm and Go packages using VS Code tasks, AWS WAF HTTP/2 inspection issues, Lambda microVMs, and a lightning round on GitHub Advisory Volume, Git 2.55, Valkey 9.

1, and Fable 5 coming back online. If this episode was useful, follow or subscribe wherever you're watching or listening. If you're on YouTube, hit subscribe. If you're in a podcast app, follow the show there.

And if you know someone dealing with AI coding assistants, IDE security, supply chain risk, WAF configuration, or sandboxing untrusted code, send them this one. It genuinely helps the show grow, and it helps me keep making this for people who actually live with these systems. You can find the weekly brief at OnCallBrief.com and the full show notes, links, and past episodes at ShipItWeekly.

fm. I'm Brian Teller from Teller's Tech. Thanks for listening. And remember, before execution, trust is a policy.

After execution, trust is a blast radius.