Lista de verificação de segurança do PHP: 8 passos para identificar e corrigir vulnerabilidades

php icon.
Responsável pelo Engineering
Especialista verificado
Todos os artigos da Innowise são escritos por autores com experiência prática. Estes compreendem o tema para além da teoria e partilham perspetivas baseadas em projetos reais.
7+ anos de experiência
Especialista verificado
7+ anos de experiência
Herman lidera departamentos de engenharia e desenvolve os processos, as estruturas das equipas e as normas técnicas de que estes necessitam para crescer. A sua experiência abrange sistemas backend de elevada carga, gestão de entregas e liderança em engenharia.
Especialização
Sistemas de alta carga Arquitectura de software Bases de dados
Contacto

Principais conclusões

  • O PHP2Shell requer a aplicação urgente de uma correção. A 21 de outubro de 2026, o PHP corrigiu as vulnerabilidades CVE-2026-109618 e CVE-2026-109619. Ambas são vulnerabilidades críticas de tempo de execução (CVSS v4.0: 9,2) que podem permitir a execução remota de código sem autenticação.
  • Verifique as versões corrigidas. As primeiras versões corrigidas são PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. As distribuições Linux podem disponibilizar as mesmas correções através de patches retrocompatíveis.
  • Dê prioridade aos ambientes de execução PHP expostos. O mod_php do Apache apresenta o maior risco relatado, mas o PHP-FPM e outras configurações voltadas para a Web também requerem atenção. As atualizações do framework e a auditoria do Composer não corrigem o PHP2Shell.
  • Não se limite a aplicar patches ao PHP. Utilize a lista de verificação de oito passos para analisar dependências, código da aplicação, configurações do servidor e outras vulnerabilidades de segurança.
  • Verifique a correção no ambiente de produção. Peça à sua equipa um relatório que mostre quais as versões do PHP que estão efetivamente em execução, quais as cargas de trabalho que receberam as correções e se há sinais de comprometimento anterior.
Resumo por IA

De acordo com o W3Techs, O PHP está presente em cerca de 70% dos sites em que a linguagem do lado do servidor é conhecida. Como o PHP é tão comum, uma vulnerabilidade no interpretador pode colocar muitos sites em risco, mesmo que o seu próprio código seja seguro.

A 21 de outubro de 2026, o projeto PHP lançou correções de emergência para duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, conhecidas em conjunto como PHP2Shell. Ambas receberam uma pontuação de 9,2 segundo o CVSS v4.0 e permitem a execução remota de código sem autenticação. Estas falhas afetam a memória interna e o tratamento de pedidos do PHP.

Os primeiros patches foram lançados no PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Se o seu sistema utilizar uma das versões afetadas, atualize o PHP imediatamente e certifique-se de que o seu servidor web está a executar a versão corrigida. Mas o trabalho não deve ficar por aí. Para as equipas que desenvolvem e mantêm aplicações PHP, incluindo os especialistas em desenvolvimento da Innowise, especialistas em PHP desenvolvimento, o lançamento de outubro é também um motivo para rever as dependências, o código da aplicação e as configurações do servidor.

Neste guia, vou mostrar-lhe oito passos para identificar e corrigir vulnerabilidades na sua configuração PHP e confirmar que as suas correções funcionam em produção.

Análise de especialistas: em que medida o PHP2Shell difere de uma vulnerabilidade CVE de dependência comum

Um pacote do Composer vulnerável afeta o código utilizado pela sua aplicação. O PHP2Shell é diferente. Ambas as vulnerabilidades encontram-se no próprio PHP interpretador, e um atacante pode ativá-las antes de Laravel, Symfony ou outra estrutura sequer comece a ser executada. A atualização de plugins de CMS ou de dependências do Composer não corrige o PHP, e o composer audit não deteta estas vulnerabilidades em tempo de execução.

A equipa de segurança do PHP identifica o Apache mod_php como a configuração de maior risco para o CVE-2026-109618, com um ataque comprovado que funciona antes da execução do código da aplicação. O PHP-FPM, o CGI e outras configurações de servidor web também são afetadas, embora as condições de exploração sejam diferentes. Os investigadores também demonstraram a exploração da vulnerabilidade CVE-2026-109619 contra o PHP-FPM.

Eis o que corre mal em cada caso:

CVECausa principalPor que razão as equipas devem dar importância a isto
CVE-2026-109618Se o PHP ficar sem memória durante o processamento de um pedido, alguns dados internos podem ficar num estado inválido. Quando o PHP limpa o pedido que falhou, pode utilizar esses dados.Se o PHP ficar sem memória durante o processamento de um pedido, alguns dados internos podem ficar num estado inválido. Quando o PHP limpa o pedido que falhou, pode utilizar esses dados.
CVE-2026-109619Um PHP worker pode manter uma referência à memória que foi libertada após um pedido anterior. Quando o worker processa outro pedido, pode tentar utilizar essa referência antiga.O problema pode propagar-se entre os pedidos tratados pelo mesmo trabalhador. A verificação de cada pedido da aplicação, individualmente, não o revelará necessariamente.

Ambas as falhas podem levar à execução remota de código sem autenticação. A correção deve ser aplicada no PHP em tempo de execução, e não nas dependências da aplicação.

Para uma explicação técnica mais aprofundada, pode consultar os avisos do projeto PHP relativos a CVE-2026-109618 e CVE-2026-109619.

De onde vêm as vulnerabilidades de segurança do PHP?

Como mencionei anteriormente, atualizar o PHP não resolve o problema de um pacote do Composer vulnerável, e uma verificação completa das dependências não detecta problemas no seu próprio código. Ao analisar uma aplicação PHP, tenho em conta quatro fontes de risco de segurança, cada uma com as suas próprias consequências potenciais.

CategoriaExemplosRisco principal
Tempo de execução do PHPVersões do PHP sem correções, vulnerabilidades no interpretador, versões sem suporteOs atacantes exploram falhas no próprio PHP, independentemente do nível de segurança com que a aplicação tenha sido programada
Dependências de terceirosPacotes do Composer, plugins para CMS, frameworksO código de terceiros vulnerável expõe as aplicações a ataques, mesmo quando o seu próprio código é seguro
Código da candidaturaInjeção de SQL, XSS, CSRF, deserialização insegura, controlo de acesso defeituosoFalhas de programação podem permitir que os atacantes roubem dados, realizem ações não autorizadas ou comprometam a aplicação
Configuração e infraestruturaConfigurações inseguras de PHP, ficheiros expostos, permissões excessivasAs configurações incorretas podem expor informações confidenciais ou conceder aos atacantes um acesso superior ao pretendido

Resolva as vulnerabilidades PHP antes que se agravem

Lista de verificação de segurança do PHP: 8 verificações essenciais

A seguir, vamos analisar oito verificações de segurança que eu utilizaria numa aplicação PHP já existente. Começaria pelo PHP em execução a atender pedidos em tempo real e, em seguida, analisaria o código, as dependências e a configuração para identificar problemas que uma atualização do PHP por si só não resolveria.

Verifique a sua versão do PHP e as atualizações de segurança

Em primeiro lugar, identifique quais os runtimes PHP que as suas aplicações utilizam: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP ou LiteSpeed. Inclua pools FPM, contentores, instalações CLI, trabalhadores de fila e tarefas agendadas separadamente.

Não confie apenas no php -v ou no php –ini. O php -v mostra a versão CLI, enquanto o php –ini mostra a sua configuração. Nenhum deles confirma o PHP em execução a servir pedidos web.

Compare o ambiente de execução ativo e a sua configuração com o alerta oficial do PHP, incluindo as versões afetadas e as condições de exposição. O mod_php do Apache apresenta a exposição mais grave comprovada ao PHP2Shell, incluindo um caminho de exploração antes da execução do código da aplicação. A exposição do PHP-FPM depende da configuração e dos caminhos de execução. Outras SAPIs também necessitam de avaliação, uma vez que a SAPI, por si só, não determina se uma implementação é segura.

As primeiras versões upstream que incluíram ambas as correções foram:

Ramo PHPPrimeira versão corrigida
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Estas versões estão listadas nos avisos de segurança do PHP relativos a CVE-2026-109618 e CVE-2026-109619. Verifique se existem versões de segurança mais recentes antes de atualizar.

Verificar correções do PHP no Linux e em contentores

Verifique o ambiente de execução ativo. Analise a configuração do seu servidor web para identificar o módulo PHP, o pool FPM ou o SAPI incorporado que está a tratar os pedidos. Confirme a sua versão utilizando diagnósticos de acesso restrito e, em seguida, remova quaisquer pontos finais temporários. Nunca exponha publicamente phpinfo() ou um ponto final de versão.

Verifique os pacotes instalados. No Ubuntu com PHP 8.3, estes comandos de leitura apenas mostram os pacotes instalados e as versões disponíveis:

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Adapte os nomes dos pacotes à sua ramificação do PHP e compare as versões instaladas com o aviso de segurança do fornecedor ou com o registo de alterações do pacote. Os fornecedores de Linux podem fazer o backport de correções para versões mais antigas do PHP. Por exemplo, o Ubuntu lista estas compilações corrigidas:

  • Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04: 8.1.2-1ubuntu2.28

Ambas contêm as correções relevantes, apesar dos seus números de versão mais baixos. Consulte o aviso de segurança do Ubuntu.

Aplique as correções e volte a implementar. Instale os pacotes corrigidos. No caso dos contentores, registe o resumo da imagem em execução, atualize as imagens base PHP vulneráveis, recompile e volte a implementar as cargas de trabalho afetadas, incluindo os trabalhadores da fila.

Verifique o resultado. Reinicie ou substitua os PHP workers afetados e confirme se os processos e contentores em execução utilizam compilações corrigidas ou backports verificados do fornecedor. Registe as versões dos pacotes, os resumos das imagens em execução, os detalhes do reinício e os resultados da verificação.

O PHP 8.1 e versões anteriores já não são suportados a montante, embora alguns fornecedores ainda forneçam backports de segurança. Verifique se a sua compilação instalada está abrangida e atualize-a caso não esteja. O suporte de segurança do PHP 8.2 termina em 31 de dezembro de 2026, pelo que deve associar qualquer correção de curto prazo a um plano de atualização. Pode consultar o cronograma completo de suporte no calendário de suporte do PHP.

Dependências e estruturas de auditoria

Comece por composer.lock. Este ficheiro regista as versões dos pacotes de que a sua aplicação depende, incluindo as instaladas indiretamente através de outros pacotes. Execute estes dois comandos:

composer audit --locked
composer outdated

composer audit --locked verifica as versões bloqueadas em relação a alertas de segurança conhecidos e pode sinalizar pacotes abandonados. composer outdated mostra quais as atualizações disponíveis, mas um pacote desatualizado não é necessariamente vulnerável. Verifique também os avisos do Laravel ou do Symfony, especialmente se a versão do seu framework já não for suportada.

Compare os pacotes implementados em produção com as versões no ficheiro de bloqueio auditado. Guarde os resultados da auditoria e o inventário de pacotes instalados juntamente com os seus registos de lançamento.

Se encontrar pacotes vulneráveis, atualize-os para versões corrigidas compatíveis e teste as funcionalidades afetadas. Substitua as bibliotecas que já não recebem correções de segurança. Se problemas de compatibilidade impedirem a atualização do framework, documente-os, bem como o trabalho de migração necessário. Não se esqueça dos plugins de CMS ou das bibliotecas instaladas fora do Composer.

Uma auditoria do Composer sem falhas não confirma que o PHP2Shell tenha sido corrigido. A auditoria verifica os pacotes do Composer, enquanto o PHP2Shell requer uma verificação separada do PHP e das suas correções. Para avaliar a própria aplicação, utilize SAST para analisar o código-fonte e DAST para testar a aplicação em execução.

Revisão PHP e configurações do servidor

Verifique as configurações do PHP efetivamente utilizadas pelo seu servidor web, incluindo as substituições do pool do PHP-FPM e as extensões carregadas. Lembre-se de que php --ini mostra a configuração da CLI, que pode diferir da aplicação em produção.

Para produção, comece com:

display_errors = Off
log_errors = On

Mantenha os registos fora de diretórios acessíveis ao público e restrinja o acesso aos mesmos. Remova páginas públicas phpinfo() e pontos de extremidade de depuração, e reveja expose_php, extensões desnecessárias e permissões do sistema de ficheiros.

Desativar display_errors reduz a divulgação de informações, mas não mitiga a vulnerabilidade CVE-2026-109619. O caminho de código vulnerável pode ser executado antes de PHP processar a mensagem de erro.

Medidas temporárias quando a aplicação de patches ao PHP é adiada

Se a aplicação de patches tiver de ser adiada, siga as instruções do aviso oficial PHP para a sua configuração.

  • CVE-2026-109619: Desative session.upload_progress.enabled e, no PHP 8.5, defina fatal_error_backtraces=0. Aplique estas definições antes do processamento dos pedidos através da configuração do servidor ou do pool e, em seguida, reinicie os workers afetados. Podem subsistir outras vias de exploração.

  • CVE-2026-109618: Impose memory_limit=-1 ao nível do servidor ou do pool e reinicie os workers afetados. Isto elimina a via previsível de falha do PHP memory-limit, mas deixa em aberto a possibilidade de outras falhas de alocação. Verifique os limites das solicitações e as proteções de memória do anfitrião ou do contentor para reduzir os riscos de negação de serviço.

O PHP também publicou um aviso separado para o CVE-2026-115560 a 23 de outubro. Diz respeito a aplicações que mudam session.serialize_handler de php_binary ou php_serialize para php utilizando ini_set() antes de session_start(), com o progresso do upload ativado. As configurações afetadas devem desativar o progresso do upload até que seja disponibilizada uma correção.

Adquira um plano de atualização para as aplicações PHP antigas das quais a sua empresa depende

Verificar se há injeção de SQL, XSS e execução de código não seguro

O tratamento inadequado das entradas do utilizador pode expor dados confidenciais ou permitir que os atacantes executem código malicioso. Recomendo que utilize a revisão de código para identificar percursos de entrada de risco e o SAST para detetar possíveis vulnerabilidades. O DAST autorizado testa a aplicação em execução, enquanto os testes de penetração ajudam a determinar quais as fraquezas que os atacantes poderiam explorar. As aplicações criadas através da programação vibe podem apresentar as mesmas falhas e necessitam das mesmas verificações.

Injeção de SQL

A injeção de SQL ocorre quando os dados introduzidos pelo utilizador alteram a estrutura de uma consulta à base de dados. Verifique como a sua aplicação constrói as consultas, especialmente em formulários de pesquisa e relatórios.

Para manter os dados introduzidos pelo utilizador separados dos comandos SQL, utilize instruções preparadas do PDO:

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

As instruções preparadas mantêm os valores dos dados separados da sintaxe SQL, tal como o marcador de posição :email faz no exemplo. No entanto, os placeholders não podem representar nomes de tabelas ou colunas. Por exemplo, se os utilizadores puderem ordenar um relatório, selecione as colunas permitidas a partir de uma lista definida na aplicação. Teste as consultas afetadas após efetuar as alterações.

Cross-site scripting

O 'Cross-site scripting' (XSS) ocorre quando uma aplicação apresenta dados não confiáveis que um navegador pode executar como código. Verifique os modelos PHP quanto a entradas do utilizador apresentadas sem o escape adequado, especialmente nos casos em que o escape automático está desativado.

Por exemplo, se a sua aplicação apresentar o nome de um utilizador como texto HTML, utilize htmlspecialchars() para converter caracteres especiais, de modo a que o navegador os trate como texto:

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

A proteção adequada depende do local onde os dados aparecem. JavaScript, URLs e HTML requerem verificações e codificação específicas para cada contexto. Se os utilizadores puderem enviar HTML formatado, utilize um sanitizador de HTML para remover elementos perigosos, mantendo a formatação permitida.

Código não seguro e execução de comandos

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Revisão da autenticação, sessões e controlo de acesso

Comece pelas palavras-passe. Estas não devem ser armazenadas de forma legível. Verifique se a sua aplicação utiliza PHP’s password_hash() e password_verify(), ou os métodos equivalentes do framework. Procure código de hash mais antigo que possa já não ser seguro.

Em seguida, verifique o que acontece quando alguém inicia sessão. A aplicação deve gerar um novo ID de sessão, para que um ID obtido antes do início de sessão não possa ser reutilizado para aceder à conta. Reveja as definições de session.use_strict_mode e de cookies, como Secure, HttpOnly e SameSite. Teste a regeneração do ID de sessão através do seu framework, incluindo quando chegam vários pedidos ao mesmo tempo.

Agora teste se os utilizadores conseguem ver dados que não lhes pertencem. Crie duas contas de teste, cada uma com a sua própria fatura. Inicie sessão na primeira conta e altere o ID da fatura numa solicitação para aquele que pertence à segunda conta. O servidor deve negar o acesso, a menos que esse utilizador tenha permissão.

Repita o teste para a edição de faturas, o download de ficheiros e as solicitações à API. Verifique se os utilizadores normais não conseguem aceder às funções de administração. Estar com sessão iniciada não confere automaticamente a alguém permissão para aceder a todos os registos. O servidor deve verificar as permissões para cada solicitação a um registo protegido ou a um ponto final da API.

Verificar a proteção contra CSRF

Um ataque CSRF induz o navegador de um utilizador com sessão ativa a realizar uma ação que este não autorizou, como alterar os dados da conta. Comece por verificar os formulários e os pedidos que modificam dados, especialmente aqueles autenticados através de cookies de sessão.

Analise a proteção contra CSRF na sua aplicação Laravel ou Symfony e verifique se alguma rota está excluída. Nos casos em que se aplica a validação de tokens, teste pedidos com tokens em falta ou inválidos. Verifique também se as solicitações falsificadas provenientes de outro site não conseguem alterar os dados do utilizador. Verifique igualmente a configuração SameSite nos cookies de sessão.

No Laravel Blade, @csrf adiciona um campo de token oculto a um formulário:


    @csrf
    

Há um detalhe importante no Laravel 13. O seu middleware CSRF verifica primeiro o cabeçalho Sec-Fetch-Site. Uma solicitação da mesma origem pode ser aprovada sem um token, enquanto outras solicitações recorrem à validação do token por predefinição. O Laravel também desativa a proteção CSRF durante testes automatizados por predefinição, por isso certifique-se de que está ativada ao testar estas defesas.

No caso das APIs, o método de autenticação é importante. Uma API sem estado que utilize tokens «bearer» nos cabeçalhos de autorização enfrenta, geralmente, riscos de CSRF diferentes. No entanto, se a sua SPA depender de cookies de sessão, continuará a necessitar de proteção contra pedidos falsificados.

Envio e acesso seguros a ficheiros

O envio de ficheiros torna-se um risco de segurança quando os atacantes conseguem enviar ficheiros executáveis ou aceder a dados a que não deveriam ter acesso. Verifique quais os tipos e tamanhos de ficheiros que a sua aplicação aceita, onde os ficheiros enviados são armazenados e quem pode descarregá-los. Teste as rotas de envio e descarregamento quanto a 'path traversal', certifique-se de que os ficheiros enviados não podem ser executados como PHP e verifique se os ficheiros .env, .git e de cópia de segurança não estão acessíveis ao público.

Segue-se um exemplo em PHP que verifica o tipo MIME de um ficheiro carregado e o guarda com um nome gerado aleatoriamente:

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Falha no upload');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Tipo de ficheiro não suportado');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('Não foi possível guardar o ficheiro carregado');
}

O exemplo pressupõe o carregamento de um único ficheiro e a existência de um diretório privado com as permissões adequadas. A função move_uploaded_file() do PHP confirma que o ficheiro de origem foi carregado através do mecanismo HTTP POST do PHP.

A verificação MIME, por si só, não é suficiente para garantir a segurança dos uploads. O código de produção também necessita de limites de tamanho de ficheiro impostos pelo servidor, permissões de upload e download e validação do conteúdo real do ficheiro. Recodifique imagens quando apropriado e considere a verificação de malware para uploads de maior risco. Mantenha os ficheiros fora da raiz da web sempre que possível, restrinja o acesso ao sistema de ficheiros e impeça que os ficheiros carregados sejam executados como PHP.

Proteja dados confidenciais e credenciais

Palavras-passe de bases de dados, chaves de API e tokens de acesso expostos podem permitir que os atacantes tenham acesso à sua aplicação ou a dados confidenciais. Verifique o seu código-fonte e o histórico do Git para detetar estes segredos. Ferramentas como Gitleaks podem ajudar a encontrá-los. Certifique-se de que os ficheiros .env não estão armazenados no Git nem são acessíveis através da Web. Verifique também quem pode aceder a segredos nos pipelines de CI/CD e analise as imagens de contentores e os registos da aplicação à procura de informações confidenciais.

Mantenha os segredos num gestor de segredos ou noutro sistema com acesso restrito, em vez de no código da aplicação. Limite quem pode visualizá-los ou alterá-los e conceda a cada aplicação apenas as permissões de que necessita.

Se uma credencial for exposta, revogue-a ou substitua-a e atualize os serviços que a utilizam. Remova as cópias expostas, investigue se alguém a utilizou sem autorização e evite que os segredos apareçam em registos futuros. Remover um segredo do seu código não o desativa nem o apaga de commits antigos do Git.

Obtenha uma avaliação de segurança especializada em PHP

Como priorizar, implementar e verificar correções de segurança do PHP

01
Priorizar as vulnerabilidades

Dê prioridade aos sistemas expostos a ataques. Avalie o CVSS em conjunto com o PHP SAPI, a exposição à Internet, as proteções existentes e o impacto nos negócios. As cargas de trabalho mod_php sem patches e expostas à Internet requerem atenção urgente, enquanto outras SAPIs ainda necessitam de avaliação.

02
Aplicar correções de forma segura

Registe as aplicações afetadas, PHP pools de trabalhadores e resumos das imagens dos contentores. Teste no ambiente de pré-produção e prepare um plano de recuperação antes da implementação. Aplique correções aos pacotes afetados ou recompile as imagens e, em seguida, reinicie ou substitua todos os workers afetados. As regras do WAF e as medidas de mitigação na configuração podem reduzir a exposição a vias de exploração específicas. No entanto, não corrigem o ambiente de execução vulnerável.

03
Verificar a correção

Verifique qual a versão do PHP que está a processar os pedidos em tempo real e confirme o seu estado de patches, incluindo quaisquer backports do fornecedor. Verifique se os workers afetados foram reiniciados ou substituídos, execute testes de regressão e repita a verificação de segurança que falhou anteriormente. Monitorize o ambiente de produção para detetar erros após a implementação.

04
Investigar uma possível violação de segurança

A aplicação da correção resolve a vulnerabilidade. Qualquer comprometimento anterior continua a exigir investigação. Analise os registos do servidor, falhas dos processos, ficheiros desconhecidos e atividade de rede suspeita. No mod_php, o PHP2Shell pode ser executado antes do início do registo da aplicação, pelo que registos limpos da estrutura não permitem excluir a possibilidade de um ataque. Encaminhe os sinais de alerta para a equipa de resposta a incidentes e preserve as provas.

05
Manter a segurança

Acompanhar novas vulnerabilidades do PHP e das suas dependências e adicionar verificações de segurança ao CI/CD. Basear as avaliações regulares na exposição das aplicações e no risco empresarial e reavaliar após alterações significativas ou divulgações críticas.

arrow-icon.arrow-icon.
01 Priorizar as vulnerabilidades

Dê prioridade aos sistemas expostos a ataques. Avalie o CVSS em conjunto com o PHP SAPI, a exposição à Internet, as proteções existentes e o impacto nos negócios. As cargas de trabalho mod_php sem patches e expostas à Internet requerem atenção urgente, enquanto outras SAPIs ainda necessitam de avaliação.

arrow-icon.arrow-icon.
02 Aplicar correções de forma segura

Registe as aplicações afetadas, PHP pools de trabalhadores e resumos das imagens dos contentores. Teste no ambiente de pré-produção e prepare um plano de recuperação antes da implementação. Aplique correções aos pacotes afetados ou recompile as imagens e, em seguida, reinicie ou substitua todos os workers afetados. As regras do WAF e as medidas de mitigação na configuração podem reduzir a exposição a vias de exploração específicas. No entanto, não corrigem o ambiente de execução vulnerável.

arrow-icon.arrow-icon.
03 Verificar a correção

Verifique qual a versão do PHP que está a processar os pedidos em tempo real e confirme o seu estado de patches, incluindo quaisquer backports do fornecedor. Verifique se os workers afetados foram reiniciados ou substituídos, execute testes de regressão e repita a verificação de segurança que falhou anteriormente. Monitorize o ambiente de produção para detetar erros após a implementação.

arrow-icon.arrow-icon.
04 Investigar uma possível violação de segurança

A aplicação da correção resolve a vulnerabilidade. Qualquer comprometimento anterior continua a exigir investigação. Analise os registos do servidor, falhas dos processos, ficheiros desconhecidos e atividade de rede suspeita. No mod_php, o PHP2Shell pode ser executado antes do início do registo da aplicação, pelo que registos limpos da estrutura não permitem excluir a possibilidade de um ataque. Encaminhe os sinais de alerta para a equipa de resposta a incidentes e preserve as provas.

arrow-icon.arrow-icon.
05 Manter a segurança

Acompanhar novas vulnerabilidades do PHP e das suas dependências e adicionar verificações de segurança ao CI/CD. Basear as avaliações regulares na exposição das aplicações e no risco empresarial e reavaliar após alterações significativas ou divulgações críticas.

Exemplo prático: uma atualização de produção que parece ter sido bem-sucedida, mas que não o foi

Uma loja Symfony utiliza o PHP 8.3 com o nginx e o PHP-FPM. O administrador atualiza os pacotes do sistema operativo e executa o comando `php -v`. O comando mostra uma versão corrigida, pelo que tudo parece estar bem. No entanto, o comando `php -v` verifica apenas o binário PHP da linha de comandos.

Os pedidos dos clientes continuam a passar pelo nginx para os workers do PHP-FPM que foram iniciados antes da atualização. As tarefas em segundo plano também são executadas num contentor separado com uma camada base PHP vulnerável. Os pacotes podem estar atualizados no servidor, mas estas cargas de trabalho continuam a executar o código antigo.

PHP build checks for web, workers, and CLI.

Para concluir a correção, a equipa precisa de identificar todas as aplicações e conjuntos de trabalhadores afetados, reiniciar os trabalhadores do FPM e voltar a implementar o contentor da fila com uma imagem corrigida. Em seguida, devem verificar se os processos PHP em execução utilizam compilações corrigidas ou backports verificados pelo fornecedor.

Teste o checkout e os uploads de ficheiros no ambiente de teste, execute testes de verificação de funcionamento em produção e repita as verificações de segurança que falharam anteriormente. O registo de implementação deve incluir o PHP SAPI a servir o tráfego web, versões de pacotes verificadas ou resumos de imagens, provas de reinício e teste, e o responsável.

Uma auditoria do Composer com resultado positivo não é prova de que o PHP2Shell tenha sido corrigido. Esse comando verifica as dependências, não o PHP interpretador que processa os pedidos web.

Analise o ID de utilizador do PHP worker, os diretórios graváveis, os segredos montados, as permissões da base de dados e o acesso de rede de saída. Estes fatores determinam se um atacante poderia modificar ficheiros da aplicação, ler credenciais ou aceder a outros sistemas. O princípio do privilégio mínimo e a segmentação da rede podem limitar os danos caso um worker seja comprometido, mas continua a ser necessário aplicar as correções ao interpretador.

O comando `php -v` mostra a versão do PHP na linha de comandos, mas não permite confirmar qual o interpretador que está a processar o tráfego de produção nem se os workers de execução prolongada ainda estão a utilizar a compilação vulnerável. Com o PHP2Shell, verificamos primeiro o ambiente de execução ativo e, em seguida, analisamos as dependências e o código da aplicação. Só consideramos a correção concluída depois de confirmarmos que a versão corrigida está, de facto, a processar os pedidos de produção.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Diretor de GRC, Cibersegurança e Sustentabilidade

Como a Innowise pode ajudar a proteger as suas aplicações PHP

Na Innowise, reunimos PHP e conhecimentos especializados em segurança. Os nossos mais de 100 programadores PHP já concluíram mais de 250 projetos, e os nossos mais de 50 engenheiros de cibersegurança ajudam a identificar e a resolver vulnerabilidades. O nosso trabalho conta também com o apoio das certificações ISO/IEC 27001:2022 e ISO 9001:2015.

Verificamos as suas aplicações PHP quanto a problemas de segurança, incluindo dependências vulneráveis e componentes desatualizados. Os nossos programadores tratam das correções e atualizações necessárias, enquanto os engenheiros de segurança testam as alterações antes do lançamento. Se não souber por onde começar, a nossa IT pode avaliar os riscos e ajudar a definir as prioridades do trabalho.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

Os nossos projetos em PHP

Redesenho e reconstrução do site da MedSpa Network
A Innowise reformulou o site da MedSpa Network no WordPress, permitindo à sua equipa controlar as atualizações diárias de conteúdo.
2 meses desde o início até ao lançamento
3-5 leads por semana, em comparação com 1 por mês
Ver estudo de caso
Avaliação do cliente
Ver estudo de caso
Client review logo. Avaliação do cliente
MedSpa Network website redesign and rebuild.
Bot de IA para a campanha de marketing do TBC Bank
A Innowise criou um bot bilingue no Telegram que gera selfies geradas por IA com o embaixador da marca do TBC Bank, uma estrela do futebol.
3,000 utilizadores envolvidos
2 idiomas suportados
Ver estudo de caso
Avaliação do cliente
Ver estudo de caso
Client review logo. Avaliação do cliente
AI Telegram bot..
Definição da estratégia de produto para a plataforma de empréstimos em bitcoin da Bitlendex
A Innowise conduziu uma fase de descoberta para a Bitlendex, ajudando o cliente a transformar um conceito de produto em fase inicial num modelo de negócio validado e num MVP claramente definido.
1 mês para uma fase de investigação completa
Sistema de consultoria financeira para Bonnfinanz
A Innowise ajudou a Bonnfinanz a criar um sistema de aconselhamento e gestão baseado na Web que permite o trabalho móvel e a interação direta com o cliente.
Plataforma de carregamento de veículos elétricos com faturação flexível
A Innowise contribuiu para a modernização da plataforma de mobilidade elétrica da SMART/LAB, melhorando as suas capacidades de faturação, pagamento, gestão de transações e elaboração de relatórios.
>50% processamento mais rápido da faturação e dos pagamentos
Transformação DevOps cloud-native da FinXP
A Innowise ajudou a FinXP a modernizar a sua infraestrutura de serviços financeiros, através da migração de APIs e aplicações legadas baseadas em PHP para uma arquitetura nativa da nuvem.
11 aplicações transferidas para o Azure App Service
100% Infraestrutura como código
SEO técnico para plataforma de e-commerce
A Innowise resolveu problemas técnicos críticos relacionados com o SEO e o desempenho na plataforma de comércio eletrónico da Officine 08.
<500 ms tempo de resposta do servidor
5 meses para concluir o projeto
Ver estudo de caso
Avaliação do cliente
Ver estudo de caso
Client review logo. Avaliação do cliente
SEO técnico para plataforma de e-commerce.
Desenvolvimento contínuo de uma plataforma de subscrição de perfumes
A Innowise ajudou a Scentbird a expandir a sua plataforma de subscrição para dar resposta a novas experiências de compras e ao crescimento internacional.
4 anos de apoio contínuo
Ver estudo de caso
Avaliação do cliente
Ver estudo de caso
Client review logo. Avaliação do cliente
Continuous development of a fragrance subscription platform.
01 / 01
Close popup icon

Conclusão

O PHP2Shell revelou um risco grave no próprio PHP. As atualizações do framework e as verificações de dependências não corrigem as vulnerabilidades a esse nível. As empresas precisam de identificar todos os ambientes de execução PHP que processam pedidos web, instalar as atualizações de segurança e verificar se os servidores de produção estão a executar as versões corrigidas.

A segurança do PHP também requer verificações regulares do código das aplicações, da configuração e dos controlos de acesso, especialmente após a divulgação de vulnerabilidades críticas ou atualizações importantes. Se precisar de ajuda para avaliar a sua exposição ou verificar as correções, a Innowise oferece consultoria em segurança de TI e avaliação de cibersegurança da

Innowise podem apoiar esse trabalho.

FAQ

A sua aplicação pode estar em risco se o seu servidor executar uma versão do PHP que não tenha sido corrigida para as vulnerabilidades CVE-2026-109618 e CVE-2026-109619. Verifique qual a versão do PHP que está efetivamente a ser executada e se o seu fornecedor de alojamento já aplicou as correções. O Apache mod_php apresenta o risco confirmado mais elevado, mas o PHP-FPM também deve ser verificado. Uma vez que as vulnerabilidades se encontram no próprio PHP, atualizar o WordPress ou outra estrutura não as irá corrigir.

As correções para o PHP2Shell estão disponíveis no PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Alguns fornecedores de Linux fizeram o backport dos patches para versões mais antigas, por isso verifique o aviso do seu fornecedor. Certifique-se de que os seus workers PHP em execução utilizam a versão corrigida. No Windows, instale os pacotes atualizados de 26 de outubro que terminam em -1, os quais também corrigem uma vulnerabilidade separada do Brotli.

Se não for possível atualizar o PHP de imediato, restrinja o acesso público às aplicações afetadas, sempre que possível. Para sites que têm de permanecer online, o administrador do seu servidor pode aplicar medidas temporárias indicadas no aviso de segurança do PHP, tais como limitar o tamanho dos pedidos ou desativar o progresso de upload durante a sessão. Teste estas alterações para se certificar de que o site continua a funcionar. Estas medidas apenas reduzem o risco, pelo que a instalação de uma versão corrigida do PHP continua a ser urgente.

Não. A atualização do PHP corrige vulnerabilidades no ambiente de execução do PHP, mas não resolve problemas de segurança no código da sua aplicação, em plugins desatualizados ou na configuração do servidor. Tem de verificar e resolver esses problemas separadamente.

Recomendo verificar as aplicações PHP quanto a vulnerabilidades conhecidas, pelo menos uma vez por mês, com verificações mais frequentes para sistemas de alto risco. Acompanhe continuamente os avisos de segurança do PHP e as dependências, e agende auditorias mais exaustivas com base na exposição da sua aplicação e no risco empresarial. É importante realizar testes adicionais após atualizações importantes ou divulgações de vulnerabilidades críticas.

Consulte os avisos de segurança do PHP e os boletins do seu fornecedor de alojamento ou do sistema operativo para identificar vulnerabilidades conhecidas. Utilize o comando composer audit --locked para verificar as dependências, recorra à análise estática e à revisão de código para identificar problemas ao nível da aplicação e utilize o OWASP ZAP para testar a sua aplicação web com as devidas autorizações. Para verificar as correções de segurança, verifique a versão do PHP em execução no ambiente de produção e quaisquer correções retroativas fornecidas pelo seu fornecedor.

Sim. As atualizações podem causar problemas de compatibilidade com código ou extensões mais antigas. Teste-as num ambiente de teste antes de atualizar a sua aplicação em produção e tenha um plano de recuperação pronto, caso algo deixe de funcionar.

Correlacione os registos do proxy inverso, do Apache/nginx, do PHP-FPM e do EDR/host. Procure falhas nos workers, ficheiros ou processos suspeitos, tráfego de saída inesperado e sinais de exposição de credenciais. Os registos da aplicação podem não detetar explorações em tempo de execução do PHP que ocorram antes de o framework iniciar o registo. Se detetar atividade suspeita, inicie a resposta a incidentes e preserve as provas forenses.

Mostrar mais Mostrar menos

Índice

Descubra quais as cargas de trabalho PHP que precisam de uma atualização de segurança em primeiro lugar

    Contacte-nos

    Agende uma chamada ou preencha o formulário abaixo e entraremos em contacto consigo assim que analisarmos o seu pedido.

    Envie-nos uma mensagem de voz
    Anexar documentos
    Enviar ficheiro

    Pode anexar um ficheiro com um máximo de 2MB. Formatos de ficheiro válidos: pdf, jpg, jpeg, png.

    Ao clicar em «Enviar», autoriza a Innowise a tratar os seus dados pessoais de acordo com a nossa Política de Privacidade , para lhe fornecer informações relevantes. Ao enviar o seu número de telefone, aceita que possamos contactá-lo através de chamadas de voz, SMS e aplicações de mensagens. Poderão aplicar-se tarifas de chamadas, mensagens e dados.

    Pode também enviar-nos o seu pedido
    para contact@innowise.com
    O que é que acontece a seguir?
    1

    Assim que recebermos e analisarmos o seu pedido, entraremos em contacto consigo para detalhar as necessidades do seu projeto e assinar um NDA para garantir a confidencialidade.

    2

    Depois de analisarmos os seus desejos, necessidades e expectativas, a nossa equipa elaborará uma proposta de projeto com o âmbito do trabalho, dimensão da equipa, tempo e estimativas de custos.

    3

    Marcaremos uma reunião consigo para discutir a oferta e acertar os pormenores.

    4

    Por fim, assinaremos um contrato e começaremos a trabalhar no seu projeto imediatamente.

    Mais serviços abrangidos

    arrow