Google's developer tool was about to store a customer's artificial intelligence (AI) model at an address anyone could guess in advance. A researcher registered that address first, waited for the model to arrive, and swapped it for a poisoned version. The whole thing took 1.4 seconds, before Google itself even read the file.
The story matters less for what it says about Google and more for what it says about how we treat AI. No intelligence was outsmarted here, and no model was "hacked" by some cleverer AI. There was a predictable folder name and a check that was missing. It is one of those dull bugs we have been dragging around for twenty years, now sitting underneath the AI gold rush, where almost nobody looks at the pipes the models travel through.
An address you could write from memory
The flaw was documented by Unit 42, the research team at Palo Alto Networks, which named it "Pickle in the Middle" (an attack that sits in the middle of the road). It affects the software development kit (SDK) for Vertex AI, Google's cloud AI platform. When a developer did not pick where to store the model, the SDK made up the name of the storage "bucket" (the folder where the file lands) on its own, from public data: the project identifier and the region. The result was predictable enough to write from memory.
And the SDK only checked whether that bucket already existed, never whether it belonged to whoever was using it. All an attacker had to do was create a bucket with that name in their own account first, a technique called bucket squatting, claiming the address before the owner, so that the victim's models were delivered, quietly, into the attacker's account.
This is where it turns from theft into control. AI models in Python are usually saved in a format called pickle, which runs code the moment it is opened. Whoever controls the file can hide instructions inside it that run on the machine reading it. That is what Unit 42 demonstrated: an automated function fired the instant the upload happened and replaced the legitimate model with a poisoned one in 1.4 seconds, inside the roughly 2.5-second window that existed before Google read the file. The end of the line is remote code execution (RCE), running the attacker's commands inside the victim's infrastructure, and worse, across different customers of the same cloud. The attacker never had to break into anyone's house.
It was not bad luck, it was a pattern
Google accepted the report, marked it top priority, and fixed it in two stages: first it added a random code to the bucket name, in March, then it started checking who the owner is, in version 1.148.0 of the SDK, on 15 April. The detail that should keep us up at night is a different one. This was the second time. In February, Google had already fixed a flaw from the same family in Vertex AI (CVE-2026-2473, the public name for a known vulnerability), also through buckets with predictable names, also with models swapped between customers. When the same mistake shows up twice in the same place, it stops being an oversight and becomes a design trait.
Anyone who investigates incidents knows the rule: evidence is only worth something if the chain of custody is intact, if we know whose hands it passed through from the start. An AI model deserves the same care. Between the place where it was trained and the place where it runs, nobody should be able to touch it without leaving a trace. Here, the chain broke at the very first step, and the platform served the swapped file as if nothing had happened. This is also why Europe started treating the software supply chain as a security matter and not a logistics one: the NIS2 directive and the work of Portugal's National Cybersecurity Centre on supply chain risk rest on the same principle, that trusting a supplier is not the same as trusting everything it assembles underneath.
How to protect yourself
For anyone putting AI in the cloud, there are concrete steps:
- Update the Vertex AI SDK to version 1.148.0 or later, where the ownership check already exists.
- Never let the tool decide on its own where it stores the models: always set the destination storage bucket by hand.
- Treat a model as code, not as a harmless data file. A pickle model can run instructions when opened, so it should only come from a trusted, validated source.
- Prefer formats that do not run code when opened, such as safetensors, whenever possible.
- Watch the permissions of service accounts (the identity the system uses to authenticate), so a compromised model has nowhere to spread.
We spend the whole conversation fearing that artificial intelligence will turn against us. This week, to hijack it, all it took was a predictable name and a check nobody ran. The most advanced threat still comes in through the oldest door.
Original source: Unit 42 (Palo Alto Networks).
#StaySafe
🙏🖖
