I'm going to be publishing a multi-part series on why you shouldn't use Blueprints in user-created content because of serious vulnerabilities in the Blueprint interpreter.
This is a prelude to that, and follows the vulnerability's origins as a poorly-kept secret in the UT2004 modding, which had long been using exploits to install community-made anti-cheat mods.
I basically sat on this all for a very long time, before a very "better extremely late than never" decision to finally report it once most of these games had active maintainers again. The new maintainers have been notified, but some of those maintainers authored these exploits in the first place.
Some history of this problem
A few years after Unreal Tournament's launch, connecting to servers would frequently greet you with this:
A "native mod" is a fancy term for a DLL downloaded on to your machine by the server, which is not something that the game is supposed to allow. This was a combination of a path traversal vulnerability with an overly permissive API and is assigned CVE-2024-34492, and worked by stuffing a DLL binary into a music resource, then loading the Editor package and exporting it into the System directory. (Ultimately, this makes it a path traversal vulnerability.)
The fact that a self-advertising DLL dropper openly existed on around half of the active servers of a popular game and never set off alarm bells or caused an incident is a testament to how different the security landscape was in the early 2000's compared to today, and how much games have lucked out by being overlooked as attack vectors.
This was only a few years after the big headline-making threat was the Melissa virus, a pointless macro virus that did nothing but spam itself to every one of your Outlook contacts. Clearly not the same type of environment as a world full of ransomware, wipers, RATs, and crypto wallet stealers.
However, this particular method stopped working in Unreal Tournament 2003. Despite that, some similar community-made anti-cheat systems and "enhanced functionality" were popping up for Unreal Tournament 2004 anyway, and some of the internal comments were odd things like "don't recompile this package." It turns out that was because they were using intentionally-mismatched packages to take advantage of a type confusion vulnerability in order to escape the scripting system's sandboxing.
So, why does this matter today?
This would only matter so much if it was about vulnerabilities in 20-year-old games with a niche audience. Shortly after I reported this issue to Epic, Unreal Tournament, Unreal Tournament 2003, and Unreal Tournament 2004 were removed from sale, but there is no evidence that this is related to the vulnerability report. Unreal Tournament 3, which is still being sold, is almost certainly still affected by the same exploits used in UT2004, which I will be going into more detail on in the next part.
Unreal Engine 4 and 5 work much differently than the prior iterations that happily let players run their own servers that distributed mod packages to anyone connecting though. Unreal-based games these days mostly use developer-controlled servers and don't distribute arbitrary packages to users unless the developers explicitly add paths for doing so.
Unfortunately, about 2 weeks ago, such a thing happened when popular indie hit Meccha Chameleon allowed Blueprints in custom maps downloaded via Workshop.
That was caused by an insecure function, "Launch URL," which could be used to launch... things that were not URLs. Most of the responses centered on limiting what functions Blueprint can access. Cool idea, but ultimately not the correct approach. Blueprint is not safe to load from untrusted sources, period, because the Blueprint interpreter itself is not safe when given untrusted bytecode.
It's based on the UnrealScript interpreter and none of the fundamental vulnerabilities used by the UT2004-era sandbox escapes have been fixed.
I'll be going into those in the next part.
