As of 36171312ef0 we have:
$wgCacheDirectory = false;
$wgLocalisationCacheConf = [
'class' => 'LocalisationCache',
'store' => 'detect',
'storeClass' => false,
'storeDirectory' => false,
'manualRecache' => false,
];And in LocalisationCache we have:
case 'detect':
if ( !empty( $conf['storeDirectory'] ) ) {
$storeClass = 'LCStoreCDB';
} else {
$cacheDir = $wgCacheDirectory ?: wfTempDir();
if ( $cacheDir ) {
$storeConf['directory'] = $cacheDir;
$storeClass = 'LCStoreCDB';
} else {
$storeClass = 'LCStoreDB';
}
}Which in effect means for someone on a shared host using default config, they are probably going to use /tmp for their localisation cache directory.
This is a bad idea because having multiple wikis with different extensions/mw versions use the same localisation cache directory means they are going to step over each other, since this creates files named like l10n_cache-en.cdb (which doesn't have wiki id in it). This makes sense if you have a consistently configured wiki farm or manual localisation cache refreshes. It makes less sense in a generic shared host (Just try and install MediaWiki on tool labs and see the permission fatals).
More importantly though, this has a security impact. Another user on the system can insert an evil cache file (You don't really even need a race condition, just chose a really obscure language).
The most obvious thing to do would be to change one of the raw html messages, in order to XSS (Actually editing Common.js seems a bit harder, since you would need to force a RL cache purge somehow, but i can confirm this works for other various raw messages).
However, since these fields get run through unserialize(), you can actually execute arbitrary code as the web user