GHSA-v33j-v3x4-42qg — hurl
Fix: Orange-OpenSource/hurl@248ac41GHSA-v33j-v3x4-42qg is a security vulnerability in hurl. A fix is available for hurl — see the affected versions and patch details below.
Regex literal in Hurl files are not escaped when exported to HTML, allowing injections
Real-World Exposure
hurlReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Given this Hurl file:
regex.hurl:
GET https://foo.com
HTTP 200
[Asserts]
jsonpath "$.body" matches /<img src="" onerror="alert('Hi!')">/
When exported to HTML:
$ hurlfmt --out html regex.hurl
<pre><code class="language-hurl"><span class="hurl-entry"><span class="request"><span class="line"><span class="method">GET</span> <span class="url">https://foo.com</span></span>
</span><span class="response"><span class="line"><span class="version">HTTP</span> <span class="number">200</span></span>
<span class="line"><span class="section-header">[Asserts]</span></span>
<span class="line"><span class="query-type">jsonpath</span> <span class="string">"$.body"</span> <span class="predicate-type">matches</span> <span class="regex">/<img src="" onerror="alert('Hi!')">/</span></span>
</span></span><span class="line"></span>
</code></pre>
The regex literal /<img src="" onerror="alert('Hi!')">/ is not escaped:
<span class="regex">/<img src="" onerror="alert('Hi!')">/</span></span>
When opened in a browser, the code is run without user interaction:
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | hurl | all versions | 7.0.0cargo update -p hurl --precise 7.0.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hurl, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update hurl to 7.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v33j-v3x4-42qg is resolved across your whole dependency graph.
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.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-v33j-v3x4-42qg can be triaged on real exposure rather than presence alone.
Tailored to GHSA-v33j-v3x4-42qg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-v33j-v3x4-42qg in your dependencies?
O3 Security finds GHSA-v33j-v3x4-42qg across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.