Hugo: XSS via text/html content filesGHSA-c54g-xjwj-8g82
Fix: gohugoio/hugo@e41a064GHSA-c54g-xjwj-8g82 is a Cross-site Scripting (XSS) vulnerability in github.com/gohugoio/hugo. A fix is available for github.com/gohugoio/hugo — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-c54g-xjwj-8g82.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
github.com/gohugoio/hugoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Commit: e41a06447d — Disallow HTML content by default
Affected versions: all Hugo versions prior to v0.162.0.
Fixed in: v0.162.0.
Severity: Low to Medium, depending on threat model. Not an issue if you fully trust every file under /content and every content adapter you load.
Description. Hugo accepts content files in several markup formats. Files mapped to the text/html media type (typically .html files under /content, or pages produced by a content adapter that sets content.mediaType = "text/html") had their body emitted verbatim into the rendered page. A site that ingests HTML content from an untrusted source — for example, a CMS-backed editor, a content adapter pulling from an external API, or an automated import pipeline — could therefore be served stored cross-site scripting.
Mitigation. v0.162.0 introduces a security.allowContent whitelist with text/html denied by default. Sites that intentionally author HTML content can opt back in:
[security]
allowContent = ['.*']
This only affects pages whose source file (or content adapter output) declares an HTML media type; Markdown, AsciiDoc, Org, Pandoc and reStructuredText content is unaffected.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gohugoio/hugo | all versions | 0.162.0go get github.com/gohugoio/hugo@v0.162.0 |
Affected Products
hugogohugoDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gohugoio/hugo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/gohugoio/hugo to 0.162.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c54g-xjwj-8g82 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | hugo-main-0.163.3-0.1.hum1 | RHSA-2026:36862 |
Frequently Asked Questions
Is GHSA-c54g-xjwj-8g82 in your dependencies?
Find it across Go, including transitive dependencies.