oss-sec mailing list archives
Re: CVE-2025-30761:A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution
From: "liyajie" <liyajie () openeuler sh>
Date: Thu, 24 Jul 2025 11:43:51 +0800
Hi Moritz, I agree with you, based on my understanding, to use Nashorn safely, at least three conditions must be met: 1. Remove objects such as "Java" and "Package" from the Nashorn execution context to prevent direct access to Java classes and methods. 2. Prohibit access to the engine property in the Nahsorn execution context. 3. Prohibit Reflection. This approach may ensure that the default execution context is secure (excluding scenarios where business code binds a high-risk class/instance to the execution context on its own). Using both SecurityManager and ClassFilter should meet the above three conditions, but employing SecurityManager in business environments is not an easy task, the SecurityManager has also been marked as deprecated starting from JDK 17. Best Regards, Yajie Li
From: "Moritz Bechler"<mbechler () eenterphace org> Date: Mon, Jul 21, 2025, 00:26 Subject: Re: [oss-security] CVE-2025-30761:A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution To: <oss-security () lists openwall com>, "liyajie"<liyajie () openeuler sh> Hi,
interesting that they "fixed" this issue now. Way back
(<https://mbechler.github.io/2019/03/02/Beware-the-Nashorn/>) reporting
something similar, I was told that Nashorn "sandboxing" was not supposed
to be secure unless you also configure a SecurityManager (which
implicitly suppresses the "engine" property). Restrictions purely based
on a ClassFilter have been broken ever since then.
And the patch really does not address the fundamental issue, which is
that you are able to get and configure a new engine. While the change
may stop you from suppressing the inherited no-java flag, why not get
direct command execution using another option instead:
System.setProperty("nashorn.args", "--no-java");
ScriptEngine e = new ScriptEngineManager().getEngineByName("nashorn");
String cmd =
"this.engine.factory.getScriptEngine(\"scripting\").eval('$EXEC(\"calc.exe\")')";
e.eval(cmd);
So, imho, the proper advice still should be not to use Nashorn for
running untrusted code.
best regards
Moritz
Current thread:
- CVE-2025-30761:A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution liyajie (Jul 16)
- Re: CVE-2025-30761:A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution Moritz Bechler (Jul 21)
- Re: CVE-2025-30761:A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution liyajie (Jul 24)
- Re: CVE-2025-30761:A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution Moritz Bechler (Jul 21)
