CVE-2026-30913 is a medium-severity (CVSS 4.6) Cross-site Scripting (XSS) vulnerability in flarum/nicknames. A fix is available for flarum/nicknames — see the affected versions and patch details below.
flarum/nickname: Display name injection in notification emails (autolink & markdown)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-30913.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
flarum/nicknamesReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
When the flarum/nicknames extension is enabled, a registered user can set their nickname to a string that email clients interpret as a hyperlink. The nickname is inserted verbatim into plain-text notification emails, and recipients may be misled into visiting attacker-controlled domains.
Affected package
flarum/nicknames— permissive display name driver that allows special characters; affected since initial release on the1.xbranch
Any third-party display name driver that permits special characters would be equally affected.
Variants
- Domain autolink — a nickname such as
nasty.comis automatically converted to a clickable hyperlink by virtually all email clients (Gmail, Outlook, Apple Mail, Thunderbird). - Markdown link syntax — a nickname such as
[CLICK](https://evil.com)is rendered as a clickable hyperlink by email clients that auto-render markdown in plain-text emails (e.g. Apple Mail, Thunderbird).
Steps to reproduce
Variant 1 (autolink — affects all email clients)
- Enable
flarum/nicknames, set nickname tonasty.com - Trigger a notification email to another user (e.g. follow them, mention them)
- The nickname appears as a clickable link in the received email
Variant 2 (markdown — affects markdown-rendering email clients)
- Enable
flarum/nicknames, set nickname to[CLICK](https://evil.com) - Trigger a notification email to another user
- In a markdown-rendering email client (e.g. Apple Mail), the nickname appears as a clickable link
Impact
Phishing / social engineering: victims may be misled into visiting attacker-controlled URLs via links appearing to originate from a trusted platform notification email. Variant 1 is exploitable against virtually all email clients without any special conditions.
- CVSS v3.1:
AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N— 4.6 Medium
Root cause
The default username-based display name driver constrains values to [a-zA-Z0-9_-]+, making it immune. flarum/nicknames introduced permissive validation (min/max length and an optional admin-configured regex) that allows arbitrary characters including those meaningful in URL and markdown contexts. This has been the case since the first commit of the extension.
Proposed fix
- Add validation in
flarum/nicknamesto reject or sanitize nicknames containing characters that email clients may interpret as URLs or markdown links - Alternatively, sanitize the display name before insertion into notification email bodies so that legitimate nicknames like
Jane.Smithare preserved but rendered safely
References
- Bug bounty submission: SBB-L4ZVAFH8 (Intigriti)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | flarum/nicknames | all versions | 1.8.3composer require flarum/nicknames:^1.8.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flarum/nicknames, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update flarum/nicknames to 1.8.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-30913 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 CVE-2026-30913 in your dependencies?
Find it across Packagist, including transitive dependencies.