A critical Splunk flaw came from a helper service that no one asked to lock its own door

Cybersecurity 5 min 31 sources

A 9.8-severity hole in Splunk Enterprise let an unauthenticated user reach a built-in database helper and run code — because the helper trusted that only the main app would ever call it. Plus a decade-long China-linked espionage campaign, a coming change to npm to slow supply-chain attacks, and a government order pulling two AI models offline.

Key takeaways

A 9.8-severity Splunk flaw came from a built-in helper service that had no login check of its own — because it assumed only the trusted main app would ever reach it. Patch to 10.0.7 or 10.2.4.
The riskiest doors in a system are often the internal ones, left unlocked on the assumption that only friends will knock.
If your "bank" calls and asks you to confirm security details, hang up and call the number on your card — a real bank won't ask that way.

The biggest security story today isn’t a breach. It’s a flaw in software that thousands of companies use to watch for breaches — and the reason it existed is worth understanding.

A back room with no lock

Splunk released an emergency fix for a flaw rated 9.8 out of 10 — about as severe as the scale goes [1]. Splunk is software companies use to collect and search their logs; security teams lean on it to spot trouble. The flaw, tracked as CVE-2026-20253, let someone with no account and no password reach a part of the system and, in the worst case, run their own code on it [1].

A CVE is just a public ID for a specific software flaw, so everyone refers to the same one. The number rating it (CVSS) runs 0 to 10; 9.8 means easy to exploit and very damaging.

Here is the part that teaches something. Splunk’s main application checks who you are before it does anything sensitive. But the flaw wasn’t in the main application. It was in a small helper service bundled alongside it — a database engine (PostgreSQL) running as a “sidecar,” a separate component installed to do one supporting job [1]. That helper had its own network door, and that door had no lock at all. Anyone who could reach it over the network could ask it to do work without proving who they were [1].

The helper was built on a quiet assumption: only the trusted main app will ever talk to me, so I don’t need my own check. The assumption held right up until someone reached the helper directly. Researchers showed that from there, a determined attacker could chain steps together to write a file onto the system and eventually run their own code [1]. There’s no sign anyone used the flaw before the fix, but now that the details are public, opportunistic attempts become likely — so patching fast matters [1].

If you run Splunk Enterprise: the fix is in versions 10.0.7 and 10.2.4; older 10.0 and 10.2 builds are exposed, and Splunk’s cloud version is not affected [1]. If you don’t: the lesson still lands — the riskiest doors in any system are often the internal ones nobody thought to guard, because everyone assumed only friends would knock.

A decade in someone’s network

Researchers at the firm Sygnia described a China-linked espionage group, which they track as “Velvet Ant,” that sat inside one organisation’s network for about ten years before being caught [3]. The group, active since at least 2016, worked its way from internet-facing servers into an “air-gapped” part of the network — a section deliberately kept off the internet for safety [3].

What stands out is patience, not flash. Instead of breaking in loudly, the group hijacked the network’s own login process and watched administrators work, keeping quiet access for years [3]. Air-gapping is supposed to be a wall; this is a reminder that a wall only helps if nothing trusted can carry a message across it. (This is the group’s account of one campaign, documented by the researchers who found it — not a claim from the attackers themselves.)

A small change to slow a big problem

On the prevention side: the team behind npm — the giant library of free code that web developers pull into their projects — said its next version, npm 12, will change how it runs install scripts, a step aimed at slowing supply-chain attacks [2]. A supply-chain attack is when someone poisons a piece of shared code that thousands of projects depend on, so the poison spreads downstream to all of them.

Today, installing a package can quietly run code on your machine as part of setup — convenient, and a favourite trick for attackers who sneak a bad package into the supply [2]. The coming change makes that automatic execution less automatic [2]. It won’t end supply-chain attacks, but it removes one easy on-ramp. You don’t have to write code to benefit; the apps and sites you use are built on this plumbing.

A government pulls two AI models offline

In policy news, the US Commerce Department ordered Anthropic to immediately cut foreign access to its two newest AI models, Fable 5 and Mythos 5, citing a national-security concern [4]. The order placed the models under export controls — rules that limit who outside the US can use a technology [4]. Because those controls extend even to foreign-born employees, Anthropic said it disabled both models entirely to comply [4].

The reported trigger was a discovered way to get around the models’ built-in safety limits — a “jailbreak” [4]. The government’s letter didn’t spell out the specific worry, and several details remain unclear, including the effect on a programme that let security firms use one model to find software flaws [4]. The wider point: as these tools get more capable, the rules around who can use them are starting to move as fast as the tools themselves.

And one for your own front door

A separate Guardian piece is a useful reminder of how today’s scams actually work. A well-known UK tech reviewer with 1.6 million subscribers lost £70,000 to a single phone call from someone posing as his bank [5]. The caller already knew his name, address, who he banked with, and that he was travelling — details he’d let slip in his own videos and posts [5]. Late, jet-lagged, in a noisy restaurant, he answered their questions and the money was gone [5].

No software was hacked. The “vulnerability” was a tired person and a convincing voice. Real banks don’t ask you to confirm security details on a call they made to you. The safe move is always the same: hang up, find the number on your card, and call back yourself.

02 · Lesson · why it matters

The door you left open because only friends were supposed to use it

A lock you skip on the assumption that only trusted people can reach the door isn't a small risk — it's the whole risk, waiting for the assumption to break.

A helper that was never asked to prove itself

Today’s Splunk flaw isn’t really about Splunk. It’s about a small helper — a database engine bundled inside the bigger app to do a supporting job. The main app checked who you were before doing anything sensitive. The helper checked nothing. It had its own door onto the network, and that door had no lock.

Why would anyone ship a door with no lock? Because of a reasonable-sounding belief: only the main app will ever talk to this helper. Inside that belief, a lock is pointless work. The helper is a friend among friends. Who needs to check a friend’s ID?

The belief held until someone reached the helper directly, going around the app entirely. And then the missing lock wasn’t a minor oversight. It was the front door.

The assumption was the wall

Here is the pattern worth carrying. The Splunk team thought they had a wall: the main app guards the gate, so everything behind it is safe. But the wall wasn’t built of code. It was built of an assumption — “nothing untrusted can reach the back room.”

An assumption is not a wall. It feels like one because, most days, it behaves like one. Nobody untrusted does reach the back room, so the missing lock costs nothing and is never noticed. The protection seems real because it’s never tested. That’s exactly what makes it dangerous: the day it’s tested is the day it fails, and you find out the wall was a story you told yourself.

The fix Splunk shipped doesn’t add a wall. It adds a lock — the helper now has to check who’s calling, friend or not [1]. The difference between “trust the boundary” and “every component checks for itself” is the difference between a story and a structure.

The same shape, ten years deep

You can see the same shape in today’s second story. A China-linked group sat inside one organisation’s network for about ten years [3]. Part of that network was “air-gapped” — deliberately kept off the internet, a wall by design. But the group didn’t break the wall. It hijacked the network’s own trusted login process and rode that trust inward [3].

Air-gapping assumes nothing trusted will carry a message across the gap. The attackers turned the trusted thing — the login flow itself — into the carrier. Same lesson, longer fuse: the boundary you rely on is only as strong as the thing you’ve decided to trust on the inside of it.

This is your house too

It’s tempting to file this under “enterprise software problem” and move on. Don’t. The shape lives in ordinary life, and one of today’s stories is the proof.

A sharp tech reviewer lost £70,000 to a phone call [5]. The scammers didn’t break any software. They walked through a door he’d left unlocked: the assumption that a caller who knows your name, your bank, and your travel plans must be legitimate. That assumption is the lock most of us skip. We treat “they know things about me” as proof of identity, the way Splunk treated “you reached the helper” as proof you belonged.

Think about your own trusted insides. The browser extension you installed years ago and never reviewed. The old app still holding a permission you forgot you granted. The family member’s account that can reset yours. The home network where every device trusts every other device, so one cheap gadget can see the rest. Each of these is a helper with no lock, safe only as long as the assumption around it holds.

What the whole looks like

The humbling part isn’t that we leave doors unlocked. It’s that we usually can’t see which assumption we’re standing on. The Splunk engineers weren’t careless; they were trusting a boundary that had held every single day until it didn’t. You are doing the same thing right now, in ways you can’t fully list — trusting that the helper, the caller, the inside, is what it appears to be.

You can’t lock every door, and pretending otherwise is its own kind of blindness. But you can hold the trust more loosely. When something feels safe only because “nobody untrusted could reach it,” that’s not a wall you’ve built. It’s a bet you’ve placed — and the whole point of seeing the system is to notice you’ve placed it, before someone else notices first.

03 · Lab · your turn

Lock the Inside

Decide which internal helpers need their own login check, then watch a probe test whether your trusted boundary was a wall or just an assumption.