NexTool Solutions

Duas falhas críticas no próprio PHP, apelidadas de PHP2Shell (CVE-2026-109618 e CVE-2026-109619), permitem executar código no servidor através de pedidos sem autenticação, antes de qualquer código da aplicação correr. Afetam todas as instalações de PHP que respondem a pedidos web, e o GLPI corre em PHP. A correção está nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, lançadas a 21 de outubro de 2026. Este guia explica o que são as falhas, porque é que o GLPI está na linha de fogo, como descobrir onde tem PHP, como corrigir em cada cenário, como saber se alguém já entrou e o que fazer a seguir.

Este guia usa a informação pública disponível a 22 de outubro de 2026. Os avisos de segurança mudam depressa: consulte também o aviso do seu fornecedor ou da sua distribuição antes de agir.

Atualização: a 23 de outubro de 2026, o PHP divulgou uma terceira falha, a CVE-2026-115560, ainda sem correção. Veja o que muda e a configuração que protege.

Resumo para quem tem cinco minutos

Atualização de 23/10: uma terceira falha, CVE-2026-115560

A 23 de outubro, o projeto PHP publicou um aviso sobre uma terceira falha de execução remota de código, a CVE-2026-115560, ligada à funcionalidade de progresso de carregamento das sessões (session upload progress). É diferente das duas do PHP2Shell, e as versões de 21 e 22 de outubro não a corrigem. A correção chega na próxima versão regular do PHP, ainda sem data, e o aviso completo sai com ela.

O caminho de ataque é bem mais estreito do que o do PHP2Shell. Só existe quando se juntam três condições:

1. o php.ini define session.serialize_handler como php_binary ou php_serialize;
2. a aplicação muda esse valor para php durante a execução, com ini_set(), antes de abrir a sessão;
3. o progresso de carregamento da sessão está ativo, que é a predefinição do PHP.

O GLPI não faz essa mudança. Verificámos o código do GLPI 10, 11 e 12: não altera o serialize_handler e não usa o progresso de carregamento da sessão. Um servidor que corre apenas o GLPI, com a configuração predefinida do PHP, não fica exposto por este caminho. O risco surge quando o mesmo PHP serve outras aplicações, como um site, uma loja ou um sistema legado, que não consegue auditar.

Mesmo assim, a recomendação é desativar a funcionalidade já. O próprio PHP já o tinha sugerido a 21 de outubro como medida de contenção para a CVE-2026-109619, e o GLPI não perde nada:

session.upload_progress.enabled = Off

Coloque a linha no php.ini do PHP que serve a web ou no pool do PHP-FPM (php_admin_flag[session.upload_progress.enabled] = off) e reinicie o PHP-FPM ou o Apache. Configurar pelo código, com ini_set(), ou num ficheiro .user.ini não protege. Onde fica o ficheiro em cada cenário:

Para confirmar no servidor, use o PHP-FPM, e não o PHP de linha de comandos, que lê outro ficheiro:

sudo php-fpm8.3 -i | grep session.upload_progress.enabled
grep -rn upload_progress /etc/php/8.3/fpm/

O resultado esperado é Off. Se algum pool tiver a linha com on, esta prevalece sobre o php.ini.

Dica: esta configuração não substitui a atualização das falhas de 21 de outubro. Apenas fecha a falha nova até sair a correção. Quando o PHP publicar a próxima versão, atualize de novo.

O que aconteceu

O projeto PHP publicou correções de segurança para duas falhas de execução remota de código no núcleo da linguagem. No changelog oficial, as correções aparecem como "Avoid state corruption via bailout" (GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp). Fontes de segurança citam a nota 9,2 na escala CVSS 4.0, o que as coloca na faixa crítica. Há fontes que citam 9,8 na escala CVSS 3.1 do NVD.

Em termos simples:

• CVE-2026-109618: uma condição de falta de memória pode interromper o PHP a meio de um pedido, com dados internos apenas parcialmente inicializados. Na limpeza do pedido, o PHP passa a tratar esses dados inválidos como válidos.
• CVE-2026-109619: um estado interno de um pedido pode sobreviver depois de a sua memória ter sido libertada. O pedido seguinte, servido pelo mesmo processo, pode usar esse estado antes de ser reinicializado.

Os dois casos são problemas de gestão de memória dentro do interpretador, e é isso que os torna graves. Segundo as análises publicadas, um único pedido sem autenticação pode desencadear o ataque antes de qualquer código da aplicação correr. Ou seja: o ecrã de início de sessão do GLPI, as permissões de perfil e as regras da aplicação nem chegam a ser consultados.

Que instalações estão expostas

Todas as formas de correr PHP para a web aparecem nos avisos: PHP-FPM (o mais comum com Nginx e com Apache moderno), Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. As análises apontam o mod_php como o cenário de maior risco.

O PHP de linha de comandos (CLI), que corre as ações automáticas do GLPI pelo cron, não responde a pedidos web. Costuma estar na mesma versão e ser atualizado em conjunto.

Não é só o GLPI

A falha está no PHP, não numa aplicação. Por isso, qualquer sistema em PHP que sirva a web está exposto, e a correção é a mesma para todos: atualizar o PHP e reiniciar o serviço. Atualizar o WordPress, o GLPI ou um plugin não resolve.

O alerta não ficou restrito a quem é de TI: o Mercado Pago, por exemplo, avisou os comerciantes que usam WooCommerce, PrestaShop e Adobe Commerce (Magento) para verificarem o PHP das lojas.

Na prática, quem trata do GLPI quase sempre trata também de outros servidores com PHP: o site da empresa, a intranet, a monitorização, o sistema legado que ninguém desligou. Corrigir só o GLPI deixa a porta aberta no servidor ao lado. No Passo 1, mostramos como usar o próprio inventário do GLPI para os encontrar a todos.

Já estão a ser exploradas?

As fontes divergem, e isso não muda a recomendação:

• Amazon: segundo a Help Net Security, a equipa de inteligência de ameaças da Amazon registou uma tentativa de exploração na sua rede de honeypots (MadPot) a 17 de outubro, quatro dias antes da divulgação pública.
• watchTowr: nas suas perguntas frequentes sobre o PHP2Shell, informou a 21 de outubro que observou exploração das falhas na sua rede de honeypots.
• CISA (agência de cibersegurança dos EUA): no alerta de 21 de outubro, afirmou não ter observado exploração até esse momento, mas pediu atualização imediata. Para quem não conseguir atualizar, recomendou desligar os sistemas em PHP até corrigir. O NCSC, do Reino Unido, fez a mesma recomendação.

Quando já há tentativas registadas, inclusive antes da divulgação, e um alerta governamental a pedir para desligar o que não pode ser corrigido, o tempo entre "possível" e "a acontecer" costuma ser de dias. Trate isto como uma emergência.

Porque é que o GLPI está na linha de fogo

O GLPI é uma aplicação PHP clássica: servidor web, PHP e base de dados. Todos os pedidos ao GLPI passam pelo PHP, incluindo os que chegam antes do início de sessão. E o GLPI costuma ter mais portas abertas para a internet do que parece:

Como o ataque acontece antes de o código do GLPI correr, qualquer um destes URL serve de porta. Não importa se a API exige token ou se o portal exige início de sessão: o pedido malicioso nem chega a ser verificado.

E o que está atrás dessa porta é sensível. O servidor do GLPI guarda o acesso à base de dados com todos os pedidos, anexos, dados de utilizadores e inventário da empresa. Na pasta config ficam a palavra-passe da base de dados e a chave que protege as palavras-passe guardadas no GLPI (coletor de e-mail, LDAP, SMTP). Quem executa código no servidor tem tudo isso ao seu alcance.

Três armadilhas comuns

• Atualizar o GLPI não atualiza o PHP. Quem acabou de passar para o GLPI 12 não está automaticamente protegido: o GLPI 12 exige o PHP 8.3, mas funciona com uma 8.3 anterior à correção.
• O número da versão pode enganar. O Ubuntu costuma aplicar a correção no pacote e manter o número (o 24.04 mostra 8.3.6 mesmo atualizado). O Debian às vezes faz o mesmo e às vezes sobe para a versão nova. Um número "antigo" não prova que o servidor está vulnerável, e um pacote novo não prova que o serviço foi reiniciado. Desta vez o Debian subiu o número (8.4.27 no Debian 13 e 8.2.35 no Debian 12): aí, um número antigo indica um pacote sem correção.
• PHP 8.1 no GLPI 10 é a combinação mais arriscada: PHP sem versão corrigida oficial e GLPI sem suporte. Veja a secção sobre o PHP 8.1 mais abaixo.

Passo 1: descubra onde tem PHP

A CISA começa a recomendação por aqui: inventariar todos os sistemas com PHP. O GLPI é só um deles. Costumam aparecer também o site da empresa, a intranet, o Zabbix, o phpMyAdmin, o Moodle, o antigo sistema de pedidos que ninguém desligou.

Use o próprio GLPI para isso

Se usa o GLPI Agent, o inventário de software já sabe onde há PHP:

1. Vá a Ativos > Software (em algumas traduções, Programas) e pesquise por php.
2. Abra os itens como php8.3-fpm, php8.3-common, libapache2-mod-php8.3 ou php-fpm, conforme a distribuição.
3. No separador de instalações, veja em que computadores está instalada cada versão.

A versão que o agente mostra é a do pacote, com o sufixo da distribuição (por exemplo, 8.3.6-0ubuntu0.24.04.x). É exatamente o que precisa de comparar com o aviso de segurança da distribuição. O inventário não vê o PHP dentro de contentores Docker nem o PHP descompactado no Windows ou no XAMPP.

Verifique o PHP que serve o GLPI

O PHP da linha de comandos pode ser diferente do que serve o site. Para ver o que importa:

• No GLPI: em Configurar > Geral > Sistema, a secção do servidor mostra a versão do PHP em uso pelo GLPI.
• No servidor: veja que serviço está a correr e que versão usa.

php -v
systemctl list-units --type=service | grep -Ei 'php|apache|httpd'
sudo php-fpm8.3 -v

Substitua 8.3 pela versão que aparecer na lista de serviços. No Red Hat e derivados, use sudo php-fpm -v.

Passo 2: atualize, conforme o seu cenário

Ubuntu e Debian com o PHP da própria distribuição

As distribuições recebem as correções antes da divulgação pública e publicam os pacotes nos seus avisos de segurança (no Ubuntu, o USN-8948-1, de 21/10; no Debian, o DSA-6574-1 e o DLA-4848-1). No Ubuntu, o número principal não muda; confirme pelo pacote:

sudo apt-get update
apt-cache policy php8.3-fpm
sudo apt-get install --only-upgrade 'php8.3*'
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -E 'CVE-2026-10961[89]'

O último comando lê o changelog do pacote instalado e deve mostrar CVE-2026-109618 e CVE-2026-109619. Se as atualizações automáticas de segurança estiverem ativas, o pacote pode já ter chegado; mesmo assim, o serviço só usa o código novo depois de reiniciado.

Versões de referência por distribuição:

PHP de repositório de terceiros (ondrej/php, sury.org) ou painel de alojamento

Estes pacotes trazem o número da versão oficial (por exemplo, 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 no Ubuntu), por isso a verificação é direta. As atualizações automáticas da distribuição normalmente não cobrem estes repositórios, e o mesmo vale para painéis que instalam o PHP do sury, como o CloudPanel:

sudo apt update && sudo apt upgrade
php -v

Em painéis como cPanel, Plesk ou aaPanel, use a atualização de PHP do próprio painel e confirme a versão de cada site.

Red Hat, Rocky, AlmaLinux e Oracle Linux

sudo dnf check-update 'php*'
sudo dnf update 'php*'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

No PHP do próprio Red Hat (módulos do AppStream), o número também não muda: vale o changelog. Se o PHP vem do repositório Remi, a atualização chega com o número da versão oficial (8.2 a 8.5, no RHEL 8, 9 e 10): confirme pelo php -v. No dia da divulgação o Remi ainda não tinha os pacotes e os espelhos ficaram sobrecarregados: se o dnf não oferecer a atualização, execute sudo dnf upgrade --refresh 'php*', que ignora a cache, e tente de novo alguns minutos depois. No Remi em modo SCL, o serviço chama-se, por exemplo, php83-php-fpm.

Docker

O contentor não se atualiza sozinho, e reiniciar o contentor antigo não troca o PHP. É preciso descarregar a imagem nova e recriar. Antes, faça uma cópia de segurança da base de dados e confirme que a pasta de ficheiros, a pasta config e a base de dados estão em volumes (docker inspect <container> --format '{{json .Mounts}}'); caso contrário, recriar o contentor apaga os dados. Se a imagem usa a tag latest, o pull pode trazer outra versão do GLPI: fixe a tag. No docker compose, indique o serviço do GLPI (nos comandos abaixo, glpi): sem o nome, o pull descarrega também a imagem da base de dados e, com mariadb:latest, isso pode trazer uma versão maior da base de dados.

docker compose pull glpi
docker compose build --pull glpi
docker compose up -d glpi
docker exec <container-do-glpi> php -v

Se usa a imagem oficial glpi/glpi, ela já saiu com o PHP corrigido: a 22/10, todas as tags (latest, 12.0.0, 11.0.11, 10.0.28 e as nightly) traziam o PHP 8.5.12, por isso basta o pull. Usa Apache com mod_php, o cenário de maior risco, mais uma razão para não adiar. Se a sua imagem é construída a partir de uma imagem oficial do PHP (por exemplo, php:8.3-fpm ou php:8.3-apache), as tags corrigidas saíram ao longo de 21/10 e as do FrankenPHP na madrugada de 22/10 (UTC); um pull feito antes disso trouxe a versão vulnerável. Dois cuidados: o apt upgrade dentro do Dockerfile não atualiza o PHP destas imagens, que é compilado à parte; e a tag flutuante pode trazer mais do que o PHP (o servidor web da imagem também pode mudar de versão). Antes de recriar, guarde a imagem atual para poder voltar atrás: docker tag "$(docker inspect --format '{{.Image}}' <container-do-glpi>)" glpi-antes-do-patch.

Windows (IIS, XAMPP, WampServer)

Descarregue a versão corrigida da sua linha no site oficial de PHP para Windows e substitua a pasta do PHP, mantendo o seu php.ini. Pacotes prontos como o XAMPP costumam demorar a publicar a versão nova; não espere por eles. Depois, reinicie o IIS ou o Apache.

Passo 3: reinicie e confirme

Atualizar o pacote não basta. Os processos que já estavam a correr continuam com o código antigo carregado em memória até serem reiniciados:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

Em Red Hat e derivados, os serviços costumam chamar-se php-fpm e httpd. Depois de reiniciar:

1. Abra Configurar > Geral > Sistema no GLPI e confirme a versão do PHP.
2. Corra php -v no servidor e confirme também o PHP-FPM (sudo php-fpm8.3 -v).
3. Com PHP do sury, do Remi, de imagem Docker oficial ou do Windows, o GLPI deve mostrar a versão corrigida. Se mostra a antiga, ainda há um processo antigo a correr ou um segundo PHP instalado.
4. Com o PHP da própria distribuição, o número pode não mudar. Confirme o pacote (dpkg -l 'php8.3*' ou rpm -q php-fpm) e se o serviço foi reiniciado depois da instalação: systemctl status php8.3-fpm mostra a hora em "active since". No Ubuntu, sudo needrestart -r l lista o que ainda corre com código antigo; no Red Hat, sudo dnf needs-restarting -s.

Teste o GLPI antes de dar o trabalho por terminado

Uma atualização de PHP raramente estraga o GLPI, mas vale a regra de qualquer alteração em produção: se puder, aplique-a primeiro numa cópia de testes e, em qualquer caso, faça antes uma cópia de segurança. Depois de atualizar, confirme em poucos minutos os fluxos que não podem parar:

1. Início de sessão, incluindo pelo LDAP ou pelo início de sessão único (SSO), se o utiliza.
2. Abertura de pedidos pelo portal de self-service e por formulário.
3. Coletor de e-mail: envie um e-mail de teste e veja se se transforma em pedido.
4. Notificações: confirme se o GLPI continua a enviar e-mails.
5. Ações automáticas: em Configurar > Ações automáticas, veja se as tarefas continuam a correr.
6. API e integrações: inventário dos agentes, chatbots, ERP e automatizações que chamam o GLPI.
7. Plugins: abra os ecrãs dos plugins que a equipa mais utiliza.

E se não for possível atualizar agora?

• Retire o GLPI da internet até corrigir. Deixe o acesso apenas pela rede interna ou por VPN. Se o portal de self-service tem de ficar aberto, essa é a prioridade número um da atualização, não o motivo para a adiar.
• Restrinja o que tem de ficar aberto, antes do PHP. Faça a restrição na firewall ou no servidor web (allow/deny no Nginx, Require ip no Apache), nunca nas opções do próprio GLPI, que só correm depois do PHP. E lembre-se: restringir apenas o inventário e a API ajuda pouco se o ecrã de início de sessão continua aberto.
• Desative o progresso de carregamento da sessão (session.upload_progress.enabled = Off), como o PHP recomendou. Isto fecha a CVE-2026-115560 e reduz a exposição à CVE-2026-109619, mas não substitui a atualização.
• Use uma firewall de aplicações web (WAF) como ponte. A Cloudflare publicou regras iniciais para os vetores conhecidos. Ajuda, mas não corrige: a própria AWS avisou que nenhuma alteração de configuração é uma mitigação completa. As regras estão disponíveis também no plano gratuito da Cloudflare.
• Reforce a vigilância. Esteja atento a processos do PHP a abrir uma shell ou a descarregar ficheiros, que é o sinal que a CISA pede para monitorizar.

Passo 4: verifique se alguém já entrou

Antes de mais, um alívio: ter corrido uma versão vulnerável não prova que houve intrusão nem fuga de dados. É apenas o motivo para verificar. A tentativa mais antiga registada é de 17 de outubro. Se o seu GLPI ficou exposto com PHP vulnerável nesse período, vale a pena uma verificação rápida depois de corrigir. Nenhum destes comandos altera nada.

Ficheiros PHP onde não deveria haver. A pasta de dados do GLPI guarda anexos, imagens e temporários; ali não deveria surgir nenhum ficheiro .php, com exceção da cache (_cache) e das classes geradas por plugins como Campos adicionais (Fields) e GenericObject, em files/_plugins/fields e files/_plugins/genericobject. Estes aparecem no resultado e são esperados se as datas coincidirem com alterações que fez:

sudo find /var/lib/glpi/files /var/www/glpi/files -name '*.php' -not -path '*/_cache/*' 2>/dev/null
sudo find /var/www/glpi -type f -name '*.php' -newerct '2026-10-15' -not -path '*/files/_cache/*' 2>/dev/null

A segunda pesquisa usa a data de alteração do ficheiro no sistema (ctime), que um intruso não consegue disfarçar com touch. Ajuste os caminhos à sua instalação. Ficheiros de plugins e do GLPI que atualizou no período são esperados; o que preocupa é o que ninguém se lembra de lá ter colocado.

Processos e ligações do utilizador do servidor web:

ps -eo user,pid,ppid,lstart,cmd | grep -E '^(www-data|apache|nginx)' | grep -Ev 'php-fpm|apache2|httpd|nginx'
sudo ss -tnp | grep -E 'php|apache|httpd|"(sh|bash|dash|nc|ncat|perl|python[0-9.]*)"'
sudo crontab -u www-data -l

No Red Hat, o utilizador é apache (crontab -u apache -l). O utilizador do servidor web não deveria estar a correr sh, bash, curl, wget ou nc, nem ter tarefas agendadas que não criou (a tarefa do cron.php do GLPI é legítima). Desconfie de ligações de saída para IP que não sejam a base de dados, o LDAP, o SMTP ou as suas integrações.

Contas e plugins novos no GLPI. Em Administração > Utilizadores, adicione a coluna Data de criação (ícone de colunas), ordene por ela e verifique se apareceu alguma conta desconhecida desde 17 de outubro, sobretudo com perfil Super-Admin. Verifique também Administração > Perfis (alterações de permissões), Configurar > Plugins (algum plugin que não instalou?) e os clientes da API.

Registos do servidor web e do PHP. Picos de pedidos estranhos, de IP desconhecidos, seguidos de erros 500, merecem atenção, sobretudo nos URL da tabela acima. No registo do PHP-FPM, sequências de "Allowed memory size exhausted" e processos terminados por sinal (por exemplo, "exited on signal 11") também merecem uma vista de olhos.

Se encontrar sinais de intrusão

1. Isole o servidor da rede, sem o desligar, para preservar as provas.
2. Guarde os registos e uma cópia do disco antes de qualquer limpeza.
3. Reconstrua a partir de uma base limpa e restaure os dados de uma cópia de segurança anterior à intrusão, avaliando o que precisa de ser refeito depois dessa data. Limpar apenas o ficheiro encontrado não garante que não ficou outra porta.
4. Troque todos os segredos que o servidor guardava, só depois de isolar e reconstruir. Se o atacante ainda estiver no ambiente, as palavras-passe novas ficam expostas juntamente com as antigas. A ordem é: conter, limpar e só então trocar:
5. a palavra-passe da base de dados, que fica em config/config_db.php (ou em /etc/glpi/ em instalações por pacote);
6. a chave glpicrypt.key, que protege as palavras-passe guardadas no GLPI: gere uma nova com php bin/console glpi:security:change_key, que volta a cifrar os dados (trocar o ficheiro à mão deixa os segredos ilegíveis), e depois troque as próprias palavras-passe: coletores de e-mail, conta de leitura do LDAP, SMTP e proxy;
7. as palavras-passe dos administradores locais do GLPI, porque os hashes estavam na base de dados;
8. os tokens da API (de aplicação e de utilizadores) e os segredos de OAuth;
9. as credenciais das integrações que o GLPI chama (ERP, chatbot, automatismos).
10. Avalie a comunicação: se dados pessoais podem ter sido acedidos, envolva o encarregado de proteção de dados (DPO) e o departamento jurídico. A LGPD (art. 48) prevê comunicar à ANPD e aos titulares quando o incidente pode causar risco ou dano relevante, e o regulamento da ANPD define um prazo curto para isso. Em Portugal e no resto da União Europeia, aplica-se o RGPD: a notificação à CNPD deve, regra geral, ser feita em até 72 horas após o conhecimento da violação.

PHP 8.1 ou mais antigo: o problema é maior

O PHP 8.1 e as versões anteriores já não têm suporte do projeto PHP e por isso não recebem a versão corrigida oficial. A própria equipa do PHP publicou correções mínimas em código-fonte para 7.4, 8.0 e 8.1: quem compila o PHP pode aplicá-las; os restantes dependem de o seu fornecedor ou distribuição publicar o pacote. O PHP 5 e o 7.0 a 7.3 não têm qualquer correção (é o caso de quem ainda corre o GLPI 9.5). No Ubuntu 22.04, por exemplo, o PHP 8.1 é mantido pela própria Canonical: o USN-8948-1, de 21/10, já inclui a correção. O sury e o PPA ondrej/php também mantêm pacotes de 7.4 a 8.1; verifique se já trazem a correção. Se o GLPI está num alojamento gerido, peça ao fornecedor de alojamento um pacote com a correção das duas falhas ou um plano prioritário de migração para uma versão com suporte, com data.

Quem ainda corre PHP 8.1 normalmente também está no GLPI 10, que perdeu o suporte com a chegada do GLPI 12. O GLPI 11 exige PHP 8.2 ou mais recente, e o GLPI 12 exige o 8.3. Se é o seu caso, corrigir esta falha e sair do GLPI 10 passaram a ser o mesmo projeto: veja os riscos de continuar no GLPI 10 e o roteiro para migrar.

Depois da correção: torne o próximo susto mais pequeno

• Retire da internet o que não precisa de lá estar. Inventário só a partir dos IP dos agentes, API só a partir dos servidores que a usam, área de administração só pela VPN, sempre com a regra na firewall ou no servidor web.
• Esconda a versão do PHP. Com expose_php = Off no php.ini, o servidor deixa de anunciar a versão no cabeçalho de resposta. Isto reduz o varrimento automático, mas não protege: o ataque não precisa de saber a versão.
• Ative as atualizações automáticas de segurança da distribuição, e lembre-se de que não cobrem repositórios de terceiros nem imagens Docker.
• Tenha uma cópia de segurança testada da base de dados e da pasta de ficheiros do GLPI. Restaurar é o plano B de qualquer falha crítica.
• Acompanhe as falhas do seu ambiente. O CVE Scan é gratuito: verifica a versão do GLPI e do PHP, os cabeçalhos de segurança e as permissões, e mostra o que corrigir primeiro.

Cronologia

Lista de verificação de hoje

1. Listar todos os servidores com PHP, não só o do GLPI (o inventário do GLPI ajuda).
2. Confirmar a versão em Configurar > Geral > Sistema e o pacote no servidor.
3. Atualizar, começando pelo que está exposto na internet.
4. Reiniciar o PHP-FPM ou o Apache e confirmar de novo.
5. Se não for possível atualizar hoje, retirar o acesso externo.
6. Correr as verificações de intrusão e guardar o resultado.
7. Restringir inventário, API e área de administração ao necessário.
8. Desativar session.upload_progress.enabled no php.ini ou no pool do PHP-FPM, reiniciar e confirmar.

Precisa de ajuda para atualizar o servidor do GLPI ou rever a exposição do seu ambiente? Fale connosco.

Fontes: avisos de segurança do PHP de 21 e 23/10/2026, alerta da CISA (21/10/2026), changelog oficial do PHP (php.net), boletim de segurança da AWS, artigo da Help Net Security sobre o PHP2Shell, FAQ da watchTowr, aviso do Ubuntu (USN-8948-1), rastreador de segurança do Debian e aviso do Mercado Pago aos programadores (21/10/2026). GLPI é marca registada da Teclib'. A NexTool não é afiliada da Teclib'.