decidim-elections: Election question titles allow stored script executionGHSA-9mvp-w4rr-5c6x
MEDIUMFix: decidim/decidim#16659GHSA-9mvp-w4rr-5c6x is a medium-severity (CVSS 4.8) Cross-site Scripting (XSS) vulnerability in decidim-elections. A fix is available for decidim-elections — 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-9mvp-w4rr-5c6x.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-9mvp-w4rr-5c6x by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
decidim-electionsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
Description
A low-privilege process-scoped admin who can manage elections can store arbitrary HTML in the question statement/body without sanitization, and the public elections UI renders that value unsafely.
Technical description
This stored XSS appears because election question titles are rendered as trusted HTML instead of sanitized text. The election question editor stores question.body as a normal translatable string, and the public helper question_title returns that value with html_safe and no sanitization boundary, so any user who can edit election questions can persist markup or script-bearing payloads that later render on public election pages.
Impact
A low-privilege process-scoped admin or other election editor with question-management rights can persist JavaScript that executes in visitor's browsers on public election pages and voting booth screens.
Patches
See https://github.com/decidim/decidim/pull/16659
Workarounds
Developers should review their implementation's administrator accesses and not give access to untrustworthy users
Resources
OWASP XSS Injection
Credits
This issue was discovered in a security audit organized by the Decidim Association and made by Radically Open Security against Decidim financed by NGI.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | decidim-elections | all versions | 0.32.0bundle update decidim-elections --conservative |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for decidim-elections, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update decidim-elections to 0.32.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9mvp-w4rr-5c6x 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.
Frequently Asked Questions
Is GHSA-9mvp-w4rr-5c6x in your dependencies?
Find it across RubyGems, including transitive dependencies.