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