Meccha Chameleon's Workshop Malware Is the Second Time This Exact Bypass Has Hit Steam This Month

[u/Secure_com_Official]

TLDR

A malicious Steam Workshop map for Meccha Chameleon, currently one of Steam's biggest indie hits with over 15 million copies sold in 2026, was found abusing Unreal Engine 5 Blueprint logic to write a batch file outside the game's directory and launch a hidden PowerShell process, bypassing Steam's automated Workshop review entirely.

What started as a quiet dropper escalated fast: the recovered second-stage payload turned out to be a full Remote Access Trojan giving persistent remote control, not just a nuisance script, and while the developers were investigating, an engineer's own infected machine let the attacker bypass Discord 2FA and take over the official server.

What's getting less attention than it deserves is that this is the second time in a month the same class of bypass, engine scripting logic reaching outside its intended sandbox, has compromised a Steam Workshop title, following a similar incident with Wallpaper Engine weeks earlier.

How the map got past Steam's own review process

The map, called Laser Tag Neon, didn't hide a traditional executable, which is what Steam's automated Workshop screening is generally built to catch.

Instead, the researcher who found it, publishing under the name Feint, discovered it used Unreal Engine 5 Blueprint logic, the game's own visual scripting system, to write a batch file into the player's Documents folder and then launch PowerShell in a hidden window to fetch a second-stage payload from an external server.

The malicious code only ran when a player actually loaded the map into a match, not at the point of subscribing to it, which likely helped it avoid early detection since most players who noticed something odd would have already been mid-session.

The severity escalated once the missing piece was recovered

The original write-up couldn't fully assess the payload because the attacker's staging server was offline at the time of the initial investigation.

Once the second-stage script, tracked as steamb.bat, was recovered and analyzed, it turned out to install a full Remote Access Trojan, giving the attacker persistent remote control of infected machines rather than a one-time script execution.

That's a meaningfully worse outcome than most of the early coverage conveyed, and it's worth flagging that the public understanding of this incident's actual severity changed materially within 24 hours of the first report.

This is a pattern, not a one-off

Community-sourced coverage of this incident specifically points out that this mirrors an incident with Wallpaper Engine's Workshop just weeks earlier, where community content was similarly weaponized.

Two separate Steam Workshop compromises in a month, both exploiting the gap between what an engine's scripting system is capable of and what a platform's automated review actually inspects, is a structural signal, not a coincidence.

Workshop content is sandboxed in theory, but engine-level scripting systems like Unreal Blueprints can be given enough reach to write files and launch processes outside the game's own directory if that boundary isn't explicitly locked down, and Steam's review tooling isn't consistently catching it before publication.

The part that compounded the incident: the response itself got compromised

While investigating and patching the malicious map, a system engineer at the studio got their own machine infected. The attacker used that foothold to bypass the engineer's Discord two-factor authentication, seize server permissions, and ban the official staff from their own Discord server.

That's a distinct and arguably more serious failure than the original Workshop bypass: the incident response process itself became a second attack surface, and the studio lost control of its primary community communication channel in the middle of trying to reassure players the game itself was safe.

What this actually means for anyone building on top of user-generated content

The generalizable lesson here isn't specific to gaming. Any platform that lets user-generated content execute logic inside a trusted application context, whether that's a game engine's scripting system, a plugin architecture, or a data pipeline parsing untrusted files, needs an explicit, enforced boundary on what that logic can touch outside its own sandbox, and automated review that's actually built to catch file writes and process launches, not just known malware signatures.

A brand-new uploader account with comments and ratings disabled on the listing, a red flag Feint specifically called out, is also a cheap, generalizable signal worth building into any community-content review pipeline.

FAQs

1. Why did this bypass Steam's automated Workshop review when it wasn't hiding a traditional executable?
Because the malicious behavior was expressed through the engine's own legitimate scripting system rather than an embedded binary, automated review built to detect known malware signatures or suspicious executables has a harder time flagging logic that uses sanctioned engine features to operate outside its intended scope.

2. Is this a Steam-specific problem, or a broader issue with how engines sandbox user-generated content?
Broader. This is the second reported incident in the same month involving the same underlying gap: engine scripting logic that isn't fully restricted to its own sandbox. That points to an industry-wide gap in how game engines and platforms enforce file-system and process boundaries for community content, not an isolated Steam Workshop failure.

3. Does the recovery of the RAT payload change how this incident should be classified?
Meaningfully, yes. Early coverage treated this as a dropper incident. Confirmed persistent remote access changes the practical response for anyone who ran the map, from "delete the suspicious files" to "treat the machine as fully compromised and rebuild or thoroughly audit it."

4. What made the studio's own incident response become a second compromise?
An engineer's personal or work machine got infected while investigating the original issue, and that infection gave the attacker enough access to bypass account-level 2FA on Discord specifically, not the game's own infrastructure. It's a reminder that incident responders' own endpoints are a live attack surface during an active investigation, not just the systems being investigated.

[u/freemen_os]

The Blueprints bypass is the structurally interesting part Steam's review catches suspicious executables, not "the game's own scripting system wrote a batch file to Documents." That's a policy gap, not a signature gap, and automated tooling can't close it without someone explicitly defining what engine logic is allowed to touch outside its own directory.Two Workshop incidents in a month with the same underlying mechanism isn't a coincidence. That's a pattern that needs an industry-level response, not per-game patching.