I believe you have been in touch with my colleague, Jonathan West, who unfortunately is now on holiday.
I am looking to understand how/if Octave have been impacted by the Log4J vulnerability.
I want to follow up on something technical. We have been alerted to a critical vulnerability affecting Java applications that allows an attacker to take control of the server or device to then use as they wish. This is a global vulnerability affecting Java and the applications written on it. This vulnerability possess a severe risk.
We have a process in my company whereby we have put all our applications on a red list and only move them to the green list once we confirm the application is not impacted in any way to the log4j vulnerability.
With our third party applications, we are contacting our providers to confirm that they are not impacted by this vulnerability and if they are, they demonstrate that they have identified, mitigated and applied or applying a patch/fix to this vulnerability. If they are not impacted, we want a clear rationale on why the application is not impacted by this vulnerability, e.g. no Java used or no use of Log4J.
Can you please get back to me as a matter of urgency on the status of Octave to this vulnerability as it has been identified as one of our critical systems and our users will be prevented from using the application until it moves to the green list.
Edit by @siko1056: stripped unpermitted company commericals for more objectivity on a serious subject (see Terms of Service).
More information on the actual vulnerabitlity at:
In general Octave does not depend on Java. Which version of Octave (installation source) and operating system your company is using?
A search of the core octave shows no reference to log4j, and neither does a search of the bundled packages included in windows installers.
While Octave does have a java interface, external libraries need to be installed by the user to enable those functions, and they are not included by default. The only reference I can find online to Octave and log4j is by a third party who developed a datalogging tool that, again, would require them to separately provide/install the log4j library files for it to function.
Is there any reason you suspect that Octave is impacted by the recently discovered log4j issue? If so, could you please point to the respective parts of Octave?
In general, Octave is not a Java application. It doesn’t use log4j directly.
Having said that, Octave has many dependencies. And I don’t know if any of those might or might not use Java and/or log4j.
Additionally, Octave provides a Java interface for user code. In principle, it should be possible to call any Java code from Octave. That includes Java functions that might depend on log4j. You’d need to check your code base to evaluate if any of it might be doing that.
There is no reason. Octave is not a Java application. The number of unthinking requests to certify our code base is not vulnerable to Log4J has been ridiculously high.