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"<mbech...@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"<liya...@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
> 

Reply via email to