Back to all episodes
Amazon Q CVEs, Hijacked npm and Go Packages, AWS WAF HTTP/2 Issues, Lambda MicroVMs, and Why Execution Is the Boundary Now
devopsawsgithubWAFAIagentic AIDevSecOpsnpmAmazon QVS Code
This episode of Ship It Weekly discusses critical CVEs affecting Amazon Q Developer and AWS language servers, highlighting trust-boundary issues.
Amazon Q CVEs, Hijacked npm and Go Packages, AWS WAF HTTP/2 Issues, Lambda MicroVMs, and Why Execution Is the Boundary Now
Ship It Weekly
0:00
18:06
Transcript
0:00
This week, Amazon Q Developer and the AWS language
0:03
servers had a pair of trust-boundary CVEs. JFrog
0:08
found hijacked npm and Go packages using hidden
0:12
VS Code tasks to run malware when a workspace
0:16
opens. AWS WAF had HTTP/2 request body inspection
0:21
issues. And AWS introduced Lambda MicroVMs for
0:27
running user-generated and AI-generated code
0:30
in isolated sandboxes. Put those together, and
0:34
the shape of the episode is pretty clear. Execution
0:37
is the boundary now. The repo. The IDE. The AI
0:41
assistant. The WAF. The sandbox. They all sit
0:45
at the point where something gets to run, inspect,
0:49
block, or decide. And that is where the risk
0:52
lives. I'm Brian Teller from Teller's Tech. And
0:55
this is Ship It Weekly. Welcome back to Ship
1:14
It Weekly, the show about the DevOps, SRE, cloud,
1:19
platform, and security stories that actually matter
1:22
when you're the person who has to keep the thing
1:25
running at 3 a.m. If you're new here, follow
1:28
or subscribe wherever you're watching or listening.
1:31
And if you want the weekly story list and source
1:34
links, check out OnCallBrief.com. For past episodes,
1:38
full show notes, and more from the show, head
1:41
over to ShipItWeekly.fm. This week is about
1:44
execution boundaries. Who gets to run code? Who
1:48
gets to load config? Who gets to inspect the
1:51
request? Who gets to decide whether something
1:54
is safe? We open with Amazon Q Developer and
1:58
AWS language server CVEs, then hijacked npm and
2:02
Go packages using VS Code folder-open tasks.
2:06
After that, AWS WAF and HTTP/2 request inspection,
2:12
then AWS Lambda MicroVMs, because sandboxing
2:16
untrusted code is becoming a first-class platform
2:20
problem in the lightning round we'll hit GitHub
2:23
advisory volume git 2.55 valkey 9.1 and a quick
2:29
fable 5 callback let's get into it first up AWS
2:38
disclosed two issues in language servers for
2:41
AWS and Amazon Q Developer IDE plugins. The first
2:46
one is CVE-2026-12957. AWS describes it as
2:52
improper trust-boundary enforcement. The short
2:55
version, if a user opened a malicious workspace,
2:58
commands inside project configuration files could
3:02
automatically execute. The user had to trust
3:04
the workspace when prompted, but that is not
3:07
exactly a giant comfort. Because developers trust
3:11
workspaces all the time. They clone a repo. They
3:15
open it in VS Code. They click through whatever
3:18
prompts get them back to work. And they assume
3:21
the repo is code, not a local execution trap.
3:25
The second issue is CVE-2026-12958. That one
3:31
involved symlink validation. A malicious workspace
3:34
could use a crafted symlink that resolved outside
3:38
the workspace trust-boundary both bugs point
3:41
to the same bigger problem the IDE the language
3:45
server the assistant and the project folder are
3:49
all negotiating what is trusted and that boundary
3:53
is messy it includes config symlinks workspace
3:57
trust MCP server configuration environment variables,
4:02
local files, cloud credentials, and whatever
4:05
the assistant or plugin can reach. That is why
4:08
this matters. Amazon Q Developer is not just
4:11
an editor feature. It sits near source code,
4:14
local credentials, AWS profiles, repo context,
4:19
terminals, and sometimes production access. So
4:22
when a workspace can cross into command execution,
4:26
it can become more than a local bug. It can become
4:30
a cloud credential problem, a source control
4:33
problem, a CI/CD problem. The takeaway? Update
4:37
Amazon Q Developer and the AWS IDE plugins, but
4:41
also review the operating model. Do developers
4:44
understand workspace trust? Are MCP configs reviewed?
4:49
can project config execute shell commands do
4:53
developer machines have long-lived AWS credentials
4:57
can a malicious repo jump from weird local folder
5:01
to cloud account access AI coding assistants
5:05
are becoming part of the local control plane
5:08
local control planes need boundaries not vibes
5:12
boundaries second story JFrog found hijacked
5:20
npm packages using a clever execution path. The
5:24
malicious versions were not relying on the usual
5:28
npm lifecycle scripts. No obvious preinstall,
5:31
no obvious postinstall. Instead, the payload
5:35
hid inside a VS Code task, specifically a hidden
5:39
task configured with run on folder-open. So the
5:44
trap is not just install the package and npm
5:47
runs code. The trap is open the project folder
5:51
in VS Code, trust the workspace, and the IDE
5:55
runs the task. That is a different threat model.
5:59
And it matters because the ecosystem has been
6:02
hardening the package manager path. npm version
6:06
12 is changing install script defaults. Teams
6:10
are paying more attention. to dependency execution
6:13
ci pipelines are starting to care about lifecycle
6:17
scripts that is all good but attackers adapt
6:20
if npm install gets harder they look for the
6:24
next execution surface and the IDE is a very
6:28
good one developers open folders all day example
6:32
projects reproduction repos proofs of concept
6:36
vendor samples AI generated apps Random repos
6:40
from Slack or GitHub issues. And the editor is
6:44
not passive. It runs extensions. It loads config.
6:48
It starts language servers. It runs tasks. It
6:52
reads environment. It can access terminals and
6:55
local secrets. JFrog also found additional Go
6:59
packages tied to the same malware pattern. So
7:02
this is not just an npm story. It is a workspace
7:06
execution story. The takeaway is to treat IDE
7:09
workspace trust like a security control. Watch
7:13
for hidden VS Code tasks. Pay attention to run
7:18
on folder-open. Be careful with VS Code tasks
7:22
in random repos. Do not trust every folder just
7:26
because it looks like code. And for teams using
7:30
Cursor, VS Code forks, or AI-heavy editor workflows,
7:35
this gets even more important. The package manager
7:38
is not the only place code runs. Your editor
7:42
is an execution environment now, so act like
7:45
it. Third story, AWS disclosed two AWS WAF issues
7:53
involving HTTP/2 multi-frame request body inspection.
7:59
The CloudFront case was remediated server-side
8:03
with no customer action required the application
8:06
load balancer case is the one that operators
8:09
should look at under certain conditions a crafted
8:12
multi-frame HTTP/2 request could cause only
8:17
part of the request body to be inspected that
8:21
is the sentence that matters only part of the
8:24
body gets inspected because when you put waf
8:27
in front of an application the whole point is
8:31
that the security layer sees the thing you are
8:34
trying to block. If a request is split across
8:37
frames and the inspection layer does not accumulate
8:40
enough of it before applying rules, then the
8:43
security decision may be made on an incomplete
8:46
view. That is not unique to AWS WAF. This is
8:51
a classic security control problem. The proxy,
8:54
load balancer, WAF, app server, and backend framework
8:59
all have to agree on what the request means.
9:03
If one layer parses it one way and another layer
9:06
parses it differently, attackers get room to
9:09
move. That is where parser differentials and
9:12
request smuggling-style problems come from. AWS
9:15
released a configuration option on ALB so customers
9:20
can control how WAF inspects HTTP/2 request
9:24
bodies. So this is not only a provider fixed
9:28
it story. If you use WAF with ALB and HTTP/2,
9:33
there is something to review. The takeaway? Do
9:36
not just ask, do we have WAF? Ask what it sees.
9:41
Where does TLS terminate? Is HTTP/2 involved?
9:45
Are request bodies inspected the way you think
9:49
they are? Do your ALB settings match the protection
9:53
model you are depending on? Security controls
9:56
are not magic shields. They are parsers, policies,
10:01
and defaults. And this week, the parser mattered.
10:08
Fourth story. AWS introduced Lambda MicroVMs.
10:13
This is the positive version of the same theme.
10:16
If the first three stories are about unexpected
10:18
execution paths, this one is about building a
10:22
safer place for execution to happen. AWS describes
10:26
Lambda MicroVMs as a new serverless compute
10:30
primitive for running user-generated or AI-generated
10:34
code in isolated, stateful execution environments.
10:38
You get VM-level isolation, fast launch and
10:41
resume, lifecycle control, state control, and
10:45
AWS manages the underlying infrastructure. The
10:48
use cases are easy to imagine. AI coding assistants,
10:52
interactive code environments, Plugin systems,
10:56
data platforms, vulnerability scanners. Anything
10:59
where your product needs to run code that your
11:02
team did not write. That is becoming normal.
11:06
And it is dangerous if handled casually. Containers
11:09
are useful, but shared kernel isolation is not
11:13
always the boundary you want for untrusted code.
11:17
Full VMs are stronger, but heavier. Traditional
11:20
Lambda is great. but not built for every interactive
11:24
or stateful sandbox use case. Lambda MicroVMs
11:28
are AWS trying to fill that gap. Whether you
11:32
use this specific product or not, the direction
11:35
matters. Running untrusted code is becoming a
11:38
platform feature, not an edge case, not a just
11:42
run it in Docker and hope situation, a platform
11:46
feature. The takeaway. is to inventory your execution
11:50
surfaces. Where do users, agents, plugins, tests,
11:55
scripts, or generated workflows run code? Can
11:58
that code reach internal services? Can it access
12:02
credentials? Can it write to shared storage?
12:06
Can it talk to the internet? Can state leak between
12:09
users? Can you kill it? Can you audit it? Can
12:13
you prove it is gone? Execution is not going
12:16
away. the platform has to make execution safer.
12:27
Quick lightning round. First, GitHub says its
12:31
advisory database hit a record volume. In May,
12:34
GitHub published more than 1,500 reviewed advisories,
12:39
more than five times the typical monthly output.
12:43
And even that was not enough. to keep up that
12:47
is a real DevSecOps problem vulnerability management
12:51
is becoming a queueing problem the hard part is
12:55
not getting alerts the hard part is deciding
12:58
what matters before the queue buries the team
13:01
second git 2.55 is out the useful bit is incremental
13:06
MIDX support through git repack That mostly matters
13:11
for very large repositories and hosting platforms.
13:15
But it is a good reminder that developer platforms
13:18
are infrastructure too. At enough scale, Git
13:22
performance becomes engineering productivity.
13:25
Third, Amazon ElastiCache now supports Valkey
13:28
9.1. The main angle is performance and efficiency
13:32
improvements landing in the managed AWS service.
13:37
Not every cache needs an urgent upgrade. But
13:40
cache engines are production systems. Memory
13:44
efficiency, throughput, command behavior, and
13:47
isolation matter when the cache is sitting directly
13:50
in the request path. Fourth, quick Fable 5 callback.
13:55
Anthropic's Fable 5 is back online after the export
13:59
control issue that knocked it offline. And that
14:02
does not weaken the earlier point. It strengthens
14:05
it. The model came back, but the dependency risk
14:09
was still real AI reliability is not only uptime
14:13
anymore it is access policy regional rules model
14:18
behavior fallback behavior and vendor changes
14:21
so yes fable 5 is back still put AI models in
14:26
your dependency register the human closer this
14:37
week is about execution a repo is not just source
14:42
code if opening it can trigger the assistant
14:44
language server or task runner an IDE is not
14:49
just an editor if it can run commands load tools
14:53
and inherit credentials a waf is not just a checkbox
14:57
if it only inspects the part of the request it
15:01
actually sees a sandbox is not just nice to have
15:06
If your product runs code from users, agents,
15:09
or plugins, and an advisory feed is not useful
15:13
just because it is complete, someone still has
15:17
to decide what matters. That is the platform
15:20
work hiding under this episode. Modern systems
15:23
are full of places where something gets permission
15:27
to run, inspect, transform, or decide. Sometimes
15:31
that thing is a package script sometimes it is
15:35
an IDE task sometimes it is an MCP server sometimes
15:40
it is a WAF parser sometimes it is a sandbox
15:43
sometimes it is an AI model the better question
15:47
is not only is it trusted the better question
15:50
is what happens when it executes what can it
15:54
reach what can it read what can it write what
15:58
authority does it inherit what logs prove what
16:01
happened And who owns that boundary? Because
16:05
execution is where trust becomes real. Before
16:09
execution, trust is a policy. After execution,
16:13
trust is a blast radius. So find the places where
16:17
code runs. Find the places where tools make decisions.
16:21
Find the places where security controls parse
16:25
reality on your behalf. Then make those boundaries
16:28
explicit. Because execution... is the boundary
16:31
now. That's it for this week of Ship It Weekly.
16:35
We covered Amazon Q and AWS Language Server
16:38
CVEs, hijacked npm and Go packages using VS Code
16:43
tasks, AWS WAF HTTP/2 inspection issues, Lambda
16:48
microVMs, and a lightning round on GitHub Advisory
16:52
Volume, Git 2.55, Valkey 9.1, and Fable 5 coming
16:58
back online. If this episode was useful, follow
17:01
or subscribe wherever you're watching or listening.
17:04
If you're on YouTube, hit subscribe. If you're
17:07
in a podcast app, follow the show there. And
17:10
if you know someone dealing with AI coding assistants,
17:14
IDE security, supply chain risk, WAF configuration,
17:18
or sandboxing untrusted code, send them this
17:22
one. It genuinely helps the show grow, and it
17:25
helps me keep making this for people who actually
17:28
live with these systems. You can find the weekly
17:31
brief at OnCallBrief.com and the full show notes,
17:34
links, and past episodes at ShipItWeekly.fm.
17:39
I'm Brian Teller from Teller's Tech. Thanks for
17:41
listening. And remember, before execution, trust
17:45
is a policy. After execution, trust is a blast
17:49
radius.
Amazon Q CVEs, Hijacked npm and Go Packages,…
0:00 / 18:06
🎧 Listen & Subscribe
Catch This Episode
Listen on your favorite podcast platform
💬 Commentary
Host Commentary
📝 Notes
Show Notes
This week on Ship It Weekly: 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.
The bigger theme: execution is the boundary now. The repo, the IDE, the AI assistant, the WAF, and the sandbox all sit at the point where something gets to run, inspect, block, or decide. Before execution, trust is a policy. After execution, trust is a blast radius.
In the lightning round, Brian covers GitHub’s record advisory volume, Git 2.55, Valkey 9.1 on Amazon ElastiCache, and a quick Fable 5 callback now that Anthropic’s Fable 5 is back online.
Links
AWS security bulletin: Amazon Q / AWS language server CVEs https://aws.amazon.com/security/security-bulletins/2026-047-aws/
JFrog: Hijacked npm packages using VS Code tasks https://research.jfrog.com/post/hijacked-npm-vscode-tasks-blockchain/
AWS security bulletin: AWS WAF HTTP/2 inspection issues https://aws.amazon.com/security/security-bulletins/2026-048-aws/
AWS Lambda MicroVMs https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/
GitHub Advisory Database record volume https://github.blog/security/supply-chain-security/inside-the-advisory-database-and-what-happens-when-vulnerability-volume-breaks-records/
Git 2.55 highlights https://github.blog/open-source/git/highlights-from-git-2-55/
Amazon ElastiCache Valkey 9.1 https://aws.amazon.com/blogs/database/announcing-valkey-9-1-for-amazon-elasticache/
Claude Fable 5 and Mythos 5 model docs https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
This week’s On Call Brief https://www.tellerstech.com/on-call-brief-news/2026-W27/
More episodes and full show notes https://shipitweekly.fm/
📍 Made in Greencastle, Pennsylvania
More from Ship It Weekly
All episodes →
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
This episode of Ship It Weekly discusses recent containerd CRI plugin vulnerabilities and Datadog's findings on PostgreSQL high availability failover safety.
PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking
This episode of Ship It Weekly discusses the risks of default trust in software systems. Brian covers Oracle's PeopleSoft zero-day, npm v12's install-script changes, GitHub's shift away from personal access tokens, and Anthropic's AI model removals.
CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk
This episode of Ship It Weekly discusses the implications of the CISA GitHub leak, highlighting the exposure of AWS keys and internal documentation.
AI Agents Get API Access and Identity: GitHub Copilot Cloud Agents, MCP Auth, Ansible Automation, OpenAI Daybreak, and the New Production Risk
This episode explores the shift of AI agents from coding assistants to operational actors. Topics include GitHub's REST API for Copilot cloud tasks, Auth0's MCP authentication, and Ansible as an execution layer.
This episode is about execution boundaries.
That sounds like a security phrase, but it is really a platform phrase now.
Because modern systems are full of places where something gets permission to run, inspect, transform, block, or decide.
That “something” might be an IDE extension.
It might be a language server.
It might be an AI coding assistant.
It might be a VS Code task.
It might be a WAF parser.
It might be a sandbox running user-generated code.
It might be an advisory database feeding alerts into a vulnerability management process.
The common thread is execution.
Before something runs, trust is still theoretical.
After something runs, trust becomes a blast radius.
That is why the Amazon Q Developer and AWS Language Server CVEs matter. The scary part is not just that there were bugs in an IDE plugin. The scary part is where those tools sit.
They sit next to source code.
They sit next to local credentials.
They sit next to AWS profiles.
They sit next to project configuration.
They sit next to terminals, repo context, MCP configuration, and sometimes production access.
So when a workspace can cross into command execution, that is not just a weird local developer bug. It can become a cloud credential problem, a source control problem, or a CI/CD problem.
And yes, the user still had to trust the workspace.
But that is exactly the uncomfortable part.
Developers trust workspaces constantly.
You clone a repo, open it, click through the prompt, and get back to work. That is normal behavior. But normal behavior becomes risky when the repo is no longer just source code. The repo is config. The repo is tasks. The repo is language server behavior. The repo is MCP setup. The repo is local execution context.
That is a much bigger boundary than most teams treat it as.
The JFrog story pushes that same idea even harder.
The hijacked npm and Go packages were not relying on the usual npm lifecycle-script path. They used hidden VS Code tasks configured to run when a folder opens.
That is the part that should make people pause.
The ecosystem is getting better at package-manager security. npm v12 is changing install-script defaults. CI pipelines are starting to pay more attention to dependency execution. Teams are getting more suspicious of install-time code.
That is good.
But attackers adapt.
If the package manager gets harder, they move into the IDE. And the IDE is a great execution surface because developers open folders all day.
Example repos.
Proofs of concept.
Vendor samples.
Issue reproductions.
AI-generated apps.
Random repos from Slack, GitHub issues, Discord, or wherever else work happens.
The editor is not passive anymore. It runs extensions. It loads config. It starts language servers. It runs tasks. It reads environment variables. It can access terminals and local secrets.
So “don’t run random code” is not enough advice anymore.
Sometimes “opening the folder” is the thing that runs code.
The AWS WAF HTTP/2 story is different, but it still fits.
A WAF is supposed to inspect requests and block bad ones. But that only works if the WAF sees the request the same way the rest of the stack sees it.
If HTTP/2 request bodies are split across frames, and the inspection layer only evaluates part of the body before making a decision, then the security control is operating on an incomplete view.
That is the whole problem.
Security controls are not magic shields.
They are parsers, policies, and defaults.
And if the parser has a blind spot, the policy may be correct but still not protect you.
That is why “do we have WAF?” is not the right question.
The better question is: what does the WAF actually see?
Where does TLS terminate?
Is HTTP/2 involved?
Are request bodies accumulated before inspection?
Does ALB behave the way the protection model assumes?
Do the proxy, load balancer, WAF, app server, and backend framework all agree on what the request means?
Because when those layers disagree, attackers get room to move.
Then AWS Lambda MicroVMs are the other side of the same episode.
The first few stories are about unexpected execution paths. Lambda MicroVMs are about building a better place for execution to happen.
That matters because running untrusted code is becoming normal.
AI coding assistants need sandboxes.
Users upload code.
Agents generate scripts.
Security tools analyze unknown payloads.
Data platforms run user-defined logic.
Developer platforms execute test cases.
Plugin systems need isolation.
The question is no longer “will we run untrusted code?”
For a lot of teams, the question is “where are we already running it, what can it reach, and how badly can it hurt us?”
Containers are useful, but shared-kernel isolation is not always the right boundary for untrusted code.
Full VMs are stronger, but heavier.
Serverless is convenient, but not every sandbox use case fits the traditional request-response Lambda model.
So the product direction here is interesting even if you do not adopt this specific AWS feature. Sandboxing is becoming a first-class platform primitive.
That is the larger trend.
Execution is becoming something platform teams need to design, not something they inherit accidentally.
The lightning round keeps reinforcing it.
GitHub’s advisory database hitting record volume is a reminder that vulnerability management is not just about getting more feeds. It is about deciding what matters before the queue buries the team.
Git 2.55 is a reminder that developer platforms are infrastructure too. At enough scale, Git performance becomes engineering productivity.
Valkey 9.1 on ElastiCache is a reminder that cache engines are production systems. Memory efficiency, throughput, command behavior, and isolation matter when the cache sits directly in the request path.
And the Fable 5 callback is a reminder that AI dependency risk does not disappear just because the model came back online. If a model can go away for policy reasons and then return with new access rules or behavior, that is still something reliability teams need to track.
That is why the closer lands where it does.
Execution is where trust becomes real.
A repo is not just source code if opening it can trigger an 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 part of the request.
A sandbox is not optional if your product runs code from users, agents, or plugins.
An advisory feed is not useful just because it is complete. Someone still has to decide what matters.
So the practical questions this week are pretty simple:
Where does code run?
What can it reach?
What can it read?
What can it write?
What authority does it inherit?
What logs prove what happened?
Who owns that boundary?
And if the answer is “we’re not sure,” that is the work.
Because before execution, trust is a policy.
After execution, trust is a blast radius.
Extra links worth including:
AWS security bulletin: Amazon Q / AWS Language Server CVEs
https://aws.amazon.com/security/security-bulletins/2026-047-aws/
JFrog: Hijacked npm packages using VS Code tasks
https://research.jfrog.com/post/hijacked-npm-vscode-tasks-blockchain/
AWS security bulletin: AWS WAF HTTP/2 inspection issues
https://aws.amazon.com/security/security-bulletins/2026-048-aws/
AWS Lambda MicroVMs
https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/
GitHub Advisory Database record volume
https://github.blog/security/supply-chain-security/inside-the-advisory-database-and-what-happens-when-vulnerability-volume-breaks-records/
Git 2.55 highlights
https://github.blog/open-source/git/highlights-from-git-2-55/
Amazon ElastiCache Valkey 9.1
https://aws.amazon.com/blogs/database/announcing-valkey-9-1-for-amazon-elasticache/
Claude Fable 5 and Mythos 5 model docs
https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
This week’s On Call Brief
https://www.tellerstech.com/on-call-brief-news/2026-W27/
More Ship It Weekly episodes
https://shipitweekly.fm/