How ShinyHunters Ate a Hundred Schools

I’ll preface with this is best effort from the public record and my own read of it. I don’t work for Oracle, Google, or anyone else named here, and I have no inside knowledge of what happened inside any of the victim networks. Everything below is stitched together from Oracle’s security alert, Mandiant’s writeup, the NVD entry, and CISA’s KEV catalog. If I got something wrong, tell me.

If you run PeopleSoft, June was a rough month. If you run it at a university, it may have been a genuinely awful one, and you might not even know it yet.

Here’s the short version before I get into it. Somebody found a door on Oracle PeopleSoft that forgot to ask who was knocking. They walked through it, quietly, for about two weeks before anyone knew the door existed. By the time Oracle shipped a patch and CISA started sounding alarms, a crew called ShinyHunters had reportedly touched more than a hundred organizations, and roughly two out of three of them were schools.

I usually write about the guts of a bug: the memory, the primitive, the clever trick. This one’s different, and that’s exactly why I wanted to write it. There’s no clever trick here. The bug is almost embarrassingly simple. What makes it worth your time is everything that happened after the bug, because that’s the part that turns “a vulnerability” into “a campaign,” and it’s the part most people never get to see laid out end to end.

Before I get into the technical angle people probably came here for, a few things I think are worth sitting with:

• A missing authentication check is not an exotic failure. It’s the most human kind of mistake there is: somebody built a thing and forgot to ask “wait, should this be locked?” That happens on every team, everywhere, and it will keep happening.
• The two weeks between “in use against real targets” and “the vendor tells you it exists” is where the whole story lives. During that window, every affected admin on earth had a clean scorecard and no idea.
• Almost none of what the attackers did after getting in was “hacking” in the dramatic sense. They mostly used the same tools your own IT team uses. That should bother you more than a fancy exploit would.
• And the victims here weren’t a random spread. They were disproportionately schools, and that isn’t bad luck. It’s a structural thing worth understanding, because the reasons higher ed got hit are the same reasons it’ll get hit again.

Those are the conversations I hope this kicks off. But first, what actually happened…

So what’s a “missing auth check,” really

Most of the scary bugs I write about are about fooling software into doing something it was built to refuse. This one’s dumber than that, and honestly worse.

Picture a building where every door has a badge reader except one. That one got added late, by a contractor, for maintenance, and nobody ever wired it into the badge system. It isn’t hidden. It isn’t even locked. If you know it’s there, you just turn the handle and walk in. No lockpick, no forged badge, no cleverness. You just use the door that everyone assumed was connected to something.

That’s CVE-2026-35273. The formal name is a mouthful, “Missing Authentication for Critical Function,” which is a precise way of saying: an important function was sitting on the network with no check on who was allowed to call it. Oracle rates it a 9.8 out of 10. Unauthenticated, over the network, over plain HTTP, and the payoff is full takeover of the product. No password. No user account. No session. Just a door.

(A couple of researchers have argued about whether the underlying flaw is technically a request-forgery bug rather than a pure missing-auth one. I’ll let them have that fight. From where you sit on the receiving end, the effect is identical: something answered a stranger it never should have.)

The door nobody was watching

The unlocked door here lives in a corner of PeopleSoft called the Environment Management Hub, the PSEMHUB if you go grepping your own logs, and it affects PeopleTools 8.61 and 8.62.

If you don’t live in PeopleSoft land, here’s the context that makes this land. PeopleSoft is the backbone that a huge chunk of universities, agencies, and big enterprises run their world on: HR, payroll, financials, and at a lot of schools, the entire student records system. The Environment Management Hub is deep internal plumbing, the piece that helps admins push updates and keep environments in sync. Nobody ever meant for it to face the internet. Which is exactly why nobody was watching it. It’s boring infrastructure, and boring infrastructure is where the bodies get buried, because “boring” is another word for “nobody’s looking.”

And here’s the part that should put a knot in your stomach: the attackers were in there before anyone knew the door existed. Mandiant places the active exploitation between May 27 and June 9, 2026. Oracle’s alert and emergency patch didn’t land until June 10. So for the better part of two weeks this was a live zero-day, being worked quietly against real targets, while every affected admin in the world was looking at a green dashboard.

CISA didn’t waste time once it was public. They added it to the KEV catalog on June 12, flagged it for known ransomware use, and set a remediation deadline of June 15. Three days. When the federal patch clock gets set to seventy-two hours, that’s the government’s way of quietly telling you this one is already hurting people.

What they actually did once they were in

This is the part I find genuinely instructive, because almost none of it looks like hacking. Once they were through the door, the crew, which Mandiant tracks as UNC6240 and the rest of us know as ShinyHunters, ran a playbook that any working sysadmin would recognize as the exact tools they use every day.

• They dropped a webshell. Unexpected .jsp files landed in the PSEMHUB.war directory on the WebLogic server. A webshell is just a little script that turns a web request into a command prompt. Now the unlocked door is a permanent one, and it takes orders.
• They set up C2 that looks like your help desk. For their command channel they didn’t write custom malware. They installed MeshCentral, a legitimate open-source remote-management tool, the same category of thing a real IT department uses to fix your laptop from across the building. Their agents beaconed out to a hostname (azurenetfiles.net) picked specifically to look Microsoft-flavored and boring. To most monitoring, a MeshCentral agent chatting over 443 looks like IT being IT.
• They sprayed credentials. From there they used sshpass to automate SSH logins across internal machines, the digital version of walking down a hallway trying one key in every lock. No exploit needed. Just reused and guessed passwords, at machine speed, across a network where the hosts all trusted each other.
• They shipped the data out. They compressed the loot and pushed it over SSH to a server Mandiant tied to the public mirror of the ShinyHunters leak site. And then the extortion clock starts ticking.

Read that list again and notice what’s missing: malware. Apart from the webshell, every tool in that chain, MeshCentral, SSH, sshpass, is something you’d find on a legitimate admin’s box on a normal Tuesday. That’s not the attackers being lazy. That’s them being good. Custom malware trips alarms; a remote-management agent and a handful of SSH sessions just melt into the background hum of a busy IT shop. This is what “living off the land” actually means in practice, and it’s why “we didn’t find any malware” is such a hollow thing to be reassured by. There wasn’t supposed to be any.

Why schools

Here’s the number that turned this from a CVE into a headline: of the 100-plus organizations Mandiant notified, 68% were in higher education, most of them in the US.

Let me be careful with that number, because the coverage tends to smear it. “Notified” is not “breached.” That 68% is the sector breakdown of everyone Mandiant flagged as touched by this activity, not a confirmed count of ransacked schools. And 68% of this particular set doesn’t say anything about universities as a share of some larger whole. When you’re the one writing the number down, the precision is the job.

But even with those caveats, the concentration is real, and it isn’t an accident. Higher ed is, structurally, one of the softest large targets in the country, and I say that as someone who genuinely loves how open academia is:

• A university isn’t one network, it’s dozens. Every department, lab, and college grew its own systems over decades. Central security often can’t even see everything, let alone patch all of it inside seventy-two hours.
• The ERP can’t just go down. PeopleSoft at a big school runs registration, financial aid, payroll. You don’t casually yank that offline for an emergency patch in the middle of a term.
• The data is rich and the budgets are thin. Universities sit on SSNs, financial-aid records, health data, and decades of alumni PII, guarded by security teams that are perpetually outnumbered by the sprawl they’re defending. High value, low friction. Extortion crews do that math too.

The 68% isn’t ShinyHunters being sentimental about schools. It’s them being efficient. If you’ve got an unauthenticated PeopleSoft takeover in your pocket, higher ed is simply where that one key opens the most doors for the least effort.

Who ShinyHunters are, and one thing not to mix this up with

ShinyHunters aren’t new, and they aren’t really a “group” in the tidy org-chart sense. They’re a financially motivated data-theft-and-extortion crew orbiting the loose English-speaking cybercrime scene people call the Com, the same murky pool that gave us LAPSUS$ and Scattered Spider. Resecurity has written about the overlap between these crews as a kind of “Trinity of Chaos”, and the membership is fluid enough that arguing over exact boundaries is mostly a waste of breath.

What actually matters is where they’re headed. This is the crew tied to the Snowflake mass-extortion wave and the Salesloft Drift / Salesforce OAuth-token campaign, both of them cloud and SaaS plays built on stealing tokens and abusing trust between services. PeopleSoft is a pivot. They’ve gone from picking SaaS locks to kicking down on-prem enterprise-application doors. That shift is the part I’d actually keep my eye on. A crew that just proved it can turn one on-prem ERP zero-day into a hundred-victim campaign is a crew that’s now out shopping for the next one.

If you’re the one who has to deal with it

None of the fixes here are exotic. They’re just the tedious stuff, which is its own kind of hard.

• Patch PeopleTools, then go hunting anyway. Oracle’s out-of-band fix landed June 10, so apply it. But because this ran as a zero-day for two weeks first, patching is necessary and not sufficient. Go look for the tells: unexpected .jsp files under PSEMHUB.war, a MeshCentral agent nobody remembers installing, outbound traffic to that azurenetfiles.net C2, a storm of SSH auth failures across internal hosts. The patch shuts the door. It won’t tell you who already walked through it.
• Get the hub off the internet. The Environment Management Hub was never supposed to face the world. If yours is reachable from outside, that’s the real root cause, not the CVE. Put internal plumbing back behind the VPN where it belongs.
• A flat network is how one door becomes a hundred. That credential spray only worked because the internal hosts trusted each other so freely. Segmentation and SSH key hygiene are the difference between “they got one box” and “they got the building.”
• Alert on your own tools acting strange. You will not catch this by hunting for malware, because there wasn’t any. You catch it by noticing that a remote-management agent showed up on a server that has no business running one, or that a single host suddenly started SSHing to fifty others. The tell isn’t a virus signature. It’s your own infrastructure behaving unlike itself.

Final Thoughts

I keep coming back to how ordinary the starting point was. Not a nation-state, not a zero-day chain three exploits deep. One function that forgot to ask for a password, and a crew patient enough to build a whole campaign on top of it. The bug was the boring part. The scary part is how little actual hacking it took to turn that boring part into a hundred victims, because once they were inside they mostly just used the building the way it was designed to be used, from the wrong side of a door that was never locked.

If there’s a lesson in here, I don’t think it’s really a technical one. It’s that the unglamorous stuff is what gets you: the internal service nobody remembered was exposed, the flat network everyone meant to segment “eventually,” the RMM agent that looked close enough to legitimate that nobody asked. Attackers have figured out that they don’t need to be clever if we’re not paying attention to the boring parts. And the boring parts are exactly the parts that are easy to stop paying attention to.

So if you run this stuff, this is your nudge. Go find out whether your Environment Management Hub is talking to the internet. Go read what a normal night of SSH traffic actually looks like on your network, so you’ll recognize an abnormal one. None of it is glamorous work, and that’s kind of the whole point. The next unauthenticated 9.8 in some load-bearing enterprise app is already out there, probably before this post goes stale. The crews are counting on us to keep not looking at the doors nobody’s watching. The least we can do is go check the locks.