{"answers":{"affected":"2 open source packages ship an affected version, including loofah.","exploited":"There is no known exploitation of GHSA-46fp-8f5p-pf2m in the wild and no public exploit code.","fix":"Upgrade loofah to 2.25.1 or later.","what":"GHSA-46fp-8f5p-pf2m is a cross-site scripting vulnerability in loofah, published on 18 Mar 2026. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link."},"fix_prompt":"Check this codebase for GHSA-46fp-8f5p-pf2m and fix it if it is affected.\n\nWhat it is: GHSA-46fp-8f5p-pf2m is a cross-site scripting vulnerability in loofah, published on 18 Mar 2026. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.\nExploitation: There is no known exploitation of GHSA-46fp-8f5p-pf2m in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- loofah (RubyGems): affected from 2.25.0; fixed in 2.25.1\n- loofah (RubyGems): affected from 2.25.0; fixed in 2.25.1\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-46fp-8f5p-pf2m/ (Markdown: https://insights.sbomify.com/GHSA-46fp-8f5p-pf2m/index.md)","id":"GHSA-46fp-8f5p-pf2m","markdown":"https://insights.sbomify.com/GHSA-46fp-8f5p-pf2m/index.md","name":"GHSA-46fp-8f5p-pf2m","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["code_execution"],"network_reachable":"yes","non_default_config":true,"product_category":"Ruby HTML sanitizer","requires_auth":"none","summary":"Attackers can bypass URI validation to inject JavaScript, causing XSS in applications directly using the allowed_uri? helper.","user_interaction":"required","vuln_class":"xss"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"## Summary\n\n`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` URIs when the scheme is split by HTML entity-encoded control characters such as `\u0026#13;` (carriage return), `\u0026#10;` (line feed), or `\u0026#9;` (tab).\n\n## Details\n\nThe `allowed_uri?` method strips literal control characters before decoding HTML entities. Payloads like `java\u0026#13;script:alert(1)` survive the control character strip, then `\u0026#13;` is decoded to a carriage return, producing `java\\rscript:alert(1)`.\n\nNote that the Loofah sanitizer's default `sanitize()` path is **not affected** because Nokogiri decodes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects direct callers of the `allowed_uri?` string-level helper when passing HTML-encoded strings.\n\n## Impact\n\nApplications that call `Loofah::HTML5::Scrub.allowed_uri?` to validate user-controlled URLs and then render approved URLs into `href` or other browser-interpreted URI attributes may be vulnerable to cross-site scripting (XSS).\n\nThis only affects Loofah `2.25.0`.\n\n## Mitigation\n\nUpgrade to Loofah \u003e= `2.25.1`.\n\n## Credit\n\nResponsibly reported by HackOne user `@smlee`.","ecosystems":["RubyGems"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Improper detection of disallowed URIs by Loofah `allowed_uri?`","id":"GHSA-46fp-8f5p-pf2m","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"RubyGems","product":null,"products":[],"type":"xss","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"RubyGems","fixed":["2.25.1"],"introduced":["2.25.0"],"last_affected":[],"package":"loofah","purl":null,"source":"GHSA-46fp-8f5p-pf2m"},{"ecosystem":"RubyGems","fixed":["2.25.1"],"introduced":["2.25.0"],"last_affected":[],"package":"loofah","purl":"pkg:gem/loofah","source":"GHSA-46fp-8f5p-pf2m"}],"products":null,"published":"2026-03-18","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Attackers can bypass URI validation to inject JavaScript, causing XSS in applications directly using the allowed_uri? helper.","url":"https://insights.sbomify.com/GHSA-46fp-8f5p-pf2m/"}