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 com requisições sem login, antes de qualquer código da aplicação rodar. Elas afetam toda instalação de PHP que atende requisições web, e o GLPI roda em PHP. A correção está nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, lançadas em 21 de outubro de 2026. Este guia explica o que são as falhas, por que o GLPI está na linha de tiro, como descobrir onde você tem PHP, como corrigir em cada cenário, como saber se alguém já entrou e o que fazer depois.

Este guia usa as informações públicas disponíveis em 22 de outubro de 2026. Avisos de segurança mudam rápido: confira também o aviso do seu fornecedor ou da sua distribuição antes de agir.

Atualização: em 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

Em 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 ao recurso de progresso de upload das sessões (session upload progress). Ela é diferente das duas do PHP2Shell, e as versões de 21 e 22 de outubro não a corrigem. A correção vem na próxima versão regular do PHP, ainda sem data, e o aviso completo sai junto com ela.

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

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

O GLPI não faz essa troca. Conferimos o código do GLPI 10, 11 e 12: ele não altera o serialize_handler e não usa o progresso de upload da sessão. Um servidor que roda só o GLPI, com a configuração padrão do PHP, não fica exposto por esse caminho. O risco aparece quando o mesmo PHP atende outras aplicações, como um site, uma loja ou um sistema legado, que você não consegue auditar.

Mesmo assim, a recomendação é desligar o recurso agora. O próprio PHP já tinha sugerido isso em 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 atende 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 em arquivo .user.ini não protege. Onde fica o arquivo em cada cenário:

Para conferir no servidor, use o PHP-FPM, e não o PHP de linha de comando, que lê outro arquivo:

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 tem a linha com on, ela vale mais que o php.ini.

Dica: essa configuração não substitui a atualização das falhas de 21 de outubro. Ela só 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 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 no meio de uma requisição, com dados internos só parcialmente inicializados. Na limpeza da requisição, o PHP passa a tratar esses dados inválidos como válidos.
• CVE-2026-109619: um estado interno de uma requisição pode sobreviver depois que a memória dele foi liberada. A requisição seguinte, atendida pelo mesmo processo, pode usar esse estado antes de ele ser reinicializado.

Os dois casos são problemas de gerenciamento de memória dentro do interpretador, e é isso que os torna graves. Segundo as análises publicadas, uma única requisição sem autenticação pode disparar o ataque antes de qualquer código da aplicação rodar. Ou seja: a tela de login do GLPI, as permissões de perfil e as regras da aplicação não chegam a ser consultadas.

Quais instalações estão expostas

Todas as formas de rodar 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 comando (CLI), que roda as tarefas automáticas do GLPI pelo cron, não atende requisições web. Ele costuma estar na mesma versão e ser atualizado junto.

Não é só o GLPI

A falha está no PHP, não em uma aplicação. Por isso, qualquer sistema em PHP que atende 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 lojistas que usam WooCommerce, PrestaShop e Adobe Commerce (Magento) para conferir o PHP das lojas.

Na prática, quem cuida do GLPI quase sempre cuida também de outros servidores com PHP: o site da empresa, a intranet, o monitoramento, 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 encontrar todos eles.

Já estão explorando?

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

• Amazon: segundo a Help Net Security, a equipe de inteligência de ameaças da Amazon registrou uma tentativa de exploração na sua rede de honeypots (MadPot) em 17 de outubro, quatro dias antes da divulgação pública.
• watchTowr: no seu perguntas frequentes sobre o PHP2Shell, informou em 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, disse que não tinha observado exploração até aquele momento, mas pediu atualização imediata. Para quem não conseguir atualizar, recomendou tirar do ar os sistemas em PHP até corrigir. O NCSC, do Reino Unido, fez a mesma recomendação.

Quando já há tentativas registradas, inclusive antes da divulgação, e alerta de governo pedindo para desligar o que não pode ser corrigido, o tempo entre "possível" e "acontecendo" costuma ser de dias. Trate como emergência.

Por que o GLPI está na linha de tiro

O GLPI é uma aplicação PHP clássica: servidor web, PHP e banco de dados. Toda requisição ao GLPI passa pelo PHP, inclusive as que chegam antes do login. E o GLPI costuma ter mais portas abertas para a internet do que parece:

Como o ataque acontece antes do código do GLPI rodar, qualquer uma dessas URLs serve de porta. Não importa se a API exige token ou se o portal exige login: a requisição maliciosa não chega a ser verificada.

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

Três armadilhas comuns

• Atualizar o GLPI não atualiza o PHP. Quem acabou de ir 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): ali, um número antigo indica 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 seção sobre o PHP 8.1 mais abaixo.

Passo 1: descubra onde você 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 sistema de chamados antigo que ninguém desligou.

Use o próprio GLPI para isso

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

1. Vá em 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. Na aba de instalações, veja em quais computadores cada versão está instalada.

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 você precisa comparar com o aviso de segurança da distribuição. O inventário não enxerga o PHP dentro de containers Docker nem o PHP descompactado no Windows ou no XAMPP.

Confira o PHP que atende o GLPI

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

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

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

Troque 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; confira 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 ligadas, 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 hospedagem

Esses pacotes trazem o número da versão oficial (por exemplo, 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 no Ubuntu), então a conferência é direta. As atualizações automáticas da distribuição normalmente não cobrem esses 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 confira 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): confira 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, rode sudo dnf upgrade --refresh 'php*', que ignora o cache, e tente de novo alguns minutos depois. No Remi em modo SCL, o serviço se chama, por exemplo, php83-php-fpm.

Docker

O container não se atualiza sozinho, e reiniciar o container antigo não troca o PHP. É preciso baixar a imagem nova e recriar. Antes, faça backup do banco e confirme que a pasta de arquivos, a pasta config e o banco estão em volume (docker inspect <container> --format '{{json .Mounts}}'); senão, recriar o container 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, nomeie o serviço do GLPI (nos comandos abaixo, glpi): sem o nome, o pull baixa também a imagem do banco, e com mariadb:latest isso pode trazer junto uma versão maior do banco.

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

Se você usa a imagem oficial glpi/glpi, ela já saiu com o PHP corrigido: em 22/10, todas as tags (latest, 12.0.0, 11.0.11, 10.0.28 e as nightly) traziam o PHP 8.5.12, então basta o pull. Ela usa Apache com mod_php, o cenário de maior risco, mais um motivo 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 dessas 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: docker tag "$(docker inspect --format '{{.Image}}' <container-do-glpi>)" glpi-antes-do-patch.

Windows (IIS, XAMPP, WampServer)

Baixe 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 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 confira

Atualizar o pacote não basta. Os processos que já estavam no ar continuam com o código antigo carregado na memória até reiniciar:

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

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

1. Abra Configurar > Geral > Sistema no GLPI e confira a versão do PHP.
2. Rode php -v no servidor e confira 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á processo velho no ar ou um segundo PHP instalado.
4. Com o PHP da própria distribuição, o número pode não mudar. Confira 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 roda com código antigo; no Red Hat, sudo dnf needs-restarting -s.

Teste o GLPI antes de dar por encerrado

Uma atualização de PHP raramente quebra o GLPI, mas vale a regra de qualquer mudança em produção: se der, aplique primeiro numa cópia de homologação e, de qualquer forma, faça um backup antes. Depois de atualizar, confira em poucos minutos os fluxos que não podem parar:

1. Login, inclusive pelo LDAP ou pelo login único (SSO), se você usa.
2. Abertura de chamado pelo portal de autoatendimento e por formulário.
3. Coletor de e-mail: envie um e-mail de teste e veja se vira chamado.
4. Notificações: confira se o GLPI continua enviando e-mails.
5. Ações automáticas: em Configurar > Ações automáticas, veja se as tarefas continuam rodando.
6. API e integrações: inventário dos agentes, chatbots, ERP e automações que chamam o GLPI.
7. Plugins: abra as telas dos plugins que a equipe mais usa.

E se não der para atualizar agora?

• Tire o GLPI da internet até corrigir. Deixe o acesso só pela rede interna ou por VPN. Se o portal de autoatendimento precisa ficar aberto, essa é a prioridade número um da atualização, não o motivo para adiar.
• Restrinja o que precisa ficar aberto, antes do PHP. Faça a restrição no firewall ou no servidor web (allow/deny no Nginx, Require ip no Apache), nunca nas opções do próprio GLPI, que só rodam depois do PHP. E lembre: restringir só o inventário e a API ajuda pouco se a tela de login continua aberta.
• Desligue o progresso de upload da sessão (session.upload_progress.enabled = Off), como o PHP recomendou. Isso fecha a CVE-2026-115560 e reduz a exposição à CVE-2026-109619, mas não substitui a atualização.
• Use um firewall de aplicação (WAF) como ponte. A Cloudflare publicou regras iniciais para os vetores conhecidos. Ajuda, mas não corrige: a própria AWS avisou que nenhuma mudança de configuração é mitigação completa. As regras valem inclusive no plano gratuito da Cloudflare.
• Aumente a vigilância. Fique de olho em processos do PHP abrindo shell ou baixando arquivos, que é o sinal que a CISA pede para monitorar.

Passo 4: verifique se alguém já entrou

Antes de tudo, um alívio: ter rodado uma versão vulnerável não prova que houve invasão nem vazamento de dados. É só o motivo para olhar. A tentativa mais antiga registrada é de 17 de outubro. Se o seu GLPI ficou exposto com PHP vulnerável nesse período, vale uma checagem rápida depois de corrigir. Nenhum desses comandos altera nada.

Arquivos PHP onde não deveria haver. A pasta de dados do GLPI guarda anexos, imagens e temporários; ali não deveria nascer arquivo .php, com exceção do cache (_cache) e das classes geradas por plugins como Campos adicionais (Fields) e GenericObject, em files/_plugins/fields e files/_plugins/genericobject. Esses aparecem no resultado e são esperados se as datas batem com alterações que você 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 busca usa a data de alteração do arquivo no sistema (ctime), que um invasor não consegue maquiar com touch. Ajuste os caminhos para a sua instalação. Arquivos de plugins e do GLPI atualizados por você no período são esperados; o que preocupa é o que ninguém lembra de ter colocado lá.

Processos e conexões do usuário 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 usuário é apache (crontab -u apache -l). O usuário do servidor web não deveria estar rodando sh, bash, curl, wget ou nc, nem ter tarefa agendada que você não criou (a tarefa do cron.php do GLPI é legítima). Desconfie de conexões de saída para IPs que não sejam o banco, o LDAP, o SMTP ou as suas integrações.

Contas e plugins novos no GLPI. Em Administração > Usuários, adicione a coluna Data de criação (ícone de colunas), ordene por ela e confira se apareceu alguma conta desconhecida desde 17 de outubro, principalmente com perfil Super-Admin. Confira também Administração > Perfis (mudanças de permissão), Configurar > Plugins (algum plugin que você não instalou?) e os clientes da API.

Logs do servidor web e do PHP. Picos de requisições estranhas, de IPs desconhecidos, seguidos de erros 500, merecem atenção, principalmente nas URLs da tabela acima. No log do PHP-FPM, sequências de "Allowed memory size exhausted" e processos encerrados por sinal (por exemplo, "exited on signal 11") também valem uma olhada.

Se encontrar sinal de invasão

1. Isole o servidor da rede, sem desligar, para preservar a evidência.
2. Guarde os logs e uma cópia do disco antes de qualquer limpeza.
3. Reconstrua a partir de uma base limpa e restaure os dados de um backup anterior à invasão, avaliando o que precisa ser refeito depois dessa data. Limpar só o arquivo 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 invasor ainda estiver no ambiente, as senhas novas vazam junto com as antigas. A ordem é: conter, limpar e só então trocar:
5. a senha do banco, que fica em config/config_db.php (ou em /etc/glpi/ em instalações por pacote);
6. a chave glpicrypt.key, que protege as senhas guardadas no GLPI: gere uma nova com php bin/console glpi:security:change_key, que recriptografa os dados (trocar o arquivo à mão deixa os segredos ilegíveis), e depois troque as próprias senhas: coletores de e-mail, conta de leitura do LDAP, SMTP e proxy;
7. as senhas dos administradores locais do GLPI, porque os hashes estavam no banco;
8. os tokens da API (de aplicação e de usuários) e os segredos de OAuth;
9. as credenciais das integrações que o GLPI chama (ERP, chatbot, automações).
10. Avalie a comunicação: se dados pessoais podem ter sido acessados, envolva o encarregado (DPO) e o jurídico. A LGPD (art. 48) prevê comunicar a ANPD e os titulares quando o incidente pode causar risco ou dano relevante, e o regulamento da ANPD define um prazo curto para isso.

PHP 8.1 ou mais antigo: o problema é maior

O PHP 8.1 e as versões anteriores não têm mais suporte do projeto PHP e por isso não recebem a versão corrigida oficial. O próprio time 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 demais dependem do fornecedor ou da distribuição publicar o pacote. PHP 5 e 7.0 a 7.3 não têm correção nenhuma (é o caso de quem ainda roda 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á traz a correção. O sury e o PPA ondrej/php também mantêm pacotes de 7.4 a 8.1; confira se já trazem a correção. Se o GLPI está numa hospedagem gerenciada, peça à hospedagem 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 roda 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 novo, e o GLPI 12 exige o 8.3. Se esse é o seu caso, corrigir esta falha e sair do GLPI 10 viraram o mesmo projeto: veja os riscos de continuar no GLPI 10 e o roteiro para migrar.

Depois da correção: deixe o próximo susto menor

• Tire do ar o que não precisa estar na internet. Inventário só dos IPs dos agentes, API só dos servidores que a usam, área administrativa só pela VPN, sempre com a regra no 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. Isso reduz a varredura automática, mas não protege: o ataque não depende de saber a versão.
• Ligue as atualizações automáticas de segurança da distribuição, e lembre que elas não cobrem repositórios de terceiros nem imagens Docker.
• Tenha um backup testado do banco e da pasta de arquivos do GLPI. Restaurar é o plano B de toda 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.

Linha do tempo

Checklist de hoje

1. Listar todos os servidores com PHP, não só o do GLPI (o inventário do GLPI ajuda).
2. Conferir 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 conferir de novo.
5. Se não der para atualizar hoje, tirar do acesso externo.
6. Rodar as verificações de invasão e guardar o resultado.
7. Restringir inventário, API e área administrativa ao que precisa.
8. Desligar session.upload_progress.enabled no php.ini ou no pool do PHP-FPM, reiniciar e conferir.

Precisa de ajuda para atualizar o servidor do GLPI ou revisar a exposição do seu ambiente? Fale com a gente.

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, reportagem 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 desenvolvedores (21/10/2026). GLPI é marca registrada da Teclib'. A NexTool não é afiliada à Teclib'.