CVE-2024-47882 is a medium-severity (CVSS 5.9) Cross-site Scripting (XSS) vulnerability in org.openrefine:openrefine. 1 public exploit or proof-of-concept reference is indexed, so weaponization risk is real. A fix is available for org.openrefine:openrefine — see the affected versions and patch details below.
OpenRefine's error page lacks escaping, leading to potential Cross-site Scripting on import of malicious project
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2024-47882.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
org.openrefine:openrefineReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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 stack trace, perhaps using Guava's HTML escaper.
Flows that report errors as application/json responses are not interpreted by the browser and so not affected by this issue.
PoC
In OpenRefine, use the "Import project" feature to import the following URL (or upload it as a file): https://wandernauta.nl/oa/example.tar.gz
A JavaScript alert appears.
Impact
Execution of arbitrary JavaScript in the victim's browser, provided the victim can be convinced to import a malicious project. The script can do anything the user can do.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.openrefine:openrefine | all versions | 3.8.3org.openrefine:openrefine:3.8.3 |
Affected Products
openrefineopenrefineResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.openrefine:openrefine, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.openrefine:openrefine to 3.8.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-47882 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is CVE-2024-47882 in your dependencies?
Find it across Maven, including transitive dependencies.