Per T178349. ReplaceText might be bundled. We want to do a security review before next release so we could potentially bundle it.
Items from review:
[X] Seems to have no CSRF check. Given the potential destructive nature of the tool, this is rather serious. (https://gerrit.wikimedia.org/r/#/q/Ib6a951152db222b6289b9b8d09608dfe75ed2de2)
[X] It should use resource loader instead of inline javascript and $out->addScriptFile() (https://gerrit.wikimedia.org/r/#/c/425453/)
[X] Maybe $wgReplaceTextUser should be added to the UserGetReservedNames hook so user's can't register that name for themselves.
[X] The job should maybe use RequestContext::importScopedSession so that it is more compatible with things like CheckUser
[X] "replaceAll.php" line 178 - summary should probably just be a ->plain() msg with normal parameters.
[X] The code for Special:ReplaceText is a bit hard to follow in parts. It maybe could benefit from splitting long functions into smaller functions.
[] The extension sets the ungreedy and unicode flags for regexes in PHP but does not set it mariadb. Starting in 1.10.11 this can be set using https://mariadb.com/kb/en/library/server-system-variables/#default_regex_flags . Prior to that it would always be ungreedy (and prior to 1.10.5 mariadb didn't even use pcre). Most of the time, this only controls how the pattern matches not what the pattern matches, but if you use advanced pcre features the ungreedy flag could potentially change whether the regex matches at all.
[] This won't work with $wgCompressRevisions or $wgExternalStores. Which is also fairly well known. However, ideally there would be some sort of error message for that case. It could perhaps be worked around (In a really slow way), by having it consider anything that matches `'old_flags LIKE \'%object%\' OR old_flags LIKE \'%external%\''` as matching the regex, and then have the job actually determine if they match, but then the preview step wouldn't work.
[] "SpecialReplaceText.php" line 603 - Has weird escaping. I don't think its exploitable, but its a bit sketchy.
[] "ReplaceTextJob.php" line 39 might handle colons incorrectly. Should probably use makeTitleSafe + error handling for invalid page names. [However it may be hard to trigger this because of how code in Special:ReplaceText works]
[] There's also T142314 - Mostly irrelavent now due to being out of date, and ReplaceText isn't actually vulnerable. Might make sense to check patterns for null bytea and for `/`'s that aren't preceeding by a `\`, just as a paranoia measure.
No action taken:
* This won't scale to large wikis due as the "search" part of the process is not done as part of the job (I think this is a well known fact, and replace text doesn't intend to scale to really big wikis, I'm just stating for the record)
* It should of course be noted for the record if we're having a security discussion about this tool, that its a very powerful tool, that in the wrong hands can mass vandalize your wiki. (That kind of goes without saying of course)