The Neglect of BBCode

Subscribe to RSS

07/31/2025

Let me start this post by saying that I am not a cybersecurity expert! As can be seen on this website, I mainly make software, usually software that's somehow related to linguistics. This is a bit of a detour from what I usually talk about, but I feel it's both important enough and not publicly known enough that I should post it here. If you're from Higher Logic, I'm glad I have your attention now, please reply to my email I sent two months ago!

TL;DR, what's the vuln?

In vanilla/nbbc specifically, custom tags do not properly sanitize input, allowing for malicious JavaScript to be inserted and run by merely loading the page it's on.

Where it all begins

Around two months ago, I woke up to an @everyone ping in the Art Fight Discord server. Seeing how this was before this year's event started, I thought perhaps it was the theme reveal or maybe some pre-release merchandise. What I found instead was a rather vague announcement saying there was a "recent security issue" and to check this newspost. Knowing that the Art Fight community isn't the most technical, I decided to watch #general to see some... interesting... takes made by users, such as "You can check if your account's been affected by checking your Gmail settings" and "XSS attacks give access to all of your passwords and email account". Mildly entertained and now a bit more awake, I got into a voice call with a friend of mine and read the full announcement. Reading it worried me quite a bit, as I quickly realized that Art Fight used PHP and BBCode, both of which are used on this website! Once the more in-depth announcement was posted, I noticed the owner in #general, and started to ask how I could get into contact with the developer team, not expecting a response due to how fast chat was moving at the time. However, this surprisingly got me in contact with the head developer! When talking to him, I quickly learned that Art Fight was using vanilla/nbbc as their BBCode parser, and no CVE exists for this. I also recieved the malicious comment in question, the JavaScript meant to steal login credentials replaced with alert(1):

[imgleft]http://<>deleteme9012#[url=' onerror=this.remove();alert(1)//'][/url][url]http://deleteme9012.com/<>?a=[/img][img]http://deleteme9012.com/<>?a=1'"a[/imgleft][url=http://deletme9012.com/<>] [/url][/url]

It should be noted that neither "deleteme9012.com" nor "deletme9012.com" are registered domains (at least at the time of testing), causing the image loading to always fail, thus always triggering the onerror attribute.

Testing

After getting some tea and searching for existing CVEs, I started testing. Starting with the presumption that this is applicable to all [img] tags, I tried yet failed to reproduce this vulnerability with nbbc. I decided to come back to it, and decided to test with some other BBCode parsers. I had a hunch that this would work with most other BBCode parsers, but as my experience with BBCode is mostly limited to phpBB, I simply searched up "php bbcode parser" and tested the ones that came up. Once I got it to work with genert/bbcode, I realized I'd be testing quite a few parsers, so I set up a KDE vault and continued testing there. Next I tested jBBCode, and got it to work with the following BBCode:

[b]Hello World![/b][img]https://oijon.net/invalid_img.png[/img][img]https://oijon.net/invalid_img.png#\"onerror=\"alert(1);

I got a similar result using chriskonnertz/bbcode, with the following BBCode triggering the vulnerability:

[img]https://oijon.net/invalid_img.png?"onerror="alert(1);" [/img]

After getting these (+ a few more where I couldn't find contact info) working, I decided to focus on vanilla/nbbc once more. Despite my assumption holding true for other parsers, nbbc required some sort of custom BBCode tag in order for this to work. To do this, there's two different modes of custom tags, simple and enhanced. I acquired the vulnerable [imgleft] tag from the head developer of Art Fight, and tweaked it to work for both modes. These tweaked custom tags consisted of the following:

  1. $bbcode->AddRule('imgright-simple, Array(
  2. 'simple_start' => '<img style="float:right" src="',
  3. 'simple_end' => '">',
  4. 'class' => 'inline',
  5. 'allow_in' => Array('listitem', 'block', 'columns', 'inline', 'link'),
  6. ));
  8. $bbcode->addRule('imgright-enhanced', Array(
  9. 'mode' => BBCode::BBCODE_MODE_ENHANCED,
  10. 'template' => '<img style="float:right" src="{$_content}"></img>',
  11. 'class' => 'inline',
  12. 'allow_in' => Array('listitem', 'block', 'columns', 'inline', 'link'),
  13. ));

Using these two custom tags, the following BBCode allows for XSS attacks:

[imgright-simple]https://oijon.net/img/logo.png#[url=' onload=alert(1);//'][/url][/imgright-simple]

[imgright-enhanced]https://oijon.net/img/logo.png#[url=' onload=alert(2);//'][/url][/imgright-enhanced]

What's interesting here is that, in the built-in [img] tag, [url] tags are automatically moved outside the [img] tag, thus preventing this kind of vulnerability from occuring. After all this, I went and contacted each maintainer, gave each a summary of the issue, and awaited replies. Unfortunately, not a single maintainer bothered to reply to my emails.

Response from maintainers

There are a few parsers not listed that I was able to reproduce this vulnerability, however could not find any contact details for the maintainers. As I technically have not disclosed the vulnerability to those maintainers, I will not say which parsers are in this category.

Overall, I am incredibly disappointed at the state of BBCode parsers. Out of all the maintainers I contacted (one of which being a rather large company), not a single one bothered to either reply back or attempt to fix the issue. Perhaps this is simply because BBCode is not as popular as it once was, but surely one should actually maintain their project if there's no indication that it's no longer being maintained. I am currently in the process of getting CVEs registered, I hope that process goes well. Perhaps I'll make my own parser, but if I end up doing that, it'll be quite awhile before I actually get around to that.

From my understanding, when a vulnerability is being used in-the-wild, it's best to disclose it 45 days after disclosing it to the maintainer. I decided to give the maintainers a bit more time, hoping that at least one of them would respond, but that does not seem to be the case. As of today, it's been 66 days since I contacted maintainers about this issue. To me, this is an issue of severe neglect among most BBCode parsers. When software is neglected, eventually vulnerabilities appear. I can only hope that no other website is impacted by this.

Timeline

All times in Eastern Daylight Time

Back