Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The load-language command expects a lang parameter from which it constructs the path of the localization file to load, of the form translations-$LANG.json. When doing so, it does not check that the resulting path is in the expected directory, which means that this command could be exploited to read other JSON files on the file system. The command should be patched by checking that the normalized path is in the expected directory.
Recommended action: Upgrade to 3.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact OpenRefine releases contain Google API authentication keys ("client id" and "client secret") which can be extracted from released artifacts. For instance, download the package for OpenRefine 3.8.2 on linux. It contains the file openrefine-3.8.2/webapp/extensions/gdata/module/MOD-INF/lib/openrefine-gdata.jar, which can be extracted. This archive then contains the file com/google/refine/extension/gdata/GoogleAPIExtension.java, which contains the following lines: The Base64 encoding can then be decoded to obtain the client id and client secret. Those credentials can then be used by other applications to request access to Google accounts, pretending they are OpenRefine. This assumes that they also get access to the user access tokens, which this vulnerability doesn't expose by itself. Patches The bundled credentials should be revoked. Workarounds Users should revoke access to their Google account if they have connected it to OpenRefine.
Recommended action: Upgrade to 3.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The built-in "Something went wrong!" error page includes the exception message and exception traceback without escaping HTML tags, enabling injection into the page if an attacker can reliably produce an error with an attacker-influenced message. It appears that the only way to reach this code in OpenRefine itself is for an attacker to somehow convince a victim to import a malicious file, as in GHSA-m88m-crr9-jvqq, which may be difficult. However, out-of-tree extensions may add their own calls to respondWithErrorPage. Details The Command.respondWithErrorPage (through HttpUtilities.respondWithErrorPage) function renders the Velocity template error.vt, which contains the $message and $stack variables, which are included in the response as-is: https://github.com/OpenRefine/OpenRefine/blob/master/main/webapp/modules/core/error.vt#L52-L53 However, the message can contain HTML tags, which would then be interpreted by the browser. A mitigation would be to escape both the message and…
Recommended action: Upgrade to 3.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The export-rows command can be used in such a way that it reflects part of the request verbatim, with a Content-Type header also taken from the request. An attacker could lead a user to a malicious page that submits a form POST that contains embedded JavaScript code. This code would then be included in the response, along with an attacker-controlled Content-Type header, and so potentially executed in the victim's browser as if it was part of OpenRefine. The attacker must know a valid project ID of a project that contains at least one row. Details The malicious form sets contentType to text/html (ExportRowsCommand.java line 101) and preview to true (line 107). This combination causes the browser to treat what OpenRefine thinks of as an export preview as a regular webpage. It would be safer if the export-rows command did not allow overriding the Content-Type header at all, instead relying on the exporter to provide the correct Content-Type. It could also require a CSRF token.…
Recommended action: Upgrade to 3.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.