Coinbase Outage, Meta AI Account Recovery, AWS AgentCore Code Injection, Apigee Tenant Isolation, and the Glue That Breaks Production

Transcript

An AWS data hall overheats. A single availability

zone goes dark. And Coinbase spends hours recovering

systems that were not as failure-independent

as everyone hoped. Meta's AI support tooling

becomes part of an Instagram account recovery

path. And suddenly the chatbot is not just helping

customers. It is touching identity. AWS has another

agent tooling bug, this time in AgentCore CLI.

where imported agent metadata could become generated

Python code. And Google Cloud disclosed an Apigee

cross-tenant issue, which is exactly the kind

of phrase that makes cloud engineers sit up a

little straighter. The theme this week is simple.

The risky part of modern infrastructure is not

always the big obvious production system. Sometimes

it is the glue, the recovery path, the support

workflow, the generated file. the tenant boundary.

The thing everybody depends on, but nobody quite

treats like production until it breaks. I'm Brian

Teller from Teller's Tech, and this is Ship It

Weekly. Welcome back to Ship It Weekly, the show

where we look at the DevOps, SRE, cloud, platform,

and security stories that actually matter when

you are the person who eventually has to keep

the thing running. This week, we're starting

with Coinbase's May 7th outage postmortem. Then

we'll talk about Meta's AI support incident,

where attackers reportedly hijacked Instagram

accounts through an AI-assisted recovery flow.

After that, we'll get into AWS AgentCore CLI

CVE-2026-11393, where collaborator metadata

could break out into generated Python code. Then

we'll talk about Google Cloud Apigee and a cross

-tenant vulnerability, because tenant isolation

is one of those cloud promises you only think

about when it fails. In the lightning round,

we'll hit Cloudflare threat intelligence in WAF

rules, AWS Lambda tenant isolation with event

source mappings, the next generation of

OpenSearch Serverless, and GitHub Enterprise Managed

Users IP allow list coverage. So let's get into

it. First up, Coinbase published a postmortem

for its May 7th outage. And this one is worth

reading if you work anywhere near SRE, platform,

cloud, infrastructure, Kafka, financial systems,

or any system where people say we're multi-AZ

and then everyone quietly hopes that means what

they think it means. Coinbase says that trading,

deposits, withdrawals, and most customer -facing

services were unavailable or degraded for roughly

eight hours. Full recovery took even longer.

The initiating event was physical. Multiple chiller

units failed in a single AWS us-east-1 data hall,

specifically availability zone use1-az4. That

cooling issue triggered a thermal safety shutdown

of affected racks, taking EC2 instances and EBS

volumes in that building offline. That is the

part that looks like a classic cloud outage story.

Something physical breaks inside a data center

and cloud resources disappear. But the more useful

lesson is what happened next. Because most of

us already know that an availability zone can

fail. At least in theory. We have all seen the

diagram. Three boxes, three AZs, nice clean arrows,

everybody nods. Then a real failure happens,

and the system has to prove whether those boxes

were architecture or just decoration. For Coinbase,

one major issue was that the matching engine

was tied closely to the failed zone. And this

is where the nuance matters. Low latency systems

often make tradeoffs that normal apps do not.

If you need extremely tight latency, deterministic

behavior, and careful state handling, you may

choose a design that favors performance over

easy failover. And that is not automatically

irresponsible. But it does mean the recovery

path has to be real, not theoretical. Not we

documented it once. Real. Tested. Owned. Practiced.

Known by more than one person. The other big

lesson is state. Coinbase called out delays around

managed Kafka recovery. And that is extremely

relatable. During an outage, stateless compute

is usually the easy part. You restart it. You

move it. You scale it. You reroute around it.

Then you hit the system with state, ordering,

offsets, replication, partitions, or money-adjacent

semantics, and everything slows down. That is

where incidents get complicated. The app might

be multi-AZ, but what about the broker? The

database? The cache? the topic, the volume, the

thing that keeps the system honest. That is the

real test. The operator takeaway here is simple.

Do not let multi-AZ become a comfort phrase.

Find the parts of your system that are still

effectively tied to one zone, one stateful dependency,

or one recovery path, especially the low-latency

pieces, the Kafka pieces, the databases, the

matching engines, the services with ordering,

offsets, or money adjacent semantics. Then ask

the annoying question, what happens if that AZ

disappears? What depends on recovering in place?

What can actually fail over? How long does it

take? And when was the last time we proved it?

Because resilience is not where the diagram says

the boxes are. It is where the system can actually

recover when one of those boxes disappears. Second

story, Meta confirmed an incident involving its

AI-assisted Instagram support flow. where more

than 20 ,000 accounts were likely impacted. The

reported issue was that attackers could use Meta's

AI support tooling to trigger password reset

links to an email address that was not actually

associated with the victim's account. Meta described

it as a bug where the system did not properly

verify that the provided email matched the email

on the Instagram account. So attackers could

receive reset links for accounts they did not

own. Now, I know what you might be thinking.

Instagram accounts do not sound like a normal

DevOps or SRE story. But the real story is not

social media accounts got hacked. The real story

is this. AI support automation became part of

an identity recovery control plane. And that

is absolutely our lane. Account recovery is privileged

infrastructure. It is the break-glass path for

identity it can reset passwords it can change

emails it can bypass parts of the normal login

path when the user needs help that means it has

power and if ai can influence that workflow then

the ai is not just answering support questions

anymore it is participating in an identity decision

that changes everything a chatbot that answers

how do i update my profile photo is one thing

A chatbot that helps move an account recovery

flow forward is very different. That system needs

real authorization logic, real verification,

rate limits, abuse detection, audit logs, escalation

paths, blast radius controls, and a very clear

line between what AI can suggest and what the

system is allowed to do. Because attackers do

not care whether your org chart says this belongs

to support. identity, security, product, or infrastructure.

They care that the workflow can reset accounts.

So they attack the workflow. This is also a reminder

that AI risk is not always a coding agent running

shell commands. Sometimes it is much more boring.

A support flow trusts the wrong field. A reset

link goes to the wrong place. And suddenly, the

AI part gets the headline. But the real failure?

is the control boundary around the action. The

takeaway here is not AI support is bad. The takeaway

is that support workflows can be privileged infrastructure.

Password resets, MFA resets, email changes, account

recovery, support impersonation, admin ownership

changes. Those are not just customer service

features. Those are identity control paths. So

when AI gets added to that flow, The question

is not just, is the answer helpful? The question

is, what can this workflow actually do? Can it

suggest? Can it route? Can it trigger actions?

Can it change trust? And if it can touch identity,

it needs the same seriousness as any other production

control plane. Because the scariest AI system

in production might not be your coding agent.

It might be the support flow that can reset passwords.

Third story. AWS published a security bulletin

for CVE-2026-11393 in AgentCore CLI. And if

last week's Kiro bug was stdin answered

the approval prompt, this one is more like agent

metadata became Python code, which is not the

kind of sentence you want in a security bulletin.

The issue involves AgentCore CLI when importing

a Bedrock supervisor agent with multi-agent collaboration

enabled. The advisory says the CLI fetched collaborator

metadata from the Bedrock API and inserted the

collaborationInstruction field into a triple

quoted Python string in the generated main.py

file. The problem was improper escaping of triple

quotes. So a crafted instruction could break

out of that intended string and inject Python

code into the generated file. Then, if the file

was run locally or deployed into AgentCore Runtime,

the injected code could execute with the credentials

available to that environment. AWS recommends

upgrading the CLI, removing affected imported

agents rerunning the import with the patched

cli and redeploying if you cannot upgrade right

away they recommend manually inspecting generated

main.py files for suspicious triple quote sequences

in collaborator instructions now this is preview

tooling and the attack path is specific but the

pattern matters generated code is code that sounds

obvious but teams do not always treat generated

code with the same suspicion as handwritten code.

Generated files feel like outputs, artifacts,

something the tool made, something official,

something you probably do not need to read too

closely. But if untrusted or semi-trusted metadata

gets inserted into source code, your generator

becomes a compiler for attacker-controlled input.

And we have seen this movie before. SQL injection.

Template injection. Shell injection. CI config

injection. YAML templating weirdness. Now it

is agent metadata turning into Python. Different

costume, same villain. The AI angle makes it

feel new, but the secure engineering lesson is

old. Do not turn text into executable content

without a hard boundary. Do not assume metadata.

is safe because it came from an API. Do not assume

generated code is safe because it came from an

official tool. And definitely do not assume instructions

are harmless. In agent systems, instructions

are operational inputs. They can shape behavior.

They can get passed between systems. They can

become config. They can become prompts. And sometimes

they can become code. The takeaway here is short.

Generated code is still code. If a tool turns

metadata, instructions, templates, or agent definitions

into executable files, that path needs review.

Keep the CLI updated. Inspect generated files

before running them in trusted environments.

Run agent tooling with limited permissions. And

pay attention to what credentials are available

if something goes wrong. Because the blast radius

is not just the bug. The blast radius is what

the generated code can access when it runs. Fourth

story. Google Cloud disclosed a vulnerability

in Apigee, CVE-2025-13292. Google's release

notes say the issue could have allowed a malicious

actor with administrative or developer -level

permissions in their own Apigee environment to

elevate privileges and access cross-tenant data.

NVD describes it as unauthorized read and write

access to Apigee analytics data and access logs

belonging to other customer organizations. Google

says the issue was patched and no user action

is required. That is good. But the phrase that

matters is cross-tenant. Tenant isolation is

one of the deepest assumptions in cloud computing.

You have your environment. Other customers have

their environments. The provider keeps those

boundaries in place. That is the model. Most

of the time, you do not have to think about it.

And you cannot think about it all day. If cloud

customers had to constantly wonder whether another

tenant could see their logs, analytics, objects,

volumes, or traffic, nobody would get anything

done. So when a managed service has a cross-tenant

issue, even a patched one, it is worth paying

attention. And Apigee is not some random side

tool. API management sits in a sensitive part

of the stack. It can see traffic patterns, access

logs, analytics, client behavior. API paths,

timing, errors, and sometimes more than people

realize. Access logs are not always harmless.

They can reveal service names, query parameters,

client identifiers, internal routing, usage patterns.

And because logging systems are logging systems,

sometimes they capture fields everyone later

wishes had been redacted. So cross-tenant access

to analytics and logs is not just a privacy issue.

It can be a reconnaissance issue, a compliance

issue, a customer trust issue. The takeaway is

not never use managed services. That would be

ridiculous. The takeaway here is that tenant

isolation is not just a cloud provider promise.

It is a design requirement. For every platform

team building multi-tenant systems, logs, analytics,

dashboards, exports, admin tools, support consoles,

background jobs, search indexes, all of those

can become tenant boundary problems. So do not

only test the obvious request path, test the

internal paths too. Can tenant A see tenant B's

logs? Can a support view cross the wrong boundary?

Can an analytics query forget tenant context?

Can an async job mix records that should never

touch? Cross tenant bugs usually do not start

in the happy path. They start in the seams. Now

let's do a quick lightning round. First, Cloudflare

is turning threat indicators into real-time

WAF rules. Cloudflare says Cloudforce One threat

intelligence can now be used directly inside

the WAF engine. That means teams can write rules

based on things like known attacker names, targeted

industries, source countries, target countries,

and attack context. I like the direction. It

moves security from, we know this traffic is

bad, towards we can actually enforce on that

knowledge. But the operator warning is obvious.

Threat intel in the blocking path is still production

change management. Start in visibility mode.

Watch false positives. Stage the rollout. Make

sure that the logs explain why something was

blocked. Automation is great until it blocks

your biggest customer because a field matched

a little too creatively. Second, AWS published

guidance. for Lambda tenant isolation mode with

event source mappings. The interesting part is

that async systems do not naturally carry tenant

context the same way synchronous API requests

do. With an API request, you may have headers,

claims, and request context. With SQS, EventBridge,

or other event sources, tenant identity may be

inside the payload or may need to be extracted

and passed along carefully. That matters because

multi-tenant bugs love async systems. A message

loses context. A worker assumes the default tenant.

A retry uses the wrong metadata. A batch mixes

records that should never be mixed. Tenant isolation

is not just about the runtime. It is about context

propagation. especially when queues and events

are involved. Third, the next generation of Amazon

OpenSearch Serverless is generally available.

AWS says it provisions faster, scales faster,

supports scale to zero, and can reduce costs

compared to provisioning for peak load. That

is a FinOps story, but it is also an operations

story. If teams start treating search and vector

infrastructure as more elastic and disposable,

they still need to understand cold starts, latency,

indexing behavior, cost patterns, and traffic

spikes. Serverless does not mean operationally

invisible. It means the operational questions

moved. Fourth, GitHub Enterprise Managed Users

IP Allow List coverage is generally available.

Enterprises using EMUs can now enforce GitHub's

native IP Allow List configuration across user

namespaces. That matters. Because source control

is production infrastructure. Repo access is

part of your security boundary. And more of that

boundary is moving into identity, network policy,

device posture, and enterprise governance. IP

allow lists do not solve everything. But repo

access is still one of the fastest ways to turn

a credential problem into a production problem.

The human closer this week is about the glue.

Coinbase was not just an AZ failure. It was state,

latency, Kafka, and recovery paths. Meta was

not just an AI support bug. It was account recovery

becoming identity infrastructure. AgentCore

was not just a Python escaping issue. It was

metadata turning into executable code. Apigee

was not just a patched cloud vulnerability. It

was tenant isolation showing up in logs and analytics,

not just the main product path. Different stories,

same pattern. Modern reliability and security

problems keep showing up in the seams. The support

flow. The generated file. The recovery path.

The admin console. The queue. The logs. The things

between two systems that quietly decides what

is allowed to happen next. That is where a lot

of real platform work lives now. Not just making

the app scale. Not just adding another region.

Not just buying a managed service. But asking

where the authority actually sits. Who can recover

an account? Who can generate code? Who can access

another tenant's data? Who owns the failover

path? Who tested the recovery plan? And who gets

paged when the glue fails? So the takeaway this

week is simple. Do not just review the big production

systems. Review the seams. That is usually where

the incident is waiting. That's it for this week

of Ship It Weekly. We covered Coinbase's May

7th outage postmortem, Meta's AI support and

Instagram account recovery issue, AWS AgentCore

CLI CVE-2026-11393, Google Cloud Apigee's

cross-tenant vulnerability, and a lightning

round on Cloudflare WAF threat intel, AWS Lambda

tenant isolation, OpenSearch Serverless, and

GitHub Enterprise Managed Users IP allow lists.

If this episode was useful, follow or subscribe

wherever you are watching or listening. If you

are on YouTube, hit subscribe. If you are in

a podcast app, follow the show there. And if

you know someone dealing with cloud resilience,

AI support workflows, agent tooling, tenant isolation,

or repo governance, send this one to them. It

helps the show grow, and it helps me keep making

this kind of content for people who actually

live with these systems. You can find the weekly

brief at OnCallBrief.com and more episodes and

this week's show notes at ShipItWeekly.fm. I'm

Brian Teller from Teller's Tech. Thanks for listening.

And remember, the system that breaks production

is not always the big obvious service. Sometimes

it is the glue everybody forgot was holding the

whole thing together.

Coinbase Outage, Meta AI Account Recovery, AWS AgentCore Code Injection, Apigee Tenant Isolation, and the Glue That Breaks Production

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