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

Transcript

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.

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

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

More from Ship It Weekly

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

Get the next episode in your inbox

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

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

Related On Call Brief

More from Ship It Weekly

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

Get the next episode in your inbox