Em resumo: Um ficheiro que apenas chama phpinfo() mostra a qualquer visitante a versão, os módulos, os caminhos e as definições do PHP, muitas vezes também variáveis de ambiente com credenciais. Para a segurança do phpinfo aplica-se, por isso: nunca deixar esses ficheiros de forma duradoura no webroot, apagá-los após o uso e verificar o estado do PHP de preferência através da gestão de pacotes e da configuração. O estado do patch contra o PHP2Shell, de qualquer modo, não é comprovado por uma saída de phpinfo.
O ficheiro de teste que fica
Desde 21 de outubro de 2026, milhares de administradores verificam que versão do PHP os seus sites servem. O caminho mais rápido é conhecido: criar um ficheiro info.php com uma única linha, abri-lo no navegador, ler o resultado. Funciona. O problema começa depois, quando o ficheiro é esquecido.
Estes ficheiros sobrevivem surpreendentemente muito tempo. Acompanham as mudanças, vão parar a backups e surgem passados anos em diretórios que ninguém conhece. Os scanners automatizados consultam constantemente nomes de ficheiro típicos. O que para o administrador era uma ferramenta de apoio é, para um atacante, uma planta do servidor.
Estão particularmente afetadas as agências e os fornecedores de alojamento com muitos sites de clientes. Quem, numa semana agitada, verifica dezenas de sites cria depressa dezenas de ficheiros de teste. Basta uma única pasta esquecida para que o ficheiro continue acessível meses depois.
O que o phpinfo() revela e porque conta para a segurança
Segundo o manual do PHP, o phpinfo() apresenta o estado atual do PHP. Através de constantes pode controlar-se que partes aparecem; sem indicação, aparece tudo.
| Área (constante) | Conteúdo segundo o manual | Porque é delicado |
|---|---|---|
INFO_GENERAL |
build, localização do php.ini, servidor web, sistema | revela o sistema operativo e os caminhos |
INFO_CONFIGURATION |
valores locais e mestre de todas as diretivas | mostra se disable_functions ou open_basedir estão ativos |
INFO_MODULES |
extensões carregadas com as suas definições | os atacantes veem que funções estão disponíveis |
INFO_ENVIRONMENT |
variáveis de ambiente | aqui estão muitas vezes credenciais de bases de dados ou de APIs |
INFO_VARIABLES |
variáveis predefinidas (Environment, GET, POST, Cookie, Server) | contém cabeçalhos e cookies do pedido atual |
As duas últimas linhas são as mais perigosas. As aplicações modernas carregam de bom grado as credenciais a partir de variáveis de ambiente, por exemplo de um ficheiro .env ou da configuração do contentor. Estes valores aparecem então em texto simples na saída. Como proteger estes segredos em termos gerais é descrito no artigo Proteger corretamente credenciais e ficheiros .env.
Acresce: a saída mostra os valores do pedido em curso, portanto também cookies e cabeçalhos. Se um atacante conseguir levar um visitante à página e ler a resposta, por exemplo através de uma falha de Cross-Site Scripting noutro ponto, tornam-se visíveis até cookies marcados como HttpOnly.
Porque é que o phpinfo não é uma prova contra o PHP2Shell
Muitos criaram o ficheiro precisamente para verificar o estado do patch. É para isso que serve apenas em parte. As distribuições e os fornecedores de alojamento aplicam muitas vezes as correções como backport; segundo relatos, por exemplo, o Ubuntu 24.04 continua a mostrar 8.3.6 após a atualização. O número apresentado diz, portanto, pouco. Inversamente, um número atual não prova que todos os workers foram reiniciados.
Fiável é o estado do pacote com os números CVE no changelog, complementado pelo reinício de todos os processos PHP. Como fazê-lo é explicado no artigo Verificar corretamente a versão do PHP e o nível de patch.
Uma saída temporária no contexto web tem, ainda assim, o seu lugar: mostra que php.ini e que valores se aplicam realmente ao site, pois a linha de comandos lê muitas vezes outra configuração. Os antecedentes sobre níveis e precedência são explicados em O php.ini explicado. Se precisar disso, faça-o com proteção de acesso, nome de ficheiro aleatório e apenas durante minutos.
Para a maioria das perguntas existem de qualquer modo melhores caminhos. A versão do PHP de um pool FPM consta da sua configuração e da lista de processos. Valores individuais podem ser consultados com um script fora do webroot através de ini_get(), sem expor tudo. E nos painéis de alojamento, a interface mostra a versão atribuída a cada site, ainda que sem indicação sobre backports.
Encontrar ficheiros esquecidos: passos de verificação concretos
É assim que localiza resíduos num servidor Linux. Os comandos apenas leem e nada alteram.
- Procurar ficheiros com chamada a phpinfo (adaptar o caminho):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- Verificar nomes de ficheiro típicos, mesmo sem resultados no conteúdo:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
Avaliar os resultados: nem todo o achado é um ficheiro de teste. Ferramentas de administração, painéis ou frameworks podem usar o
phpinfo()por trás de um início de sessão. Decisivo é saber se o ficheiro é acessível a partir da Internet sem autenticação. -
Ver os acessos no registo antes de apagar:
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Apagar e trocar os segredos: se na saída constava uma palavra-passe ou chave e o ficheiro era público, o valor considera-se conhecido. Altere-o.
Um achado com data de criação desconhecida e conteúdo invulgar ao lado da chamada a phpinfo pode ser também uma porta dos fundos. Nesse caso, não se limite a apagar: guarde e mande verificar, ver Detetar e remover uma webshell.
Prevenir de forma duradoura em vez de arrumar
Três medidas garantem que o tema não volta. Primeiro: incluir phpinfo na lista disable_functions do php.ini para o contexto web. Verifique antes se o seu painel precisa da função para uma página de estado. Como a definição atua e onde estão os seus limites está em Usar corretamente o PHP disable_functions.
; php.ini para FPM ou Apache, depois reiniciar todos os processos PHP
disable_functions = phpinfo
expose_php = Off
Segundo: disponibilização apenas através de um processo fixo, por exemplo com Git ou pipeline de build, para que nenhum ficheiro isolado chegue ao webroot à mão. Terceiro: as informações de estado pertencem à monitorização ou ao inventário, não a uma página pública.
O expose_php = Off remove ainda o cabeçalho com que o PHP comunica a sua versão em cada resposta. Não substitui uma atualização, mas retira aos scanners automatizados uma informação cómoda. Quem tem várias pessoas com acesso ao servidor deve ainda acordar uma regra simples: os ficheiros de teste são apagados no mesmo passo de trabalho em que são criados, e não “mais tarde”.
Como ajuda concretamente a PHP SOS?
- Percorremos os seus webroots à procura de ficheiros phpinfo, scripts de teste e outros resíduos e avaliamos cada achado.
- Analisamos os acessos aos ficheiros encontrados e dizemos-lhe que segredos deve substituir.
- Comprovamos o estado do patch contra o PHP2Shell através do changelog do pacote e do arranque dos processos, em vez de uma indicação de versão.
- Implementamos
disable_functions,expose_phpe outros reforços de forma duradoura no âmbito do reforço de segurança de servidores.
Conclusão: Um ficheiro phpinfo cria-se em segundos e esquece-se com a mesma rapidez. Quem o procura e remove agora fecha uma fuga de dados desnecessária e apoia-se, quanto ao estado do patch, em comprovativos fiáveis.
Perguntas frequentes
Um ficheiro phpinfo é, por si só, uma falha de segurança?
Não abre nenhum acesso, mas dá aos atacantes uma descrição detalhada do servidor: versão, módulos, caminhos, definições e, consoante o ambiente, também variáveis de ambiente. Isso facilita ataques dirigidos e pode expor credenciais.
O número da versão no phpinfo prova que o PHP2Shell tem o patch aplicado?
Não. As distribuições e os fornecedores de alojamento aplicam muitas vezes as correções como backport, e o número apresentado mantém-se igual. O estado do patch é comprovado pelo changelog do pacote e pela confirmação do fornecedor, além do reinício de todos os processos PHP.
O que fazer se um ficheiro phpinfo esteve público durante muito tempo?
Apagar o ficheiro, ver no registo de acesso quem o consultou e substituir todos os segredos que constavam da saída, por exemplo palavras-passe de bases de dados ou chaves de API de variáveis de ambiente.
Posso desativar por completo o phpinfo()?
Sim, através de disable_functions no php.ini do contexto web. Verifique antes se um painel ou uma aplicação usa a função para páginas de estado e reinicie depois os processos PHP.