146 - Invisible Threats: The Risks of Automatic Code Execution

We track the thread running through the biggest security stories of the week: automatic execution paths that get trusted too far and monitored too little. We break down what went wrong across legacy servers, the software supply chain, edge devices, and AI platforms, then land on one practical way to reduce risk fast.
• ColdFusion path traversal leading to unauthenticated remote code execution under risky RDS settings
• Legacy exposure driven by forgotten toggles, missing ownership, and incomplete asset inventory
• JS Crambler NPM compromise using real publisher credentials and a cross-platform info stealer
• Attacker pivot from preinstall hooks to imported code that executes at runtime
• ORB relay networks built from compromised routers to hide espionage origins
• AI tooling risks where “small” permissions reach across tenants and managed runtimes
• NPM v12 turning install scripts off by default and winding down weak publisher tokens
• Typosquat payment SDKs and fake aged GitHub repos undermining trust heuristics
All of that is in this week's written issue at InfoSec.watch.

Transcript

The Week’s Unifying Security Pattern

SPEAKER_00 0:03

Here's the thread that runs through almost everything that mattered in security this week. It isn't a single vendor or a single bug class or a single threat actor. It's a question: what on your network runs code automatically? And do you actually know what that code can reach? Because when you line these incidents up side by side, they look completely unrelated. A cold fusion flaw, a poisoned NPM package, a Chinese espionage group hijacking home and office routers, a couple of AI platforms. On paper, none of these have anything to do with each other, but they all fail in the same place. In every one of them, something was trusted to execute on its own, and that trust reached further than anyone was watching. That's the lens for this episode. This is the InfoSec.watch podcast, walking through the week that was and why it matters for the people who have to defend against it. Let's get into it.

ColdFusion RCE And The Forgotten Toggle

SPEAKER_00 0:56

Start with Cold Fusion, because it's the clearest example of an old assumption coming back to bite. Adobe patched a vulnerability called CVE20002648282 on June 30th. It's a path traversal flaw, it scores a perfect 10 on the severity scale, and where it's exploitable, it hands an attacker unauthenticated remote code execution, meaning they run commands on your server without ever logging in. When Adobe shipped the fix, it said it wasn't aware of anyone exploiting it. That lasted about two days. By early July, researchers were watching attacks land in the wild, and on July 7th, Sissey added it to its known exploited vulnerabilities catalog. If you run Cold Fusion 2025, you want update 10. If you run 2023, you want update 21. Now here's the part worth slowing down on because it's easy to misread. This bug is only exploitable in a specific condition. A component called RDS has to be enabled, and its authentication has to be turned off. Your first instinct might be relief. That's not my default, I'm probably fine. And you might be, but flip it around. RDS enabled, authentication disabled is exactly the kind of setting that gets switched on years ago by a developer who needed it for something, and then never switched off. It's the forgotten toggle on the decade-old Cold Fusion box that runs one legacy application nobody wants to touch, that isn't in your asset inventory, and that's quietly reachable from the internet. That's the real risk here. Not that cold fusion is everywhere. It's that where it is, it tends to be old, unowned, and exactly the kind of thing an attacker finds before you do. So the move isn't just patch, it's go find every instance you forgot you had.

Poisoned NPM Package And Moving Payloads

SPEAKER_00 2:44

The second story is a supply chain compromise, and it's a good one to understand because of how the attacker adapted in real time. The NPM package JS Crambler, a legitimate, widely used JavaScript protection tool, got compromised. According to Socket, whose researchers caught it, the attacker published five malicious versions of the package using a real legitimate publishing credential. Not a type of squat, not a lookalike, the actual package, poisoned at the source. Each malicious version carried a cross-platform info stealer, built in Rust, targeting Windows, Mac OS, and Linux. Install it, and it goes hunting for cloud credentials, tokens, wallets, whatever the process running the install can see. But here's the detail that makes this one instructive. The first malicious versions ran their payload from a pre-install hook, the classic movie, code that fires the moment you install the package. That's a known pattern, and plenty of defenders now scan for it. Or install with the flag that skips install scripts entirely. So the attacker changed tactics mid-campaign. In the later poisoned versions, they move the malicious code out of the install hook and into the package's own imported code, so it fires when your application actually uses the library, not when you install it. That completely sidesteps the just skip install scripts defense. It's a live demonstration that install time scanning alone is not enough anymore. The clean version to move to is 8.22.0. And if you pulled any of the bad ones, treat that build machine as compromised and rotate everything it could touch.

Router Relay Networks Hiding Espionage

SPEAKER_00 4:15

The third story moves from your code to your hardware. Cisco Talos reported that a China Nexus group they track as UAT78TEU is expanding what's called an ORB network, an operational relay box network. The idea is simple and nasty. Compromise a lot of ordinary internet-facing devices and chain them together into relay infrastructure that other espionage groups route their traffic through. So when an attack finally lands somewhere sensitive, it appears to come from a boring residential or small business router in the right region, and the true origin stays hidden. The devices they're going after are unpatched Ruckus and Asus routers using vulnerabilities that already have fixes available. Talos documented an upgraded backdoor they call Long Leash and a new one called Dog Leash, built to hold onto these devices long term. And the reason this works is the reason edge devices are always the soft underbelly. They have long replacement cycles, thin logging, and almost nobody watches them the way they watch a laptop or a server. A router can sit compromised for months, relaying someone else's espionage, and the owner never notices. The takeaway isn't exotic. Patch the supported ones, replace the end-of-life ones, and start treating outbound proxying from your edge gear as something you'd actually want to see. Those are the three big ones. There were five more developments worth your attention, and they sort neatly into two themes, which is itself part of the

AI Platform Permissions That Overreach

SPEAKER_00 5:42

point. The first theme is AI tooling entering the exploitation timeline for real. Two stories here. One, CISA added a vulnerability in Langflow, the open source AI flow builder, to its actively exploited catalog on July 7th. It's an authorization bypass, and what it lets an authenticated user do is run another user's flows, just by referencing that victim's flow ID in the request. In a shared multi-tenant deployment, that's a clean isolation break. One tenant reaching into another's logic and whatever that logic can touch. 2. Veronis disclosed a now fixed flaw in Google's Dialogflow CX they called Rogue Agent, where a single edit permission on one AI agent could be used to inject persistent code, read conversations, and affect other agents sharing the same managed execution environment. Google fixed it back in June, and there's no sign it was exploited in the wild. But notice how those two rhyme. In both, the AI platform runs code in a managed runtime you can't fully see into. And a permission that looks narrow turns out to reach much further. If your organization is standing up AI tooling right now, that's the pattern to design against.

Supply Chain Shifts And New Deception

SPEAKER_00 6:51

The second theme is the software supply chain, and there are three beats. One, NPM shipped version 12 and it finally turns install scripts off by default. GitHub itself calls those install hooks the single largest code execution surface in the whole ecosystem, and now they don't run unless you explicitly allow them. It also starts winding down the tokens that let publishers skip two-factor authentication. That's a genuine structural reduction in attack surface, and it's overdue since PNPM, Yarn, and Bun already worked this way. But, and the JS Grambler story is the proof, it is not a cure. Malicious code can still ride in through the imported package itself, which install script blocking does nothing about. 2. Socket flagged a wave of payment SDK typosquats hitting three ecosystems at once, NPM, PyPI, and NuGet, including 17 packages impersonating Paysafe, Skrill, and Nuteller, plus a fake Braintree package, all built to skim credentials, API keys, and livecard data. And three, Socket also documented a campaign they named Operation Muckin' Load, which stood up 222 GitHub repositories, complete with faked commit history, to make malicious Go modules look like trustworthy, established projects. That last one is worth sitting with because it attacks a heuristic every developer uses. An active-looking, aged, populated repo feels safe. It isn't evidence of anything.

One Lesson Across Every Headline

SPEAKER_00 8:22

So step back and look at the whole board. Cold Fusion, the JS Grambler package, UAT7810s routers, Langflow, Dialogflow CX, five very different technologies and the same shape underneath every one of them. Something that was trusted to run on its own, reaching further than its monitoring justified. A forgotten server setting. An install hook. And then, when that got watched, the imported code instead. A router quietly relaying for someone else. An AI permission that crossed a tenant boundary. The reason this matters is that the defensive reflex, is it patched? Only answers half the question. Patching closes the specific hole. It doesn't tell you what else on your network executes automatically, what those execution paths can reach, or whether you'd even know if one had already been used. The week is basically arguing that the more useful question is the second one.

Trace Your Riskiest Auto-Execution Path

SPEAKER_00 9:16

Which turns into a concrete move, and I'd keep it to one. This week, pick the single automatic execution path in your environment with the most exposure, the internet-facing one, the one with the most access, the one you understand the least, and actually trace it end to end. What runs without a human in the loop? What credentials and systems can it reach if it's abused? And what evidence would prove it stayed clean? If you run ColdFusion, that RDS configuration is a very good place to start today. If you live in a build pipeline, start with what executes on your CI runners and what secrets they hold. You're not going to map everything in a week. Map the worst one properly. That's the week. Different headlines, one lesson. Automatic trust is where defenders keep getting caught, and the fix is knowing what runs, what it can reach, and how you'd prove

Where To Get The Full Checklist

SPEAKER_00 10:09

it's clean. If you want the specifics, the exact CVE identifiers, the affected and fixed versions, the primary sources, and the full defensive checklist written up as something you can hand to a team. All of that is in this week's written issue at InfoSec.watch. This has been the InfoSec.watch podcast. Patch the Forgotten Box. I'll see you next week.