GHSA-gj48-438w-jh9v
MEDIUMGHSA-gj48-438w-jh9v is a medium-severity (CVSS 6.1) vulnerability in bleach. O3 Security confirms whether GHSA-gj48-438w-jh9v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Bleach clean() / Cleaner() fails to sanitize dangerous URI schemes in allowed formaction attributes
Real-World Exposure
bleachReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Bleach clean() / Cleaner() fails to sanitize dangerous URI schemes in allowed formaction attributes.
Bleach applies URI protocol sanitization only to attributes listed in attr_val_is_uri. While URI-bearing attributes such as action, href, src, and poster are included in that set, formaction is not. As a result, if a downstream application explicitly allows formaction on submit-capable controls in untrusted HTML, Bleach preserves dangerous values such as javascript:alert(1) instead of stripping them.
This can lead to submit-triggered JavaScript execution in applications that rely on Bleach to sanitize untrusted HTML and allow the relevant tag/attribute combination.
Details
The issue appears to be a URI-sanitization coverage gap in Bleach’s sanitizer logic.
Relevant code paths:
bleach/sanitizer.py—BleachSanitizerFilter.allow_token(around line 553)bleach/_vendor/html5lib/filters/sanitizer.py—attr_val_is_uri(around line 525)
In BleachSanitizerFilter.allow_token, URI protocol sanitization is only applied when:
if namespaced_name in self.attr_val_is_uri:
However, (None, 'formaction') is currently missing from attr_val_is_uri.
This creates an inconsistency where action is protocol-sanitized, but formaction is not.
As a result, if a downstream application allows:
- tags such as
<button>or<input> - the
formactionattribute
then Bleach preserves dangerous URI schemes such as javascript: in formaction.
Examples of affected submit-capable controls include:
<button>(default submit behavior unlesstype="button"is set)<input type="submit"><input type="image">
This appears to be a real library-side sanitizer gap rather than only an application misuse issue, because Bleach already treats similar URI-bearing attributes (such as action) as protocol-sensitive and sanitizes them.
Suggested minimal fix:
Add:
(None, 'formaction')
to attr_val_is_uri in:
bleach/_vendor/html5lib/filters/sanitizer.py
I also prepared a minimal patch and focused regression tests if helpful.
PoC
Below are minimal reproductions using bleach.clean().
1) <button>
from bleach import clean
print(clean(
'<form><button formaction="javascript:alert(1)">go</button></form>',
tags={'form', 'button'},
attributes={'button': ['formaction']},
))
Actual output:
<form><button formaction="javascript:alert(1)">go</button></form>
Expected output:
<form><button>go</button></form>
2) <input type="submit">
print(clean(
'<form><input type="submit" formaction="javascript:alert(1)" value="go"></form>',
tags={'form', 'input'},
attributes={'input': ['type', 'formaction', 'value']},
))
Actual output:
<form><input type="submit" formaction="javascript:alert(1)" value="go"></form>
Expected output:
<form><input type="submit" value="go"></form>
3) <input type="image">
print(clean(
'<form><input type="image" formaction="javascript:alert(1)" src="/foo.png"></form>',
tags={'form', 'input'},
attributes={'input': ['type', 'formaction', 'src']},
))
Actual output:
<form><input type="image" formaction="javascript:alert(1)" src="/foo.png"></form>
Expected output:
<form><input type="image" src="/foo.png"></form>
Impact
This is a client-side HTML sanitization bypass / dangerous URI preservation issue.
If an application relies on Bleach to sanitize untrusted HTML and explicitly allows:
formaction- and submit-capable controls such as
<button>or<input>
then Bleach can emit sanitized output that still contains a dangerous javascript: URI in formaction.
That can lead to submit-triggered JavaScript execution when the user activates the control.
Impact is limited to configurations that explicitly allow the relevant tag/attribute combination, but the issue is still security-relevant because:
formactionis a real browser sink- Bleach already protocol-sanitizes similar URI-bearing attributes like
action - the omission creates inconsistent sanitizer coverage for dangerous URI schemes
I would currently assess this as Medium severity.
If useful, I also have:
-
a minimal patch
-
focused regression tests for:
<button formaction="javascript:..."><input type="submit" formaction="javascript:..."><input type="image" formaction="javascript:...">- a safe control case where
formaction="/submit"is preserved
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | bleach | all versions | 6.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for bleach. 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.
Fix
Update bleach to 6.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gj48-438w-jh9v 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 pinpoints whether GHSA-gj48-438w-jh9v 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-gj48-438w-jh9v. 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-gj48-438w-jh9v in your dependencies?
O3 detects GHSA-gj48-438w-jh9v across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.