Way back in 2012, I gave a BSidesLV talk called Big Data’s Fourth V: Or Why We’ll Never Find the Loch Ness Monster. The argument was meant to help prevent AI from being so unsafe. Everyone counts three Vs in big data: variety, volume, velocity. The fourth V is vulnerability, and it means the data itself is the attack vector. Inputs and outputs need control. Integrity of data is the future, beyond and even in opposition to confidentiality. The July 2026 HuggingFace breach is that talk brought to the headlines, which it was supposed to help prevent.
And the attacker? OpenAI announced that its own engineers ran software under evaluation that ignored its tests, used stolen credentials, found the flaw, and did the breaking in. Cliff Stoll in 1989 named this genre Cuckoo’s Egg. The cuckoo lays its egg in another bird’s nest, and the host raises the parasite. The OpenAI cuckoo, came out of an OpenAI cuckoo door, and cuckooed Hugging Face. Sam Altman admitted a “significant security incident” while his company branded the broken toy clock “unprecedented” and pitched it as proof more companies should be given the bird. HF called it mind-blowing and asked for more.

The entire HF attack chain started because a file was trusted to be what it claimed to be. Since I’m not dead yet, here are the five whys to explain what we’ve known for over a decade, each with the defensive lesson, again.
One. Why did reading a file let the attacker in?
Who studies the Trojan horse? The data was trusted to be safe (well-formed), and it was not. A malformed file in a common data format was read as if it were sound, because the reader does not fully check a file unless told to, and it was not told to. The content was the attacker’s payload.
Defense: Be more like a historian, less of a STEM head. Treat every incoming file as a claim, not a fact, and verify the claim before acting on it. When you cannot verify, refuse. The eventual fix, six weeks late, was a single validation call before use.
Two. Why didn’t the safety check catch it?
A guard had been added to the loader a few weeks earlier. It watched where files came from. It never checked whether the file’s own contents were valid. The weakness was inside the data, and the guard was looking outside the data.
Defense: put checks where the danger actually comes in, at the moment the content is interpreted, rather than rest only on the perimeter around it. Layered defense, depth as some say, is common sense.
Three. Why did one compromised machine expose the whole system?
The machines handling files from complete strangers were also trusted by the rest of the system as if they were safe. They carried a credential to the wider infrastructure (most privilege, instead of least privilege) that they never needed to do their job, and they carried it by default, until it was switched off after the breach. So an attacker landing on the most exposed machine found that it was setup to reach into everything around and behind it. This is web 101 security failure.
Defense: the parts most exposed to untrusted data should be the least trusted by everything else. Give them nothing they do not need. DMZ, RBAC, acronym soup. Learn it and why forty years of it aren’t wrong.
Four. Why was the risky change never reviewed?
The security-relevant change on the exact vulnerable path (where untrusted data was read) was written and approved by one and the same person, because the work was filed as routine data management rather than data as the attack path. A later change to the same workers, once it was labeled security, drew reviewers within minutes. Same workers, labeled appropriately as the vulnerable path of malicious data, different scrutiny. I called it out in 2012. What time is it?
Defense: classify the paths that ingest untrusted data as attack surface, and require a second reviewer there regardless of who wrote it.
Five. Why did the fix ship broken?
The tests flagged a failure and the failure was waived in writing under time pressure. A control you can switch off when you are in a hurry is not a real control. It’s a should instead of a must. The performance fetish, spray and pray, is exactly how integrity gets abandoned.
Defense: Slow is smooth, smooth is fast. On the untrusted-data path, a failing test stops the release, and no one present has the authority to wave it through.
Perhaps you can see that the through-line is the Fourth V as I have warned since forever. Variety, volume, and velocity are the popular properties everyone optimizes for to please venture hawks, and each optimization must be balanced against a real integrity check: too many formats to validate, too much data to inspect, too fast to regulate. Vulnerability is the argument for ounce of prevention to avoid pounds of cure, for whoever gets breached. Safety is the discipline of deciding in advance that the data does not get trusted, the exposed machine does not get privileges, the risky change does not get merged unseen, and the red test does not get waived.
Fail closed at each point. Think about the weakness inside the data like a historian would.
