GitHub RCE, AI Agent Prompt Injection, and the New Reality: Your Developer Toolchain Is Production Now

Transcript

Developer tooling used to feel like the safe

part of the system. Production was the scary

place. The database, the cluster, the load balancer,

the pager. And then everything around that was

just tooling. GitHub, CICD, merge queues, package

publishing, code review bots, AI agents. But

that line is getting harder to defend. Because

when the tooling can merge code, publish artifacts,

leak secrets, spend money, or decide what gets

shipped, it is not just sitting beside production

anymore. It is part of production. And this week,

that idea showed up everywhere. Hey, I'm Brian

Teller. I work in DevOps and SRE, and I run Teller's

Tech. This is Ship It Weekly, where I filter

the noise and focus on what actually changes

how we run infrastructure and own reliability.

Show notes and links are on shipitweekly .fm.

If this show's been useful, follow it wherever

you listen. Ratings help way more than they should.

And if you are watching on YouTube, subscribe

there too. We have six main stories today, then

the lightning round, and we'll wrap with the

human closer. We're starting with GitHub's critical

Git Push remote code execution vulnerability,

including the AI reverse engineering angle from

Wiz. Then we'll talk about prompt injection against

AI agents tied into GitHub workflows. After that,

Elementary's CLI supply chain incident, where

a GitHub actions workflow became the path to

a malicious release. Then GitHub's April 23rd

Merge Queue regression. Then cal .com going closed

source, which is probably the most argument -starting

story in this set. And finally, GitHub Copilot

moving to usage -based billing because AI tooling

is becoming a governance and cost management

problem, not just a productivity experiment.

Then in the lightning, we'll hit MinIO, Ghostty,

Docker -hardened images, and Azure DevOps security

updates. Story one. GitHub's GitPush RCE is a

toolchain wake -up call. Let's start with GitHub.

GitHub disclosed a remote code execution vulnerability

in the GitPush pipeline. The issue affected GitHub

.com, GitHub Enterprise Cloud, GitHub Enterprise

Cloud with Data Residency, Enterprise Managed

Users, and GitHub Enterprise Server. GitHub says

Wiz reported the bug through the bug bounty program

on March 4th. GitHub reproduced it internally

within about 40 minutes, fixed GitHub .com in

under two hours, and says it found no evidence

of exploitation. That is the reassuring part.

The uncomfortable part is the shape of the bug.

The vulnerability involved user -supplied Git

push options. Those push options ended up influencing

internal metadata passed between GitHub services.

Because of how that metadata was formatted, an

attacker could inject extra fields that a downstream

service treated as trusted internal data. And

once user input can shape trusted internal metadata,

things get ugly fast. GitHub says the researchers

showed they could override the environment where

the push was processed, bypassing sandboxing

around hook execution, and ultimately execute

arbitrary commands on the server handling the

push. That is a lot hiding behind the phrase

Git push. And that is why this belongs in a DevOps

and SRE conversation, not just a security newsletter.

Every team treats Git as normal plumbing. Humans

push code. Bots push code. Automation responds

to pushes. CI kicks off. Release workflows start.

Security scanners run. Deployment paths wake

up. But behind that one command is a hosting

platform. Internal service boundaries. Hook execution.

Sandboxing. Audit logs. And identity. That is

infrastructure. For GitHub .com and enterprise

cloud users, GitHub says the platform was patched

and no customer action is needed. For GitHub

enterprise server customers, this is a patch

now situation. GitHub specifically recommends

upgrading supported G -H -E -S releases and reviewing

audit logs for suspicious push operations. But

the bigger story may be how Wiz found it. Dark

reading covered the AI -assisted reverse engineering

side. Wiz used AI tooling to help analyze GitHub

Enterprise Server, understand compiled binaries

and internal service behavior, and find a bug

that historically may have taken weeks or months

to uncover. They reportedly went from the idea

to working exploit in under 48 hours. That is

the part that should stick with us. Not because

AI found a bug, like the robot woke up and became

a hacker. The real story is that AI lowered the

cost of understanding complex systems. A lot

of software has been protected informally by

being annoying. Hard to reverse engineer. Hard

to understand. Too much glue. Too many binaries.

Too many internal assumptions. That was never

real security, but it was friction. And friction

matters. If AI removes enough of that friction,

then systems that were probably fine because

nobody will spend the time become more interesting

targets. So the takeaway is not panic. It is

that boring security engineering matters more

when discovery gets faster. Input validation.

Trust boundaries. Least privilege. Patch velocity.

Audibility. Because when the cost of finding

bugs drop, the cost of sloppy assumptions go

up. Story 2. Prompt injection is now in the CI

-CD blast radius. Next up, AI agents and GitHub

actions. The register covered research showing

prompt injection attacks against AI agents from

Anthropic, Google, and Microsoft tied to GitHub

workflows. The basic shape is pretty simple.

AI agents read GitHub data, pull request titles,

issue bodies, issue comments, review comments,

markdown, the stuff developers and contributors

write all day. So if an attacker can place malicious

instructions into that data and an agent later

processes it with access to tools or secrets,

the attacker may be able to steer the agent.

In the Claude case, researchers showed that a

malicious PR title could influence the bot and

leak credentials into a review comment. With

Gemini, issue comments and prompt injection were

used to expose an API key. With GitHub Copilot

Agent, malicious instructions could be hidden

in an HTML comment that humans would not see

in rendered markdown. The victim assigns the

issue to Copilot, but the payload is already

sitting there in the context. The researchers

demonstrated theft of Anthropic and Gemini API

keys, multiple GitHub tokens, and potentially

any secret exposed to the GitHub Actions Runner

environment. That last phrase is the one I care

about. The GitHub Actions Runner environment.

Because this is not just an AI story. This is

a CICD story. If your agent runs in GitHub Actions,

and GitHub Actions has access to tokens, deployment

credentials, package publishing rights, cloud

permissions, Slack webhooks, or JIRA credentials,

then prompt injection becomes part of that blast

radius. The researcher called this comment and

control, which is a play on command and control.

And it fits. The attacker may not need malware.

They may not need an external callback. They

may not need to trick a human into clicking anything.

They can write data into GitHub, let automation

read it, and let the automation leak the secret

back into GitHub. That is a nasty little loop.

And this is where I think teams are a little

too cautious about agents. A code review bot

should not have more access than it needs. An

issue summarizer should not have repository write

access. A documentation bot does not need cloud

keys. And if you are passing untrusted GitHub

content into an agent that can use tools, run

commands, or read secrets, that is not a harmless

productivity flow. That is untrusted input hitting

an execution environment. We have had that category

of problem for decades. AI did not invent it.

AI just made the parser weird. Story 3. Elementary's

CLI incident is the supply chain story in miniature.

Now let's talk about elementary. Elementary Data

published a security incident report for a malicious

release of the elementary open source Python

CLI version 0 .23 .3. On April 24th, a malicious

CLI package was published to PyPI, and a malicious

Docker image was published to their registry.

Those artifacts were not produced by the elementary

team. According to elementary, the attacker opened

a PR with malicious code and exploited a script

injection vulnerability in one of their GitHub

actions workflows to publish the release. That

is the modern supply chain anxiety loop in one

story. A pull request. A workflow vulnerability.

a release -looking artifact, PyPI, Docker, and

downstream users who now have to assume any credentials

accessible to the environment where that CLI

ran may have been exposed. Elementary removed

the malicious release, published a safe 0 .23

.4, removed the vulnerable workflow, rotated

affected credentials, and moved the OIDC authentication

where possible. That response sounds pretty solid,

but the attack path is the real lesson. A lot

of teams still think of GitHub Actions as a convenience

layer. But for many projects, GitHub Actions

is the release authority. It builds containers.

It publishes packages. It signs things. It pushes

to registries. It decides what gets shipped.

So if that workflow has script injection, broad

permissions, long -lived tokens, or too much

trust in PR -controlled input, then your release

system can become the attack path. The question

is not only do you trust your source code? It

is also do you trust the automation that turns

source code into artifacts? Those are not the

same question anymore. You can have a clean main

branch and a vulnerable release workflow. You

can have signed releases and a compromised signing

path. You can rotate app credentials and still

forget that the package publisher token has been

sitting in CI forever. So the practical playbook

is boring but important. Check workflow permissions.

Avoid long -lived publishing tokens where OIDC

is available. Be careful with shell interpolation

from PR titles, branch names, issue comments,

tags, and commit messages. Split, build, and

publish. Protect release environments. And threat

model GitHub Actions like production. Because

if GitHub Actions can publish your package, it

is production. It might not serve customer traffic,

but it controls customer trust. Story four, GitHub's

merge queue regression is a control plane reliability

story. Next one is also GitHub, but from a reliability

angle. On April 23rd, GitHub had a merge queue

regression. GitHub says whole requests merged

through merge queue using squash merge produced

incorrect merge commits when a merge group contained

more than one pull request. In some affected

cases, changes from previously merged PRs and

prior commits were accidentally reverted by later

merges. GitHub says that 658 repositories and

2 ,092 pull requests were affected. No data was

lost because the commits still existed in Git.

But affected default branches ended up in an

incorrect state. And GitHub could not safely

repair every repository automatically. That is

a painful incident. And it is painful because

merge queues exist to reduce risk. That is the

whole point. They are supposed to make high -change

environments safer. Instead of everyone racing

to merge against a moving base branch, the queue

group changes, validates them, and lands them

in a more orderly way. So when that control plane

gets a bad behavior, it creates a weird kind

of incident. Not the site is down. Not the database

is corrupted. But the mechanism we trust to preserve

correctness just produced a branched state that

is not what we think it is. That is subtle. And

subtle is dangerous. Because if a deploy fails

loudly, you know. If an API goes red, you know.

If a merge queue quietly reverts earlier changes,

you might not notice until the wrong code is

already in production. The practical takeaway

is not don't use merge queues. I still like merge

queues. The takeaway is that any environment

with merge authority needs SRE thinking. Good

audit trails. Easy ways to identify what changed.

Detection when a branch state does something

weird. Clear ownership when the thing that protects

main becomes the thing that damages main. Merge

queues, feature flag systems, CI schedulers,

artifact registries, deployment orchestrators,

GitOps controllers. These are control planes.

They may not be in the request path, but they

shape what production becomes. Story five. Cal

.com going closed source is the argument everyone

will want to have. Now for the spicy one. Cal

.com announced that it is going closed source.

They said that after five years as open source

champions, they are moving the production code

base closed because AI has changed the security

landscape. Their argument is basically this.

In the past, exploiting an application required

skilled humans. time, and patience. Now AI can

be pointed at an open -source codebase and used

to systematically scan for vulnerabilities. Cal

.com says that being open -source is increasingly

like giving attackers the blueprints to the vault.

They are keeping an open version available as

cal .diy under the MIT license. But they say

that the production Cal .com codebase has diverged,

including rewrites in areas like authentication

and data handling. I have mixed feelings on this

one. On one hand, I understand the concern. This

week's GitHub and Wiz story gives some support

to the idea that AI can make vulnerability discovery

faster and cheaper. If you run a SaaS product

handling sensitive calendar data, authentication

flows, integrations, and customer information,

it is not crazy to worry about AI -assisted vulnerability

mining. On the other hand, closed source equals

safer is not a clean argument. Closed source

software still gets reversed. Closed source software

still has bugs. Closed source software can lose

the benefit of external review. And hiding code

is not the same as securing it. So I would not

frame this as cal .com is right or cal .com is

wrong. The better framing is that AI is putting

real pressure on the business and security model

of commercial open source. For maintainers, open

source can mean transparency, community, contributions,

and trust. For customers, it can mean self -hosting,

auditability, and less vendor lock -in. For attackers,

it can mean a searchable map of the systems.

And for a commercial company, it may mean all

of those things at once, plus support burden,

vulnerability reports, hosted customer risk,

and investor pressure. That tension is not new.

AI just makes it louder. For platform teams,

the takeaway is not stop using open source. That

would be ridiculous. The takeaway is stop treating

project governance and licensing as background

noise. When a project changes its source model,

repo model, release model, or commercial posture,

that is supply chain signal. You do not have

to panic, but you should notice. Story six, co

-pilot usage -based billing makes AI a governance

problem. Last main story. GitHub Copilot is moving

to usage -based billing on June 1st. GitHub says

all Copilot plans will transition to GitHub AI

credits. Instead of counting premium requests,

plans will include a monthly credit allotment,

and usage will be calculated based on token consumption,

including input, output, and cached tokens. Base

subscription prices are not changing, according

to GitHub. Code completions and next edit suggestions

stay included. But agentic usage, longer sessions,

heavier models, and multi -step workflows move

more directly into the cost model. And one detail

jumped out at me. Copilot code review will also

consume GitHub Actions minutes in addition to

GitHub AI credits. That is what makes this a

platform engineering story. Because now AI usage

is not just a seat cost. It is tokens, model

choice, cached context, review automation. actions

minutes, budget controls, and admin visibility.

And this is the normal cloud story happening

again. First, it feels magical. Then everyone

adopts it. Then the bill shows up. Then leadership

asks, why is it growing? Then teams discover

they do not have tagging, budgets, ownership,

quotas, or usage visibility. Then platform teams

get asked to govern it after it is already everywhere.

We saw this with cloud. We saw it with observability.

We saw it with CI minutes. Now we are going to

see it with AI -assisted development. I am not

anti -copilot. I use AI tools constantly. But

the economics are changing. A quick autocomplete

suggestion and a multi -hour agentic coding session

are not the same cost profile. A lightweight

code explanation and a repo -wide refactor are

not the same cost profile. A human asking a few

questions and an agent iterating across a codebase

are not the same cost profile. GitHub is saying

that more directly now. And teams should probably

take the hint. If AI behaves like cloud spend,

you need cloud spend habits. Visibility. Ownership.

Guardrails. Budgets. And somebody who notices

before the bill becomes the incident. A few quick

ones before we wrap. MinIO's main GitHub repo

was archived by the owner on April 25th and is

now read -only. The readme says the repository

is no longer maintained and points users towards

other options. It also says that the community

edition is now source -only and that legacy pre

-compiled binaries will not receive updates.

That is a big dependency signal if you have MinIO

in your stack. Ghostty is leaving GitHub. Mitchell

Hashimoto wrote that Ghostty plans to move off

of GitHub while keeping a read -only mirror at

the current URL. The interesting part is his

framing. He says the problem is not Git itself.

The problem is the surrounding infrastructure

that people rely on. Issues, pull requests, actions,

and platform workflows. Git may be distributed,

but your actual engineering workflow usually

is not. Docker published a one -year reflection

on Docker -hardened images. They say Docker -hardened

images crossed 500 ,000 daily pulls with more

than 2 ,000 hardened images, MCP servers, Helm

charts, and ELS images. That is a nice counterweight

to the rest of the episode. Not every supply

chain story is a compromise. Some of the work

is making safer defaults easier to adopt. Azure

DevOps added one -click CodeQL setup and org

-wide alert triage to advance security. Microsoft

says teams can enable code scanning at the repo,

project, or organization level without manually

configuring a pipeline. And security admins get

a combined alerts view across repositories. Not

super flashy, but useful when security has to

scale beyond fixing repo number 417 by hand.

I think the human thread this week is that engineers

are still emotionally treating developer tooling

like it lives outside the blast radius. And it

does not. The build system is not outside the

blast radius. The merge queue is not outside

the blast radius. The package publisher is not

outside the blast radius. The AI review bot is

not outside the blast radius. GitHub Actions

is not outside the blast radius. Copilot billing

is not outside the governance conversation. The

open source project that you depend on is not

outside your supply chain just because you starred

the repo five years ago. All of this is part

of production now. Maybe not production in the

narrow sense, maybe not serving customer traffic

at this exact second, but production in the operational

sense. If this breaks, we cannot ship. If this

is compromised, customers may be affected. If

this gets expensive, leadership will care. If

this silently does the wrong thing, production

may become wrong later. If this changes its licensing

or maintenance model, our roadmap may get weird.

That is production. And I think that that shift

is hard because developer tooling used to feel

like the comfortable part of engineering. It

was where we moved fast, where we automated things,

where we glued things together with tokens and

YAML and a little bit of we'll clean this up

later. But the shortcut became the path, and

the path became the control plane. And the control

plane now has secrets, merge authority, release

authority, billing impact, AI behavior, and platform

dependency risk. That does not mean every team

needs to panic. It means we need clearer labels.

A GitHub Actions workflow that publishes to PyPI

is not just CI. It is a release system. A merge

queue that lands code on main is not just a productivity

feature. It is a source control control plane.

An AI agent with repo access and secrets is not

just a bot. It is a principal with tools. An

open source dependency whose repo gets archived

is not something to look at later. It is a dependency

management event. And a co -pilot billing change

is not just pricing. It is a governance signal.

Once you label the system correctly, you can

manage it correctly. You can put the right permissions

around it. You can monitor it. You can budget

for it. You can patch it. You can separate trusted

and untrusted input. You can stop pretending

that the thing with keys to production is somehow

not production. Reliability is not just keeping

servers up. It is keeping the paths to production

trustworthy. And this week, those paths looked

a little more serious than usual. Alright, that's

it for this week of Ship It Weekly. Quick recap.

GitHub patched a critical Git push remote code

execution vulnerability. And the AI -assisted

reverse engineering angle may be just as important

as the bug itself. Researchers showed prompt

injection attacks against AI agents tied into

GitHub workflows, which is a pretty clear reminder

that agents are now in this CI -CD blast radius.

Elementary Data dealt with a malicious CLI release

published through a vulnerable GitHub Actions

workflow. GitHub had a merge queue regression

that affected more than 600 repositories and

more than 2 ,000 pull requests. Cal .com is going

closed source and putting a spotlight on the

tension between AI, security, open source, and

business models. And GitHub Copilot is moving

towards usage -based billing, which means AI

tooling is becoming a cost and governance conversation,

not just a productivity conversation. Then in

the lightning round, we hit MinIO archiving its

main repository, Ghostty leaving GitHub, Docker

hardening images crossing 500 ,000 daily pulls,

and Azure DevOps making CodeQL setup and org

-wide alert triage easier. Links and show notes

are on shipitweekly .fm. You can also find the

video version on YouTube. If this episode was

useful, send it to the person on your team who

still says it's just CI. I'm Brian, and I'll

see you next week.

GitHub RCE, AI Agent Prompt Injection, and the New Reality: Your Developer Toolchain Is Production 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

GitHub RCE, AI Agent Prompt Injection, and the New Reality: Your Developer Toolchain Is Production 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