CVE-2026-73038

This is a stored XSS with a critical difference: the attacker never needs an account on your server. CVE-2026-73038 exploits ActivityPub's federation model — a malicious or compromised server sends specially crafted emoji tag data that NodeBB stores and renders without sanitization. When your users view federated content, the payload executes automatically in their browsers. This isn't user clicks a link; it's persistent, automatic code execution across every instance that federates with the attacker's server. The specific attack surface is tag.icon.url and tag.name in ActivityStreams objects. These are structured protocol fields, not arbitrary input — the vulnerability exploits a data model path in NodeBB's renderEmoji function, which was written assuming trusted input from internal sources, not raw federation data. The fix location in renderEmoji suggests the sanitization happened at render time rather than at federation ingestion, which raises a architectural question: did NodeBB close the vulnerability or merely obscure it? The CVSS 6.1 score fundamentally misrepresents this vulnerability. CVSS assumes single-node impact — one server, one exploit. ActivityPub has no such containment. One compromised federated server injects payloads that execute on every Mastodon, PixelFed, Calckey, and NodeBB instance that federates with it. The blast radius is the entire fediverse graph, not your server. Two immediate actions: First, verify your NodeBB version and upgrade to 4.15.0 if you haven't. Second, audit which federated servers you've federated with — if any were compromised or turned malicious before the patch, their injected data is still sitting in your database. Blocking them at the federation layer doesn't scrub stored payloads. You may need to re-sanitize or purge historical federation data from actors you now distrust. The deeper problem is architectural: ActivityPub implementations must treat ALL data from federated servers as untrusted by default, including structured protocol fields. The security boundary belongs at the federation ingestion layer, not scattered across individual rendering functions. Otherwise you're playing whack-a-mole with every code path that pulls ActivityPub fields into a rendering context.

Reviewed through automated stages and approved by a human before publication.