The Ghost in the Minified Blob: Unpacking GHSA-RWR8-XRPW-9QF5 in Craft Freeform

In the modern web development landscape, we rely heavily on package managers. We trust that composer update or npm audit fix actually does what it says on the tin. But there is a dark corner of the ecosystem that scanners often miss: the pre-compiled asset.

Imagine you are running Craft CMS. You use Solspace Freeform, the gold standard for form building in that ecosystem. You run your security scans. PHP dependencies? Clean. Node modules? You don't run them on production, so who cares? But lurking inside /vendor/solspace/craft-freeform/src/assets/freeform/plugin.js is a fossilized version of Axios—a zombie dependency that hasn't been updated in eons.

This vulnerability (GHSA-RWR8-XRPW-9QF5) isn't a flaw in Solspace's logic per se. It's a failure of the build pipeline. The vendor shipped a minified JavaScript blob that effectively statically linked a vulnerable library. It’s the web equivalent of statically linking OpenSSL 0.9.8 into a binary in 2024. You can't patch it. You can't update it. You are at the mercy of the vendor to re-run their build script.

The specific offender here is the Axios library, specifically versions older than 1.7.5. The primary vulnerability causing heartburn is CVE-2024-39338. In the world of HTTP clients, handling redirects and paths is surprisingly difficult.

CVE-2024-39338 describes a scenario where Axios mishandles the logic between the base URL and the requested path. If an application allows a user to control part of the path, an attacker can use path traversal sequences or malformed URLs to break out of the intended directory or domain scope. In a Node.js context, this is a full-blown Server-Side Request Forgery (SSRF).

In the context of a browser-based asset like Freeform's plugin.js, the risk profile shifts but doesn't vanish. If the form builder uses Axios to fetch dynamic content, validate URLs, or proxy requests through a local endpoint, relying on a broken HTTP client means your validation logic is likely bypassable. It effectively neutralizes any client-side security controls that rely on Axios behaving predictably.

Usually, in these reports, I show you a beautiful PHP diff. But today, we are looking at the ugly underbelly of frontend bundling. There is no GitHub commit hash for the code change because the change happened in the compilation of the release artifact.

To find this vulnerability, you don't grep PHP files. You look at the artifact. A researcher (or a good scanner) would look at the file located at:

/vendor/solspace/craft-freeform/src/assets/freeform/plugin.js

If you were to beautify and inspect this minified horror show in versions < 4.1.30, you'd find the Axios signature embedded directly:

// Inside the minified blob
var axios = { version: "1.6.0" ... }; // or older

The fix wasn't a code change in Freeform.php. It was the vendor running npm update axios && npm run build before tagging the release. The fixed version (4.1.30 / 5.14.6) simply ships with a newer blob where that internal string reads 1.7.5 or higher.

[!NOTE] This highlights a critical blindness in standard PHP vulnerability scanners. Most PHP scanners only check composer.lock. They do not decompose minified JS assets inside the vendor folder to check for bundled npm vulnerabilities. This is a blind spot in 90% of CI/CD pipelines.

How do we weaponize this? Let's assume Freeform uses this bundled Axios instance to handle dynamic form rendering or API submissions. A common pattern in form builders is checking a URL endpoint to see if it's valid before submitting data to it.

Let's say the code looks something like this (pseudocode reconstructed from minified logic):

// Vulnerable Logic using old Axios
const target = userInputUrl; // e.g. "http://evil.com/../../internal-api"
axios.get("/proxy?url=" + target);

Or perhaps the plugin attempts to enforce a Base URL:

const client = axios.create({ baseURL: "https://api.mysite.com/v1/" });
// CVE-2024-39338 allows breaking out of baseURL using specific path constructs
client.get(maliciousPath);

If the vulnerability is CVE-2024-39338, an attacker can supply a path that Axios thinks is relative to the BaseURL, but actually resolves to a completely different endpoint (potentially an open redirect or an internal API endpoint if the browser context allows it).

While this is client-side (running in the victim's browser), it can be chained with Cross-Site Scripting (XSS). If I can force your browser to send a request to an unexpected endpoint using the trusted Axios instance (which might have authentication headers configured), I can perform actions on your behalf that the developer thought were impossible due to URL validation.

Remediation is straightforward, provided you are tracking your dependencies. You need to pull the version of Freeform where Solspace finally recompiled their assets.

For Craft 4 Users: Bump to 4.1.30.

For Craft 5 Users: Bump to 5.14.6.

Run the magic words:

composer update solspace/craft-freeform

After updating, clear your asset caches. In Craft CMS, this often means clearing the cpresources folder or running ./craft clear-caches/all. If you don't clear the cache, your browser (or your CDN) might stubbornly serve the old, cached plugin.js file, leaving you vulnerable despite the backend update.

[!WARNING] If you are using asset bundling strategies (like Vite or Webpack) that ingest vendor files, you must rebuild your frontend assets as well to ensure the new file is picked up.