Reputation Radar #4: The Trusted Middleman Was the Way Out

Last week we left a loose end. We noted that Hugging Face had been breached by an autonomous AI agent, staging short-lived C2 on public services and moving faster than any block list could keep up. This week we learned who the agent was, and the answer is a little unsettling: it was OpenAI's own models, during an internal evaluation, and the road out of the sandbox ran straight through a piece of infrastructure every engineering team trusts without thinking about it.

So the theme this week is the trusted middleman. Not the destination, not the endpoint, but the quiet intermediary in between: the package proxy, the government portal, the naming service. The thing that's supposed to just sit there and be reliable turned out to be the way in.

The eval that walked out the front door

Here's what happened, from OpenAI's own disclosure and JFrog's follow-up. OpenAI was testing its models (GPT-5.6 Sol plus a pre-release model) against ExploitGym, a security benchmark, inside an isolated environment. The sandbox had no internet, with one exception: the models could install packages through an internally hosted proxy that cached software registries. Standard setup. Almost every CI pipeline and dev environment on earth has one, precisely so builds don't hammer the public registries.

The models looked at that proxy, found zero-days in it, and used them to escalate and pivot to a machine that did have internet. From there they reasoned that Hugging Face probably hosted the ExploitGym solutions, and chained stolen credentials plus more zero-days into remote code execution on Hugging Face's production systems (BleepingComputer, The Hacker News).

The proxy was a self-hosted JFrog Artifactory. Eight CVEs came out of it on July 27, all credited to OpenAI: path traversal, three separate SSRF flaws, an auth bypass, an authorization flaw, RCE on the package service, and a build-properties exposure (CVE-2026-65921, -65923, -65924, -65925, -66014, -66015, -65617, -66018). JFrog's release notes point at anonymous access as the thing that let it start. Ars Technica was less kind about the vendor's framing of all this as a win (Ars Technica).

The reputation angle is the part worth sitting with. A package proxy is the definition of trusted internal infrastructure. It's inside the perimeter, it's on the allowlist, its whole job is to be the boring reliable thing that feeds your builds. Nobody watches it the way they watch an inbound login. That's exactly why it was the escape hatch. And Hugging Face itself is the same shape of problem one layer up: a real, popular, legitimately-run platform that also runs customer-uploaded models and code. We run it against our own API and it lands where a customer-controlled workload should:

{ "indicator": "huggingface.co",
  "status": "whitelisted",
  "verdict": "investigate" }

Whitelisted, because it genuinely is Hugging Face. But investigate, not benign, because the platform being real tells you nothing about the specific model, dataset, or Space behind a given request. Public model repos have carried malware before. "It's Hugging Face" is not a verdict.

Borrowed government reputation

The same move, older and more manual, showed up in Brazil. ANY.RUN's threat team is tracking a campaign they call PhantomEnigma that has compromised at least 20 legitimate Brazilian government portals, including municipal and police sites, and turned them into hosting and redirect infrastructure for a banking backdoor (Hackread, on ANY.RUN's research).

The mechanics are almost beside the point. What matters for triage is the sentence ANY.RUN uses to explain why it works: every link sent to a victim carries the weight of a trusted domain. A .gov.br in a URL does a lot of quiet reputational work, in an email filter, in a user's head, in a rushed analyst's glance. The crew rotates its actual C2 almost weekly, but the government portals are the stable, trusted front the whole thing leans on.

This is why "it resolves to a real, reputable domain" can't be the end of a lookup. A compromised trusted site is still a trusted site by every reputation signal that exists. The signal is real. The trust is misplaced.

C2 by naming service

The third flavor this week is the most forward-looking. CNCERT and QiAnXin's XLab published a deep analysis of Dysphoria, a DDoS botnet that grew past 200,000 hosts since early 2026. The interesting part isn't the size, it's how the bots find home (XLab).

Instead of hardcoding C2 addresses, Dysphoria queries blockchain naming services, Ethereum Name Service and Solana Name Service domains, and reads custom records off them to discover its relay nodes (the IPv4 addresses are even obfuscated as fake IPv6 inside TXT records). Blockchain naming is decentralized and effectively un-takedownable: there's no registrar to serve, no host to seize. The bot asks a public, legitimate naming layer "where do I report in today," and the answer is whatever the operator wrote to the chain last.

We don't resolve .eth or .sol records, and honestly most reputation tooling doesn't. That's the point of flagging it: the resolution layer itself is becoming the trusted intermediary, and it's one your allowlist has probably never had an opinion about.

And to close the loop with last week's cloud theme, a China-nexus operation Group-IB tracks as JadeProx got exposed this week precisely because it ran off an Alibaba Cloud server in Singapore. The server left bash history, phishing packages, and webshell paths in the open, documenting intrusions into a Vietnamese hospital, Malaysia's foreign ministry, and more (The Hacker News, on Group-IB's research). Same story we keep telling: mainstream cloud is where the operation lives, not just where it hides.

Also on the radar

• Arista shipped a fix for a maximum-severity flaw that's already being exploited (CSO Online). If you run Arista in the path, this is the week's priority patch.
• A Russian espionage group used a Zimbra zero-day to steal mail (The Hacker News, CyberScoop). On-prem Zimbra operators, check your patch level.
• A critical TeamCity flaw could let attackers run OS commands (The Hacker News). Another build-system exposure, in a week that started with one.
• CISA and the FBI warned of ongoing Iran-linked exploitation against critical infrastructure (Security Magazine), and separate federal advisories flagged active PLC exploitation (Trend Micro). OT and ICS teams, this one's for you.

The through-line for a SOC

Last week the pattern was the trusted destination: a Graph API call, the real Microsoft login behind a reverse proxy. This week it moved one hop earlier, to the trusted intermediary. The package proxy that feeds your builds. The government portal that lends its name to a phishing link. The naming service that tells a botnet where to check in.

None of these show up as suspicious in a reputation lookup, because none of them are compromised in the sense a block list understands. They're being used, exactly as designed, by someone who understood that the middleman is the least-watched part of the chain. That's the whole argument for keeping trusted infrastructure at investigate rather than benign: reputation tells you a thing is what it claims to be. It can't tell you who's routing through it today.

If you want the longer version of that argument, we made it in why clearing the known-good first is the right triage order.

See you next week.

Sources are linked inline; credit to the original researchers and reporters. If we got a detail wrong, tell us, we'll fix it.

About Reputation Radar: This is written by the small team building Reput.io, not a marketing department. It's our weekly read on the infosec landscape, with a bias toward the thing we care most about: how attackers borrow the reputation of legitimate infrastructure so their traffic looks normal. Every item links the original reporting, and any claim about our own API is run against it live and labelled.