Quantcast

PHP2Shell: há duas falhas críticas no PHP! Correções chegam hoje

8 Comentários

Duas vulnerabilidades críticas no PHP estão a motivar um alerta de segurança internacional. Conhecidas informalmente como PHP2Shell, as falhas poderão permitir a execução remota de código em servidores vulneráveis, colocando em risco sites, aplicações web e plataformas de comércio eletrónico.

A equipa responsável pelo PHP anunciou uma atualização de segurança de emergência para 21 de outubro, com as duas vulnerabilidades classificadas com uma pontuação de 9.2 em 10 na escala CVSS v4.0. Os administradores de sistemas são aconselhados a preparar a instalação das correções assim que estas estiverem disponíveis.

PHP2Shell: o que se sabe sobre as vulnerabilidades?

As duas falhas estão associadas aos identificadores CVE-2026-109618 e CVE-2026-109619. Segundo informações divulgadas por investigadores de cibersegurança, ambas poderão permitir a execução remota de código (RCE), uma das categorias de vulnerabilidades mais preocupantes, uma vez que pode possibilitar a execução de comandos no servidor afetado.

O cenário é particularmente relevante quando o ataque pode ser realizado sem autenticação, ou seja, sem que o atacante necessite de possuir uma conta legítima no sistema.

Apesar da gravidade do alerta, os detalhes técnicos completos e o âmbito exato das versões afetadas ainda dependem da informação oficial publicada com as correções. A designação PHP2Shell é utilizada pela comunidade de segurança e não corresponde a um nome oficial atribuído pela equipa do PHP.

Milhares de sites e aplicações poderão estar em risco

O PHP continua a ser uma tecnologia fundamental para o desenvolvimento web, sendo utilizado por sistemas de gestão de conteúdos, lojas online, plataformas empresariais e serviços de alojamento.

Entre as tecnologias e plataformas que utilizam PHP encontram-se:

  • WordPress;
  • Drupal;
  • Joomla;
  • Magento;
  • Laravel;
  • phpBB.

A presença de PHP nestes ecossistemas não significa, por si só, que todas as instalações estejam vulneráveis. O risco depende das versões utilizadas, das condições de exploração e das correções disponibilizadas pelos respetivos fornecedores.

Um ataque bem-sucedido poderá permitir a execução de comandos com as permissões do processo PHP, abrindo caminho a consequências como o roubo de dados, a instalação de ferramentas maliciosas, a alteração de páginas web ou o comprometimento de outros componentes do servidor.

Versões antigas do PHP representam um risco acrescido

Um dos principais problemas identificados prende-se com os sistemas que utilizam versões antigas do PHP.

As versões 8.2, 8.3, 8.4 e 8.5 encontram-se nos ramos com suporte oficial, embora com diferentes níveis de manutenção. Já as versões 8.1 e anteriores estão fora do suporte oficial e não recebem normalmente novas correções de segurança por parte do projeto PHP.

Segundo dados divulgados pela empresa de segurança Mallory, cerca de 884 mil servidores expostos à Internet apresentavam, a 20 de outubro, indicadores de utilização de versões PHP 8.1 ou anteriores. Este número resulta de identificações efetuadas através do Shodan e não significa que todos esses servidores estejam confirmadamente vulneráveis às falhas PHP2Shell.

O que devem fazer os administradores de sistemas?

Perante a gravidade do alerta, a recomendação é preparar uma resposta rápida e coordenada, sobretudo nos sistemas acessíveis a partir da Internet.

Entre as principais medidas estão:

  1. Inventariar as instalações PHP: identificar servidores, aplicações, painéis de alojamento e equipamentos que incluam esta tecnologia.
  2. Aplicar as atualizações de segurança: instalar as versões corrigidas assim que forem disponibilizadas pelo projeto PHP ou pelo fornecedor do sistema operativo e do alojamento.
  3. Dar prioridade aos sistemas expostos: começar pelos servidores públicos, lojas online e aplicações que processem informação sensível.
  4. Reavaliar versões sem suporte: planear a migração para um ramo suportado ou adotar medidas de contenção enquanto não existir uma solução segura.
  5. Monitorizar atividade suspeita: procurar processos inesperados iniciados pelo PHP, alterações a ficheiros, novas tarefas agendadas e outros sinais de comprometimento.
  6. Isolar sistemas que não possam ser corrigidos: se um servidor vulnerável não puder ser atualizado atempadamente, considerar restringir o acesso à rede pública até ser possível aplicar uma solução adequada.

Estas medidas são particularmente importantes porque, no momento do alerta inicial, não existia ainda uma confirmação pública de exploração ativa das duas falhas. A ausência de ataques conhecidos, contudo, não elimina o risco.

Partilhar:
Tags:

Comentários

8
  1. ZA
    Zé Fonseca A.

    Para quem não acompanhou a novela, isto já é antigo e decidiram sentar-se em cima do problema, então os investigadores decidiram tornar pública a vulnerabilidade hoje, avisaram que o iam fazer e assim forçaram a agir, o que não vai dar tempo suficiente para ninguém fazer patch..

    há ainda muita gente que não se adaptou e ainda está a trabalhar como se fosse 2020

    1. RC
      Rui Cardoso

      Onde viste isso?

      1. ZA
        Zé Fonseca A.

        faz parte do meu trabalho, tenho uma blue team com dimensão relevante, não há leaks sem estarmos atentos

  2. JE
    jedi

    Segundo li, já estava agenda ser lançado para amanha (22/10) o patch, contudo devido alguem a ter-se antecipado e colocar em sites como hakernews ontem alguma info sobre 2 CVE de 9.2 , foram obrigados a antecipar para hoje às 14h UTC, como está indicado no site oficial do PHP.

    Isto afeta todas a versoes, ora somente as versoes 8.x receberam o patch.

    1. ZA
      Zé Fonseca A.

      Não é alguém, é a equipa que descobriu a vulnerabilidade que já anda a avisar há meses para ser corrigida, acho muito bem

  3. A
    A.

    Espero é que tenham dado tempo mínimo antes desta CVE, causar valentes estragos …

    1. ZA
      Zé Fonseca A.

      Isto foi descoberto numa auditoria externa em 2024, a história já cheirava mal, os investigadores foram forçados a publicar as vulnerabilidades que podem já andar a ser usadas para ataques para que a equipa php tomasse medidas, temos pena de não dar tempo para corrigir, não tivessem desde 2024 a assobiar

  4. PL
    Plesky

    Nem vos digo o caos que foi hoje… Só digo assim, desde as 23h de ontem até às 15:30h de hoje foi o tempo levado para criar e lançar o patch, mas só nas compilações Linux. Windows ainda vai levar um tempo.

Deixe um comentário