OpenRefine 3.7.4 was released today and it fixes a vulnerability with moderate severity (CVE-2023-37476). We encourage all users to update swiftly to the latest version. See the release notes for more details about the vulnerability.
I thought arbitrary code execution isn't considered a vulnerability for OpenRefine? Such issues have been dismissed in the past, even ones that can be done remotely.
I think there is a big difference between the user typing a snippet of code in an expression dialog (which clearly conveys the expectation that this code will be executed) and them importing a project which changes arbitrary parts of OpenRefine's code, without the project being even opened.
It's all about the expectation from the user: if going through a particular workflow will execute arbitrary code unexpectedly, then that's a vulnerability in my opinion. Executing user-supplied code should only happen in cases where it's by design.
Do you have pointers to similar issues being discarded in the past?
OpenRefine by design allows remote execution by others and the Jython extension by design allows one to access broader system resources.
It's not something that should be illustrated or explained here in the forum. But if one is concerned about getting pwned then one should either lock down ones router configuration, disconnect from any networks, or run OpenRefine in a remote container(ironic given the view towards hosted use-cases).
OpenRefine by design allows remote execution by others
That's not true. The OpenRefine server is designed to accept instructions from a single user using a web browser running on the same desktop or laptop.
and the Jython extension by design allows one to access broader system resources.
It's not something that should be illustrated or explained here in the forum.
We have a mechanism for responsibly disclosing security vulnerabilities. Please report any vulnerabilities that you are aware of. It's been demonstrated repeatedly that "security through obscurity" doesn't work.
But if one is concerned about getting pwned then one should either lock down ones router configuration, disconnect from any networks,
It's definitely best practice to have at least one firewall between your computer and the public internet and to refuse all inbound connections.
or run OpenRefine in a remote container (ironic given the view towards hosted use-cases).
I'm not sure what "view" this is, but there's been strong demand for hosted versions of OpenRefine for over a decade (have a look at the issue tracker). What's lacking, so far, is the engineering effort to support that. If anyone would like to provide patches to support a robust multi-user, authenticated, hosted environment with API/protocol versioning and all the other stuff that that implies, I'm sure they would be well received. It is, of course, possible to wrap a sandboxed, ephemeral, locked down copy of today's implementation to achieve some measure of this capability, if you know what you are doing, but a) people often get it wrong and b) it usually still has significant limitations (e.g. limited or no project sharing/coordination).
Tom