CVE-2026-30913: Link Injection and Content Spoofing in Flarum Nicknames Extension

The flarum/nicknames extension provides functionality for users to set custom display names within Flarum forum deployments. This component interacts directly with the core notification system to personalize outbound communications. Prior to version 1.8.3, the extension lacked adequate output sanitization for plain-text email templates.

The vulnerability is classified under CWE-79, though its execution context is email clients rather than web browsers. When the extension is enabled, an attacker can set their nickname to a string formatted as a domain or a Markdown hyperlink. The Flarum application inserts this string verbatim into notification emails sent to other users.

Modern email clients automatically parse plain-text bodies to identify and convert domain names or Markdown syntax into clickable URLs. This behavior allows the attacker to inject arbitrary hyperlinks into administrative or notification emails originating from the trusted forum domain. The resulting attack vector facilitates targeted phishing campaigns and content spoofing.

The core vulnerability resides in the NicknameDriver class, which handles the retrieval and formatting of user display names. The displayName method historically returned the user's customized nickname without applying any context-aware escaping or sanitization. This implementation assumed that plain-text emails required no specialized encoding.

This assumption fails to account for the secondary parsing engines present in modern email clients like Gmail and Outlook. These clients employ aggressive regular expressions to detect domains, email addresses, and sometimes Markdown structures, automatically converting them into active HTML anchor tags. The Flarum application unwittingly acts as a trusted transport mechanism for this unvalidated payload.

Two distinct injection variants exist due to this architectural disconnect. The first variant relies on domain autolinking, where an attacker sets their nickname directly to a malicious domain. The second variant utilizes Markdown or basic HTML syntax, which specific email clients may render into deceptive text-based hyperlinks, masking the underlying destination URL.

Prior to the fix, the displayName method in src/NicknameDriver.php executed a simple conditional return. The code checked for the existence of a nickname and returned it unmodified; otherwise, it defaulted to the standard username. This lack of intervention allowed characters like brackets, parentheses, and structural dots to persist into the email template.

The pre-patch implementation is observable in the following snippet:

public function displayName(User $user): string
{
    return $user->nickname ? $user->nickname : $user->username;
}

This function provided a direct conduit from the database entry to the outbound notification service.

The patch introduced in commit 4dde99729abdce8f6e2a7437c86e38735fdcca28 modifies src/NicknameDriver.php to neutralize parser-sensitive characters. The updated logic strips structural Markdown characters and injects a Unicode Zero-Width Space (\u{200B}) after every dot. This targeted modification breaks the regular expressions used by email clients for domain autolinking while maintaining the visual presentation of the nickname.

The updated render-time sanitization logic is implemented as follows:

public function displayName(User $user): string
{
    $name = $user->nickname ? $user->nickname : $user->username;
    $name = str_replace(['[', ']', '(', ')', '<', '>'], '', $name);
    return str_replace('.', ".\u{200B}", $name);
}

This function effectively mitigates the vulnerability for both new inputs and legacy data residing in the database.

Exploitation requires the attacker to possess a registered account on a Flarum instance with the flarum/nicknames extension enabled. The attacker navigates to their profile settings and updates their nickname to contain the malicious payload. Standard Flarum validation rules permit the required characters prior to version 1.8.3.

Once the payload is stored, the attacker must force the Flarum application to generate a notification directed at the intended victim. This is typically achieved by mentioning the victim in a public post, replying to a discussion the victim is subscribed to, or following the victim's account. The Flarum backend processes this action and queues an outbound plain-text email.

The victim receives an email originating from the legitimate forum server. The email client's rendering engine processes the message body, identifies the attacker's nickname, and converts it into a clickable link. The victim, trusting the source domain of the email, is socially engineered into clicking the malicious link.

The attack flow is illustrated in the following diagram:

The primary impact of this vulnerability is the facilitation of high-fidelity phishing campaigns. Because the malicious links are delivered within administrative emails originating from a trusted forum domain, they bypass many traditional spam filters. Victims are more likely to interact with links presented in this trusted context.

The CVSS v3.1 base score is 4.6 (Medium), reflecting the localized severity of the issue. The attack vector is Network (AV:N), but it requires Low privileges (PR:L) to set the nickname and relies on User Interaction (UI:R) for successful execution. The impact is isolated to Low Confidentiality and Low Integrity regarding the victim's immediate interaction.

While the Flarum server itself remains uncompromised, the vulnerability poses a substantial risk to organizational trust and user safety. Attackers can leverage the forum's reputation to distribute malware or harvest credentials for unrelated services. The spoofed content relies entirely on the email client's interpretation of the unmodified string.

The vendor addresses this vulnerability in the flarum/nicknames extension version 1.8.3. Administrators must update the extension via Composer to apply the necessary save-time validation and render-time sanitization. Following the update, clearing the Flarum cache ensures the application serves the patched driver logic.

The patch implements a defense-in-depth strategy that handles both new and existing data. In addition to the render-time sanitization, src/AddNicknameValidation.php is updated to reject new nickname submissions containing brackets, parentheses, or angle brackets. This prevents the initial storage of obvious payload structures.

While the render-time fix securely displays legacy nicknames, administrators should still audit the database for pre-existing malicious entries. Executing a SQL query to identify nicknames containing URLs or Markdown syntax allows operators to identify potentially compromised accounts. Proactive cleanup removes the underlying malicious data from the system entirely.