Project Zomboid’s malware scare just exposed a bigger problem with Steam mods

Steam’s Workshop has always run on a quiet assumption: that “Subscribe” is basically safe. The Project Zomboid incident blows a hole in that idea, and not just for one survival game or one bad actor, but for how we treat mods in 2026.

• 14 Steam Workshop mods for Project Zomboid’s unstable Build 42 were pulled after devs found heavily obfuscated code creating malicious files outside the game folder.
• All the mods came from a single uploader, now banned, and were disguised as unofficial add-ons to a popular soundtrack mod.
• Only Build 42 was vulnerable; players on the stable Build 41 are not believed to have been exposed to the exploit path.
• Unsubscribing is not enough: affected users are being urged to treat this as a real malware incident and scan their systems.

One rogue modder, 14 banned mods, and a hole in Build 42

The Indie Stone, the studio behind Project Zomboid, has removed 14 Steam Workshop entries and banned their uploader after discovering what it bluntly calls “malicious code.” This wasn’t a vague “maybe” situation: in the studio’s own description, the Lua scripts inside those mods were heavily obfuscated and were actually writing files outside Zomboid’s own directory.

The affected uploads all posed as unofficial extensions for the True MoooZIC soundtrack mod – basically audio add-ons for a well-liked piece of community content. That is exactly the kind of low-stakes, harmless-sounding mod most players subscribe to without a second thought.

Based on subscriber counts, The Indie Stone estimates somewhere between roughly 500 and 2,200 devices installed at least one of the malicious mods before the takedown. That’s not a planet-wide catastrophe, but it is a non-trivial number of PCs that now need to be treated as potentially compromised.

Crucially, this was not a random Steam-wide vulnerability. The exploit specifically targeted Project Zomboid’s experimental Build 42 branch. The devs say Build 41, the current stable version, is both unaffected and not vulnerable to the same trick. If you never opted into Build 42, you’re outside the blast radius of the actual exploit.

But if you did run Build 42 and subscribed to any of those 14 mods, this stops being a “game bug” and becomes a straight PC security issue. And that’s where this story stops being about one survival sim and starts being about how game modding is handled more broadly.

How a harmless-sounding music add-on became an attack vector

From what The Indie Stone has shared so far, the attack looked like this in broad strokes:

• Player opts into Build 42 (unstable branch) and subscribes to what appears to be an audio-related Workshop mod.
• Inside that mod is obfuscated Lua code – deliberately scrambled so humans and automated checks struggle to understand it.
• That code abuses a Build 42-only capability to write files outside the game directory, dropping additional payloads somewhere on the system.
• The devs observed these created files and deemed them malicious in nature, not just harmless logs or cache items.

We do not yet have a public, line-by-line breakdown of what the payloads do. Importantly, the studio is already labelling them “malicious files,” not hedging behind euphemisms like “suspicious behaviour.” That’s as close as you’ll get to a developer telling you to treat this like any other malware infection.

The choice to use “heavily obfuscated code” is itself a red flag. Obfuscation isn’t automatically evil – plenty of modders pack their scripts to deter copycats – but in security terms it’s the classic camouflage used to hide exactly this sort of behaviour. A simple audio add-on has no legitimate reason to be writing arbitrary files outside the game folder.

This is also where Zomboid’s own architecture comes into play. To support more complex mods in Build 42, The Indie Stone opened up additional Lua hooks and capabilities. That’s the standard evolution for a moddable game: start restrictive, then loosen as the community asks for more power. But every new bit of power – especially file I/O – is another way for malicious code to cross the line from “mod” to “installer.”

In other words: this wasn’t some magical new exploit chain. It was a familiar pattern – “give scripts more access, someone abuses it” – playing out inside a game that most people don’t think of as part of their attack surface.

Build 42 vs. Build 41: why only the unstable branch got burned

A lot of Project Zomboid’s player base is still on Build 41, the long-running stable branch that underpins most servers and mod ecosystems. According to The Indie Stone, those players are not vulnerable to this specific exploit at all – even if they were subscribed to the dodgy mods.

The difference comes down to what the game exposes to scripts. Build 41’s mod environment is more constrained; the file-writing behaviour these mods relied on simply doesn’t exist there in the same way, so the malicious code never had a functional pathway to do damage. The code might be present in the files, but without the right hooks it’s effectively inert.

Build 42, by contrast, is explicitly marked as unstable. It’s where The Indie Stone has been experimenting with deeper systems changes, new content, and more flexible scripting for modders. That’s exactly where you’d expect a mistake in permissions or sandboxing to show up first, and that’s where this one did.

This is a textbook early-access risk. Players get earlier access to features and more capable mods, but they’re also stepping into a space where the engine’s security assumptions are still being tested. Most of the time that risk equals crashes and broken saves. This time, it extended to file system abuse.

Steam Workshop moderation wasn’t built for this

It’s tempting to frame this as “Indie Stone removes 14 Steam Workshop mods and bans the uploader over malware (Build 42 only)” and leave it there. One bad actor, swift ban, story over. But that misses the underlying structural issue: nothing in Steam’s Workshop flow is designed to catch this kind of behaviour before it reaches players.

Steam does not actively vet Lua scripts, doesn’t sandbox per-mod permissions, and doesn’t have a meaningful automated review step for heavily obfuscated content. In practice, anything that compiles or uploads is one “Publish” click away from thousands of machines.

Up to now, the main checks in the system have been:

• Basic malware scanning on uploaded binaries (which this appears to have sidestepped by using in-game scripting and file writes).
• Community reporting once something looks obviously broken or malicious.
• Developers stepping in manually when the problem is tied to their specific game.

This incident followed exactly that pattern: players started reporting suspicious behaviour from one mod, The Indie Stone investigated, found a wider cluster of compromised uploads, then pulled the lot and banned the account. There was no automated guardrail that said “Why is this audio mod shipping layers of obfuscated Lua that writes outside the game folder?” because no such guardrail exists.

The uncomfortable reality is that for script-based ecosystems, Workshop is essentially trusting each game to enforce its own permissions model and sandbox. When that model loosens in an unstable branch – as it did with Build 42 – Steam’s side of the system doesn’t change at all. The capacity for abuse increases, but the oversight doesn’t.

Practical fallout: what Project Zomboid players should actually do

The Indie Stone’s message has been clear: simply unsubscribing or deleting the affected mods is not sufficient if the malicious code has already executed. Once a script has dropped files onto your system, removing the source script doesn’t remove what it left behind.

If you ran Build 42 and had any of the now-removed True MoooZIC “add-on” mods installed, the sensible path is to treat your machine the way you would after any other malware scare:

• Run a full system scan with a reputable antivirus or anti-malware suite.
• Pay attention to any detections tied to recent Zomboid sessions or unfamiliar executables in user or temp directories.
• If you manage sensitive data on that machine, consider more conservative steps (changing passwords, enabling multi-factor authentication, and so on).

The Indie Stone is continuing to investigate and has said it will share more specific guidance once the payloads are fully analysed. Until then, the right mental model is “this is malware that happened to arrive via a game mod,” not “this is a quirky bug that only affects zombies-and-cans-of-beans enthusiasts.”

The broader lesson for moddable games and early-access builds

Project Zomboid is not the first game to have its modding tools turned against its own players, and it won’t be the last. Minecraft has seen malicious modpacks. Garry’s Mod has had its share of exploitative Lua scripts. Any time you expose a scripting layer without a granular permissions model, you’re effectively asking players to do trust evaluation on raw code they’ll never read.

The design question every studio with a moddable game now has to answer is simple: how much power can you safely hand to mods without a proper permission system and sandbox? “Everything Lua can do” used to be an acceptable answer when the worst-case scenario was a broken save or a softlock. Once file system and network access are involved, that answer stops being acceptable.

For early-access titles specifically, this is a reminder that “unstable branch” doesn’t just mean “features may change” but “security assumptions are not settled.” Opening more of the engine to scripts on a testing branch is logical from a development perspective; doing it without strict guardrails turns your most enthusiastic testers into the first line of exposure for bad actors.

The Indie Stone’s response so far – rapid removal, public acknowledgement, clear Build 41 vs. 42 distinction, and a commitment to further analysis – is what you’d hope to see. The real test will be what changes in Build 42’s scripting model and in any future review of Workshop uploads for the game. If this ends with “we patched the specific hole” rather than “we tightened the entire trust model around scripts,” the same pattern will repeat somewhere else.

What to watch

• The Indie Stone’s technical postmortem – A detailed breakdown of the exploit path and payload will tell us whether this was a one-off abuse or a symptom of deeper architectural issues in Build 42.
• Changes to Zomboid’s mod API – Watch upcoming Build 42 patch notes for any new restrictions or permission systems around file I/O, network access, or script capabilities.
• Steam’s response, if any – If Valve remains silent and Workshop processes unchanged, it signals that responsibility for script safety will continue to sit almost entirely with individual game devs.
• How other moddable games react – If studios with heavy Lua or script modding (especially in early access) start talking about sandboxing and permissions, you’ll know this incident landed where it should: as a warning, not a footnote.

TL;DR

The Indie Stone has pulled 14 Project Zomboid Steam Workshop mods and banned their uploader after discovering heavily obfuscated code dropping malicious files outside the game folder, targeting only the unstable Build 42 branch. Stable Build 41 players are not believed to be vulnerable, but anyone who ran Build 42 with those mods installed should treat this as a genuine malware incident and scan their systems accordingly. The larger issue isn’t just one rogue modder – it’s how much power modern modding APIs and Steam Workshop give to unvetted scripts, without a permissions model built for the security risks that follow.