The primary vulnerability stems from the buildTabTransclude function in TabberNeueHooks.php. In the original code (introduced in d8c3db4), $pageName (user-controlled input) was directly interpolated into an HTML error message via sprintf() without escaping. This was patched in f229cab by adding Sanitizer::escapeHtmlAllowEntities(). The PoC demonstrates this vector by injecting a <script> tag via the page name parameter. The other two reported issues were deemed invalid/unreachable: (1) recursiveTagParse usage in Tabber.php is mitigated by MediaWiki's parser sanitization, and (2) TabberParsoid.php's code was unused. The confidence is high due to the reproducible PoC and explicit patch addressing this specific code path.
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| starcitizentools/tabber-neue | composer | >= 1.9.1, < 2.7.2 | 2.7.2 |
For the second XSS, I have given up attempting to reproduce it after over twenty minutes of "surfing through the internals of the MediaWiki parser fishing for an XSS out of this giant contraption as I bring myself deeper and deeper into the cogs of the machine that no one knows how to maintain or fully operate ever since its conception".
For the third XSS, this is unreachable as the class is never used, though it should be fixed anyway (or the file removed).
Any user with the ability to cause another user to render wikitext (such as viewing a page that the user can edit, or an attacker tricking the victim to click on a link to Special:ExpandTemplates with the malicious wikitext in the wpInput parameter) can XSS said user.
Ongoing coverage of React2Shell