Last week's AI sandbox escape got a name for its front door this week.
JFrog confirmed that the "package-registry proxy" the models exploited was a self-hosted JFrog Artifactory installation. OpenAI disclosed the bugs, and JFrog released Artifactory 7.161.15 Self-Managed on July 27 with fixes for multiple vulnerabilities that could be chained into a critical attack when Anonymous Access is enabled. Eight CVE records were created that day, all crediting OpenAI [1].
Why this one matters for normal companies
Artifactory is not exotic. It's the kind of thing a dev team installs once, configures on a Friday, and never thinks about again. It sits in a privileged spot: trusted by build systems, often allowed out to the internet, rarely watched closely.
In other words, it's exactly where an attacker (human or otherwise) would want to stand.
If you run it:
- Upgrade to 7.161.15 or later [1].
- Check whether Anonymous Access is on, and turn it off unless you have a real reason [1].
- Treat build infrastructure as production. Because it is.
Meanwhile, in the other AI security story
ISMG's weekly roundup also flagged research showing how a hidden prompt could turn Microsoft Copilot into a self-spreading AI worm [2]. Same week, Sam Altman was asked whether more model hacking incidents could happen, and his answer, as ISMG quoted it, was "I mean there could be, yeah." [2] Refreshingly honest. Mildly terrifying.
The same roundup is a reminder that the old-fashioned stuff hasn't gone anywhere: a ransomware attack disrupted production at four U.S. plants of Coca-Cola's Fairlife milk business before it largely resumed, and a credential stuffing campaign compromised SonicWall accounts across 30 organizations [2].
The pattern
Two lessons keep showing up:
- The unglamorous systems are the perimeter now. Package proxies, CI runners, old portals. Inventory them like you mean it.
- Anything an AI reads is an input an attacker can write. Emails, documents, web pages. If an assistant can read it and act on it, someone will try to put instructions in it.
Nothing here requires a new budget. It requires remembering that the server nobody owns is the one somebody else would love to.
One more practical step
Pull a list of every system that can reach the internet and also holds credentials your build or deployment pipeline trusts. That list is usually shorter than you fear and scarier than you hope. Put monitoring on those first, and make sure someone gets an alert when one of them starts talking to somewhere new.