Em resumo: a segurança do MediaWiki após o PHP2Shell começa no PHP do servidor, pois a vulnerabilidade está aí e não na wiki. As wikis internas ficam muitas vezes anos sem ser mexidas e correm em versões antigas do PHP. Verifique o estado em Especial:Versão, aplique o patch e reinicie e controle depois LocalSettings.php, images e os administradores de interface.
Porque as wikis internas são um alvo compensador
O MediaWiki serve em muitas empresas, organismos públicos e instituições de investigação como manual interno. Aí estão procedimentos, interlocutores, planos de rede, instruções para servidores e, por vezes, até credenciais que não deviam estar lá. Para um atacante, uma wiki destas é um mapa da empresa.
Segundo a equipa do PHP, as vulnerabilidades PHP CVE-2026-109618 e CVE-2026-109619 permitem executar código malicioso remotamente sem autenticação. Uma wiki pensada «só para uso interno», mas acessível pela Internet, fica assim diretamente exposta. E como as wikis raramente estão no foco da TI, correm muitas vezes em servidores antigos, frequentemente ainda com o PHP como módulo do Apache, o modo de operação de maior risco segundo a equipa do PHP.
Segurança do MediaWiki: verificar a versão do PHP e o estado do patch
A página Especial:Versão mostra a versão do MediaWiki, do PHP e da base de dados, bem como todas as extensões e skins instaladas. As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Muitos servidores de wiki correm em distribuições Linux com backports; o número apresentado mantém-se então igual, embora o patch esteja aplicado.
Se a wiki correr no PHP 8.1 ou anterior, o projeto PHP já não publica atualizações oficiais, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. O que vale então resume-o PHP 8.1 e anteriores. Quais as versões do PHP que a sua versão do MediaWiki suporta, verifique-o nos requisitos de sistema em mediawiki.org. Uma mudança de PHP pode pressupor uma atualização do MediaWiki.
Os scripts de manutenção e os job runners correm através do PHP da linha de comandos. Também esta versão tem de ter o patch aplicado. Se a fila de jobs correr como serviço permanente, este tem de ser reiniciado após a atualização, tal como o servidor web ou o PHP-FPM. Com o mod_php, isso significa reiniciar o próprio Apache, pois o PHP está aí dentro do processo do servidor web.
Esclareça ainda a quem pertence a wiki. As wikis internas foram muitas vezes montadas por um departamento e correm fora da manutenção normal dos servidores. Sem responsabilidade clara, é aí que a atualização do PHP fica parada mais tempo.
Pastas e ficheiros no MediaWiki
| Local | Conteúdo | Ponto de verificação |
|---|---|---|
LocalSettings.php |
Acesso à base de dados, $wgSecretKey, $wgUpgradeKey, direitos, definições de upload |
Código inserido, renovar chaves em caso de suspeita |
images/ |
Ficheiros carregados e miniaturas | Sem ficheiros PHP, sem execução de PHP |
extensions/, skins/ |
Extensões e designs | Ficheiros desconhecidos ou alterados |
cache/ |
Memória intermédia | Esvaziar após a limpeza |
maintenance/ |
Scripts de manutenção para a linha de comandos | Não usar através da web |
O diretório de uploads não deve executar scripts ao nível do servidor web. No Apache, isso faz-se assim, independentemente do modo de operação do PHP:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Uma primeira verificação inofensiva:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Verifique o histórico de versões das páginas MediaWiki:Common.js e MediaWiki:Common.css. As alterações aí têm efeito para cada visitante da wiki e são um local típico para código introduzido.
Direitos, grupos e extensões
No MediaWiki, a segurança é decidida pelos grupos de utilizadores. Verifique em Especial:Lista de utilizadores e Especial:Direitos de utilizador quem pertence aos grupos de administradores, burocratas e administradores de interface. Os administradores de interface podem alterar o JavaScript de toda a wiki; este grupo deve ser muito pequeno.
Numa wiki interna, a leitura sem início de sessão deve estar desativada e o registo de novas contas bloqueado. Permita uploads apenas para os tipos de ficheiro realmente necessários. As extensões trazem código PHP próprio; as extensões sem manutenção travam, além disso, qualquer atualização. Para os direitos de ficheiros no servidor, o guia Direitos de ficheiros no servidor web dá uma orientação.
O que uma atualização do MediaWiki consegue e o que não consegue
Uma atualização do MediaWiki substitui o núcleo e corrige falhas conhecidas nele. Não aplica patch ao PHP, não reinicia processos PHP, não altera nada em LocalSettings.php e não remove nem ficheiros em images/ nem alterações em MediaWiki:Common.js ou membros de grupo adicionais. Também não prova que, antes do patch, ninguém esteve a espiar.
Uma vista geral rápida dão ainda os registos em Especial:Registos. Novas contas de utilizador, alterações nos direitos de grupo e edições de páginas de interface desde 17/10/2026 ficam aí anotadas com a hora.
Como ajuda concretamente a PHP SOS?
- Verificamos a versão do PHP, o modo de operação e o estado dos backports do seu servidor de wiki e fazemos confirmar o reinício.
- Guardamos registos a partir de 20/10/2026, a base de dados e os ficheiros.
- Verificamos
LocalSettings.php, uploads, extensões, direitos de grupo e o histórico de versões das páginas de interface. - No âmbito da ajuda imediata PHP2Shell, avaliamos consigo se a wiki tem de continuar acessível publicamente.
Perguntas frequentes
O MediaWiki é afetado pelo PHP2Shell?
O MediaWiki em si não tem uma nova vulnerabilidade, mas corre em PHP. Se o PHP do servidor não tiver patch, um atacante pode, segundo a equipa do PHP, executar código sem autenticação. Uma atualização do MediaWiki não corrige a falha.
Onde vejo a versão do PHP da minha wiki?
Na página Especial:Versão, o MediaWiki lista o software instalado, incluindo a versão do PHP. Aí não se reconhece se foi aplicado um backport; isso é confirmado pelo operador do servidor.
Porque é o MediaWiki:Common.js um risco?
O conteúdo desta página é entregue como JavaScript a todos os visitantes da wiki. Quem a puder alterar pode executar código no navegador de cada utilizador. Por isso, o grupo dos administradores de interface deve ser muito pequeno.
Basta tornar a wiki acessível apenas internamente?
Uma wiki acessível apenas na rede da empresa ou por VPN reduz claramente o risco, porque os atacantes da Internet não lhe chegam diretamente. Ainda assim tem de aplicar o patch, pois um ataque também pode vir da rede interna.