Without looking into these further, I'm going to guess they are false positives. The way many of these automated scanning tools work is that if they can fuzz a query parameter or two for a url (in this case with sqli payloads) and elicit different http response codes, they assume there's a blind sqli. That's almost certainly not the case for load.php and api.php, but we can keep this security-protected until someone has the chance to further investigate.

Neither of these are... The api.php one complains about bad params. It's definitely not doing an SQL query

<warnings><main xml:space="preserve">Unrecognized parameters: recursivesubmodules, modules.</main></warnings>

The load.php one doesn't do an SQL query for the skin parameter either, not that that's what it's complaining about anyway (at least on enwiki)

/*
Problematic modules: {"mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cskins.vector.styles":"missing"}
*/

Indeed. Both are working as intended. The invalid parameters are correctly rejected by the respective request handlers.

While I understand that there's no SQL query executed here, is it really harmless to have Mediawiki echo everything back that is passed in the URL? In a Mediawiki 1.34.0 installation I get:

$ curl -L https://example.com/mediawiki/load.php?modules=foo
mw.loader.state({"foo":"missing"})

Curiously enough, when calling something else (i.e. not "modules") the standard placeholder is returned:

$ curl -L https://example.com/mediawiki/load.php?X=foo
/* This file is the Web entry point for MediaWiki's ResourceLoader:
   <https://www.mediawiki.org/wiki/ResourceLoader>. In this request,
   no modules were requested. Max made me put this here. */

IOW, shouldn't Mediawiki return the same placeholder for everything else except modules=skins.vector.styles (and all the other installed modules)?

We want client side to be able to detect missing modules.

There are scenarios where reflecting input can be dangerous, but i think proper precautions are taken here

Indeed. This is no different from searching for a word on a search engine and the response including "You searched for …"

All text displayed on the web needs to be escaped for HTML to render correctly. Security is merely a compounding factor. Even "trusted" text must be escaped in order to render correctly, otherwise special characters can take up different meanings leading to all kinds of functional problems.

Unless you find unescaped or wrongly escaped content (regardless of whether it came from the user or not), there is no problem. The convention in security analysis is to emulate user input, I believe because that makes it easier to verify a problem because the original input is right next to it. Problems with trusted input are harder to verify because you might not know the original (perhaps the original already had the problem, etc.)

OK, understood. Thanks for clearing that up! 👍