PHP2Shell: falhas críticas de RCE no PHP exigem patch já

Neste artigo do Blog Dolutech, vamos analisar um dos alertas mais sérios do ano para quem administra servidores web: duas vulnerabilidades críticas de execução remota de código (RCE) no núcleo do PHP, rastreadas como CVE-2026-109618 e CVE-2026-109619 e já apelidadas pela comunidade de PHP2Shell. O tema ganhou peso institucional com o Security Advisory 2026-018 da CERT-EU, a equipe de resposta a incidentes das instituições da União Europeia, que recomenda preparar a aplicação imediata da correção e, onde isso não for possível, considerar isolar aplicações expostas à internet até a chegada do patch.

O cenário é incomum por um motivo simples: os detalhes vazaram antes do fim do embargo. Isso transformou uma divulgação coordenada em uma corrida contra o relógio, e é exatamente por isso que nós, da Dolutech, decidimos organizar aqui o que está confirmado, o que ainda é hipótese e, principalmente, o que você pode fazer hoje nos seus servidores.

O que é o PHP2Shell e por que o alerta da CERT-EU importa

O PHP continua sendo a base de uma fatia enorme da web pública: WordPress, WooCommerce, Magento, Shopware, Drupal, Laravel, painéis de hospedagem e incontáveis sistemas internos. Uma falha no próprio interpretador não depende de plugin, tema ou código da aplicação. Ela atinge a camada que processa a requisição antes mesmo de o seu código ser executado.

O que a equipe de segurança do PHP confirmou oficialmente

Em 20 de outubro de 2026, a equipe de segurança do PHP publicou um aviso antecipado no php.net informando que:

• uma versão de segurança está agendada para quarta-feira, 21 de outubro de 2026, às 14:00 UTC;
• ela corrige duas vulnerabilidades críticas, ambas com pontuação CVSS v4.0 9.2;
• todos os usuários devem se preparar para atualizar assim que a versão estiver disponível;
• o lançamento pode ser antecipado caso os detalhes se tornem públicos ou surjam evidências de exploração ativa;
• versões afetadas, versões corrigidas e detalhes técnicos só serão publicados junto com o lançamento.

Repare em um detalhe importante: o comunicado oficial do PHP não cita os identificadores CVE nem a classe da falha. Essas informações vieram de outras fontes.

O que veio de vazamentos e de pesquisadores

Segundo a cronologia reunida pela Sansec, uma publicação no Hacker News na tarde de 20 de outubro antecipou a existência de duas RCEs no PHP, originalmente previstas para divulgação em 22 de outubro. Logo depois, a watchTowr confirmou publicamente que as falhas são reais, informou ter reproduzido a CVE-2026-109618 e declarou que só compartilhará detalhes técnicos após a publicação dos patches. A própria CERT-EU passou a referenciar os dois CVEs no seu boletim, indicando, com base em relatos de terceiros, que todas as versões a partir do PHP 5 podem estar afetadas.

Linha do tempo do vazamento

Até o fechamento desta análise, a página principal do php.net ainda listava como versões atuais a 8.5.11, 8.4.26, 8.3.35 e 8.2.34, todas publicadas em 24 de setembro. Ou seja, no momento em que escrevemos, a correção oficial ainda não estava disponível. Verifique o php.net antes de aplicar qualquer passo deste guia.

Versões afetadas e o problema do PHP fora de suporte

Este é o ponto que mais preocupa a equipe da Dolutech. O PHP mantém hoje apenas os ramos 8.2, 8.3, 8.4 e 8.5, sendo que o 8.2 está em suporte somente de segurança e chega ao fim de vida em 31 de dezembro de 2026. Tudo o que é anterior, incluindo 8.1, 8.0, toda a série 7 e a série 5, não deve receber correção oficial.

Nota de transparência: os números 8.5.12, 8.4.27, 8.3.36 e 8.2.35 circulam em análises independentes e correspondem à próxima versão de cada ramo, mas ainda não foram confirmados pelo PHP. Considere oficial apenas o que for publicado no php.net e nos avisos de segurança do repositório php-src.

Na prática, isso significa que servidores legados, appliances com PHP embarcado, imagens Docker antigas e hospedagens compartilhadas que ainda oferecem PHP 7.4 podem ficar expostos indefinidamente. A única saída real para esses ambientes é migrar para um ramo suportado ou depender de um backport do fornecedor (distribuições Linux com suporte estendido, painéis de hospedagem comerciais e afins).

Análise técnica: o que sabemos e o que ainda é hipótese

Aqui a disciplina de verificação é essencial. Nenhuma causa raiz foi confirmada pelo PHP, e tudo o que descrevemos nesta seção deve ser tratado como hipótese até a divulgação oficial.

A hipótese do session.upload_progress

Diversas análises independentes, algumas baseadas em material privado, apontam para um possível problema de corrupção de memória do tipo use-after-free no mecanismo de session upload progress, acionado por requisições POST do tipo multipart/form-data especialmente construídas.

O raciocínio faz sentido do ponto de vista arquitetural. A diretiva session.upload_progress.enabled vem ativada por padrão no PHP. Quando ela está ativa e uma requisição multipart contém um campo com o nome definido em session.upload_progress.name (por padrão, PHP_SESSION_UPLOAD_PROGRESS), o PHP passa a registrar o progresso do envio na sessão. Isso acontece durante o processamento do corpo da requisição, antes de qualquer código da aplicação rodar, e independentemente de a aplicação usar ou não esse recurso. Qualquer script PHP acessível na internet se torna, em tese, uma porta de entrada.

Ainda assim, um pesquisador citado em várias análises afirma que desativar essa diretiva bloquearia apenas uma das duas falhas, e a própria GMO Flatt Security não garante a eficácia total da medida. Por isso, tratamos a desativação como redução de superfície de ataque, não como correção.

Por que 9.2 e não 10.0

O post vazado e a watchTowr descreveram inicialmente as falhas como CVSS 10.0, enquanto a equipe do PHP atribuiu 9.2 no CVSS v4.0. A diferença é coerente com explorações de corrupção de memória, que costumam ter algum requisito de ataque, como dependência de configuração ou de layout de heap. Para quem defende, a conclusão não muda: a CERT-EU interpreta a pontuação como indicativa de RCE sem autenticação.

Lições do histórico do PHP

Nós já vimos esse filme antes. A CVE-2019-11043, no PHP-FPM com Nginx, foi explorada em massa logo após a divulgação. A CVE-2024-4577, injeção de argumentos no PHP-CGI para Windows, entrou em campanhas de ransomware e botnets em poucos dias. A Sansec estima que a exploração em massa do PHP2Shell pode começar cerca de 15 minutos após a publicação do patch, já que o diff do código corrigido entrega aos atacantes o mapa da falha. A watchTowr e a Huntress relatam, até agora, não terem observado exploração ativa.

Impacto real: quem está na linha de fogo

A Dolutech considera os seguintes ambientes como prioridade máxima:

• Lojas virtuais com Magento, Adobe Commerce, Shopware e WooCommerce, alvos históricos de skimmers do tipo Magecart.
• Sites WordPress em hospedagem compartilhada, onde o cliente final não controla a versão do PHP.
• Painéis de hospedagem (cPanel, Plesk, DirectAdmin) e servidores multi-inquilino, onde um único comprometimento pode atingir centenas de sites.
• Appliances e produtos comerciais que embarcam PHP, frequentemente em versões antigas.
• Contêineres baseados em imagens php: desatualizadas, que raramente são reconstruídos.

Um ponto relevante: WAFs de aplicação e plugins de segurança que rodam dentro do PHP não protegem contra uma falha que ocorre antes do código da aplicação ser carregado. A defesa precisa acontecer na infraestrutura.

Mapeamento MITRE ATT&CK

Como ainda não há exploração confirmada, o mapeamento abaixo é antecipatório, baseado no comportamento observado em campanhas contra RCEs anteriores do PHP.

Indicadores de Comprometimento (IoCs)

Nota de transparência: até o momento desta publicação, nenhum IoC oficial (hashes, endereços IP, domínios ou assinaturas) foi divulgado pelo PHP, pela CERT-EU ou pelos pesquisadores envolvidos. A tabela a seguir reúne indicadores comportamentais para caça a ameaças, não indicadores confirmados. Atualizaremos este artigo quando IoCs oficiais forem publicados.

Como mitigar o PHP2Shell: guia técnico da Dolutech

A ordem de prioridade é clara: inventariar, reduzir a superfície, monitorar e aplicar o patch oficial assim que for publicado. Teste todos os scripts em homologação antes de levá-los à produção.

1. Inventário de todas as instalações PHP (Bash)

Muitas organizações descobrem nessa hora que têm mais versões do PHP do que imaginavam. O script abaixo localiza binários em caminhos comuns (incluindo cPanel, Plesk, Remi e LiteSpeed), classifica a versão e verifica a diretiva de upload progress e a presença em contêineres.

#!/usr/bin/env bash
# Dolutech - Inventario de instalacoes PHP | PHP2Shell (CVE-2026-109618 / CVE-2026-109619)
# Ajuste as versoes corrigidas abaixo conforme o anuncio oficial em php.net
set -u
FIXED_82="8.2.35"; FIXED_83="8.3.36"; FIXED_84="8.4.27"; FIXED_85="8.5.12"

classify() {
  local v="$1" mm fixed=""
  mm="${v%.*}"
  case "$mm" in
    8.2) fixed=$FIXED_82 ;; 8.3) fixed=$FIXED_83 ;;
    8.4) fixed=$FIXED_84 ;; 8.5) fixed=$FIXED_85 ;;
    8.6) echo "PRE-RELEASE (nao usar em producao)"; return ;;
    *)   echo "FORA DE SUPORTE (sem correcao oficial)"; return ;;
  esac
  if [ "$(printf '%s\n%s\n' "$fixed" "$v" | sort -V | head -n1)" = "$fixed" ]; then
    echo "OK (>= $fixed)"
  else
    echo "VULNERAVEL PROVAVEL (< $fixed)"
  fi
}

echo "== Binarios PHP no host =="
find /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin /opt /usr/local/lsws -maxdepth 6 \
  -type f -regextype posix-extended -regex '.*/(php|php-fpm|php-cgi|lsphp)[0-9.]*$' 2>/dev/null |
sort -u | while read -r bin; do
  ver=$("$bin" -v 2>/dev/null | head -n1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)
  [ -z "$ver" ] && continue
  upl=$("$bin" -i 2>/dev/null | grep -m1 '^session.upload_progress.enabled' | awk -F'=>' '{print $2}' | xargs)
  printf '%-55s %-8s %-40s upload_progress=%s\n' "$bin" "$ver" "$(classify "$ver")" "${upl:-?}"
done

echo; echo "== Overrides de upload_progress em pools FPM e configs =="
grep -RIns "session.upload_progress" /etc/php* /etc/php-fpm.d /etc/opt/remi \
  /opt/cpanel/ea-php*/root/etc /opt/plesk/php 2>/dev/null || echo "Nenhum override encontrado."

if command -v docker >/dev/null 2>&1; then
  echo; echo "== Conteineres em execucao com PHP =="
  docker ps --format '{{.Names}}' | while read -r c; do
    ver=$(timeout 10 docker exec "$c" php -v 2>/dev/null | head -n1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)
    [ -n "$ver" ] && printf '%-40s %-8s %s\n' "$c" "$ver" "$(classify "$ver")"
  done
fi

2. Mitigação temporária: desativar o session.upload_progress (Bash)

Esta é uma medida não oficial de redução de superfície. Os uploads continuam funcionando; apenas o rastreamento de progresso na sessão deixa de existir, recurso que pouquíssimas aplicações modernas utilizam. Como a diretiva é do tipo INI_PERDIR, a forma mais confiável é aplicá-la no php.ini global ou no conf.d, e não em ini_set() dentro da aplicação.

#!/usr/bin/env bash
# Dolutech - Mitigacao temporaria NAO OFICIAL para PHP2Shell
# Desativa session.upload_progress e, opcionalmente, ativa session.use_strict_mode
set -euo pipefail
[ "$(id -u)" -eq 0 ] || { echo "Execute como root."; exit 1; }

ENABLE_STRICT=1   # 1 = ativa session.use_strict_mode (recomendado pelo manual do PHP)
INI_NAME="99-dolutech-php2shell.ini"
{
  echo "; Dolutech - mitigacao temporaria PHP2Shell - $(date +%F)"
  echo "session.upload_progress.enabled = 0"
  [ "$ENABLE_STRICT" -eq 1 ] && echo "session.use_strict_mode = 1"
} > /tmp/$INI_NAME

shopt -s nullglob
DIRS=( /etc/php/*/*/conf.d /etc/php.d /etc/opt/remi/php*/php.d \
       /opt/cpanel/ea-php*/root/etc/php.d /opt/plesk/php/*/etc/php.d )

for d in "${DIRS[@]}"; do
  [ -d "$d" ] || continue
  install -m 0644 /tmp/$INI_NAME "$d/$INI_NAME"
  echo "[+] Aplicado em $d/$INI_NAME"
done
rm -f /tmp/$INI_NAME

echo "[*] Verificando overrides em pools FPM (php_admin_value tem precedencia):"
grep -RIn "session.upload_progress" /etc/php/*/fpm/pool.d /etc/php-fpm.d \
  /opt/cpanel/ea-php*/root/etc/php-fpm.d 2>/dev/null || echo "    nenhum."

echo "[*] Reiniciando servicos PHP-FPM e recarregando o servidor web"
systemctl list-units --type=service --state=running --no-legend '*php*fpm*' |
  awk '{print $1}' | while read -r svc; do
    systemctl restart "$svc" && echo "    reiniciado: $svc"
  done
for web in apache2 httpd; do
  systemctl is-active --quiet "$web" && systemctl reload "$web" && echo "    recarregado: $web"
done

echo "[*] Validacao:"
for bin in /usr/sbin/php-fpm* /opt/cpanel/ea-php*/root/usr/sbin/php-fpm /opt/plesk/php/*/sbin/php-fpm; do
  [ -x "$bin" ] || continue
  printf '%-50s ' "$bin"; "$bin" -i 2>/dev/null | grep -m1 '^session.upload_progress.enabled' || echo "nao verificado"
done

Em hospedagem compartilhada sem acesso root, solicite a alteração ao provedor ou use o editor de php.ini do painel, se disponível.

3. Regra de WAF (ModSecurity) e bloqueio de multipart no Nginx

Uma regra no ModSecurity, inspecionando o corpo na fase 2, impede que o campo de upload progress chegue ao PHP. Atenção: análises independentes alertam para possíveis variantes que não passam por esse campo, então trate a regra como camada adicional.

# Dolutech - Bloqueio temporario PHP2Shell (ModSecurity v2/v3)
SecRequestBodyAccess On

SecRule ARGS_POST_NAMES|ARGS_NAMES "@rx (?i)^php_session_upload_progress$" \
  "id:1026018,phase:2,deny,status:403,log,auditlog,\
  msg:'Dolutech: campo PHP_SESSION_UPLOAD_PROGRESS bloqueado (PHP2Shell)',\
  tag:'CVE-2026-109618',tag:'CVE-2026-109619'"

SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
  "id:1026019,phase:2,deny,status:400,log,\
  msg:'Dolutech: corpo multipart malformado bloqueado'"

No Nginx, sem um WAF que inspecione o corpo, a alternativa é bloquear multipart/form-data em todas as rotas, exceto as que realmente recebem uploads. O exemplo abaixo usa rotas do WordPress como referência; adapte à sua aplicação.

# Dolutech - Contexto http {}
map $http_content_type $dolutech_is_multipart {
    default 0;
    "~*multipart/form-data" 1;
}
map $uri $dolutech_upload_allowed {
    default 0;
    ~^/wp-admin/async-upload\.php$ 1;
    ~^/wp-admin/media-new\.php$    1;
    ~^/wp-admin/update\.php$       1;
}
map "$dolutech_is_multipart:$dolutech_upload_allowed" $dolutech_block_multipart {
    default 0;
    "1:0"   1;
}

# Contexto server {}
if ($dolutech_block_multipart) {
    return 403;
}

Para aplicações críticas que não podem esperar, considere seguir a recomendação da CERT-EU: retirar temporariamente da exposição pública ou restringir o acesso por VPN ou lista de IPs até aplicar a correção.

4. Detecção: processos suspeitos, falhas de segmentação e web shells (Bash)

Explorações de corrupção de memória costumam deixar rastros: workers que travam durante tentativas malsucedidas e processos de shell nascendo do PHP quando a exploração funciona. Esse último sinal foi destacado por Florian Roth e pela Huntress como o mais provável de aparecer.

#!/usr/bin/env bash
# Dolutech - Caca a sinais de exploracao do PHP2Shell
set -u

echo "== Processos suspeitos filhos de PHP ou do servidor web =="
ps -eo pid=,ppid=,user=,comm= | while read -r pid ppid user comm; do
  pcomm=$(ps -o comm= -p "$ppid" 2>/dev/null)
  case "$pcomm" in
    php-fpm*|php*|lsphp*|apache2|httpd)
      case "$comm" in
        sh|bash|dash|zsh|nc|ncat|netcat|socat|curl|wget|python*|perl|base64|busybox)
          cmd=$(tr '\0' ' ' < "/proc/$pid/cmdline" 2>/dev/null)
          echo "[!] PID $pid ($comm, usuario=$user) filho de $pcomm ($ppid): $cmd" ;;
      esac ;;
  esac
done

echo; echo "== Workers PHP encerrados por falha de segmentacao (72h) =="
journalctl --since "72 hours ago" --no-pager 2>/dev/null |
  grep -Ei 'php.*(SIGSEGV|signal 11|segfault)|segfault.*php' | tail -n 50
grep -hEi 'exited on signal 11|SIGSEGV' /var/log/php*fpm*.log /var/log/php-fpm/*.log 2>/dev/null | tail -n 50
dmesg 2>/dev/null | grep -Ei 'php.*segfault' | tail -n 20

echo; echo "== Arquivos .php criados ou alterados nas ultimas 48h =="
for root in /var/www /srv/www /home/*/public_html; do
  [ -d "$root" ] && find "$root" -type f -name '*.php' -mmin -2880 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' 2>/dev/null
done | sort -r | head -n 200

Para monitoramento contínuo, uma regra de auditd registra toda execução de programas pelo usuário do servidor web. Ela gera ruído em aplicações que chamam binários externos, então ajuste antes de enviar ao SIEM.

# Debian/Ubuntu (www-data). Em RHEL use o usuario apache ou nginx.
WEBUID=$(id -u www-data)
auditctl -a always,exit -F arch=b64 -S execve -F uid="$WEBUID" -k dolutech_php2shell
ausearch -k dolutech_php2shell --start recent -i | tail -n 50

5. Servidores Windows com IIS (PowerShell)

Ambientes Windows com PHP via FastCGI merecem atenção especial, como a CVE-2024-4577 deixou claro. O script abaixo inventaria as instalações registradas no IIS e em diretórios comuns e, com o parâmetro -Apply, aplica a mitigação temporária com backup do php.ini.

# Dolutech - Inventario e mitigacao temporaria PHP2Shell em Windows/IIS
#Requires -RunAsAdministrator
param([switch]$Apply)

$fixed = @{ '8.2'='8.2.35'; '8.3'='8.3.36'; '8.4'='8.4.27'; '8.5'='8.5.12' }
$roots = 'C:\PHP','C:\Program Files\PHP','C:\Program Files (x86)\PHP',
         'C:\tools','C:\xampp\php','C:\laragon\bin\php','C:\wamp64\bin\php'

$paths = @()
foreach ($r in $roots) {
    if (Test-Path $r) {
        $paths += Get-ChildItem -Path $r -Filter 'php-cgi.exe' -Recurse -ErrorAction SilentlyContinue |
                  Select-Object -ExpandProperty FullName
    }
}
Import-Module WebAdministration -ErrorAction SilentlyContinue
$paths += Get-WebConfiguration -PSPath 'MACHINE/WEBROOT/APPHOST' `
          -Filter 'system.webServer/fastCgi/application' -ErrorAction SilentlyContinue |
          ForEach-Object { $_.fullPath }
$paths = $paths | Where-Object { $_ -and (Test-Path $_) } | Sort-Object -Unique

foreach ($exe in $paths) {
    $out = & $exe -v 2>$null | Select-Object -First 1
    if ($out -notmatch '(\d+)\.(\d+)\.(\d+)') { continue }
    $ver = "$($Matches[1]).$($Matches[2]).$($Matches[3])"
    $mm  = "$($Matches[1]).$($Matches[2])"
    if ($fixed.ContainsKey($mm)) {
        $status = if ([version]$ver -ge [version]$fixed[$mm]) { 'OK' } else { 'VULNERAVEL PROVAVEL' }
    } else { $status = 'FORA DE SUPORTE' }
    Write-Host ("{0,-55} {1,-8} {2}" -f $exe, $ver, $status)

    $ini = Join-Path (Split-Path $exe) 'php.ini'
    if ($Apply -and (Test-Path $ini)) {
        Copy-Item $ini "$ini.dolutech.$(Get-Date -Format yyyyMMddHHmm).bak"
        $content = Get-Content $ini
        $pattern = '^\s*;?\s*session\.upload_progress\.enabled\s*='
        if ($content -match $pattern) {
            $content = $content -replace "$pattern.*", 'session.upload_progress.enabled = Off'
        } else {
            $content += 'session.upload_progress.enabled = Off'
        }
        Set-Content -Path $ini -Value $content -Encoding ASCII
        Write-Host "   [+] Mitigacao aplicada em $ini" -ForegroundColor Yellow
    }
}

if ($Apply) {
    Get-ChildItem IIS:\AppPools | ForEach-Object { Restart-WebAppPool -Name $_.Name }
    Write-Host '[*] Application pools reciclados.'
}

6. Aplicando a correção oficial

Assim que o PHP publicar as versões corrigidas:

• Pacotes da distribuição: acompanhe os avisos do Debian, Ubuntu, Red Hat, AlmaLinux e Rocky, que podem publicar com algumas horas de diferença, e aplique com apt-get install --only-upgrade 'php*' ou dnf upgrade 'php*'.
• Repositórios de terceiros (Ondřej Surý, Remi): confirme a versão exata após a atualização com php -v e php-fpm -v.
• Painéis (cPanel EasyApache, Plesk, CloudLinux): atualize os pacotes ea-php, plesk-php ou alt-php e confirme se há backport para ramos legados.
• Contêineres: reconstrua as imagens a partir da nova tag oficial php: e reimplante; imagens antigas em cache continuam vulneráveis.
• Reinicie o PHP-FPM e o servidor web. Um pacote atualizado com o processo antigo em memória não corrige nada.
• Após o patch, rode novamente o script de detecção. Se a exploração começar logo após a publicação, como prevê a Sansec, o intervalo entre o patch e a sua atualização é exatamente a janela de risco.

Conformidade regulatória: NIS2, DORA, GDPR e LGPD

Uma RCE no interpretador que roda sistemas expostos à internet tem consequências que vão além do técnico.

União Europeia

• NIS2 (Diretiva (UE) 2022/2555): o artigo 21 exige medidas de gestão de risco que incluem tratamento e divulgação de vulnerabilidades. Entidades essenciais e importantes precisam demonstrar inventário de ativos e aplicação de correções em prazo adequado ao risco. Em caso de incidente significativo, o artigo 23 impõe alerta precoce em 24 horas, notificação em 72 horas e relatório final em até um mês.
• DORA (Regulamento (UE) 2022/2554): entidades financeiras devem manter gestão de risco de TIC com identificação de vulnerabilidades e políticas de atualização. Um comprometimento por PHP2Shell que afete serviços críticos pode configurar incidente grave de TIC, sujeito a notificação à autoridade competente nos prazos curtos definidos pelas normas técnicas do regulamento.
• GDPR (Regulamento (UE) 2016/679): o artigo 32 exige segurança adequada no tratamento de dados, e manter software com RCE pública e correção disponível dificilmente se sustenta como medida adequada. Violações de dados pessoais devem ser notificadas à autoridade de controle em até 72 horas (artigo 33).

Portugal

O CNCS e o CERT.PT são os pontos de referência nacionais para notificação e coordenação de incidentes. Organizações abrangidas pelo regime jurídico da cibersegurança, incluindo o novo enquadramento que transpõe a NIS2, devem tratar o PHP2Shell como vulnerabilidade de prioridade máxima e documentar as ações de mitigação adotadas.

Brasil

• LGPD (Lei 13.709/2018): o artigo 46 obriga os agentes de tratamento a adotar medidas de segurança aptas a proteger dados pessoais, e o artigo 48 exige comunicação à ANPD e aos titulares em incidentes que possam acarretar risco ou dano relevante.
• Resolução CD/ANPD nº 15/2024: estabelece o prazo de três dias úteis para comunicação de incidentes de segurança à ANPD, contados do conhecimento de que o incidente afetou dados pessoais.

Em todos os casos, recomendamos registrar o inventário, as mitigações temporárias e a data de aplicação do patch. Essa trilha documental é a melhor evidência de diligência perante reguladores e auditores.

Conclusão

O PHP2Shell reúne os ingredientes de um evento de exploração em massa: uma tecnologia onipresente, falhas críticas no núcleo do interpretador, um vazamento antes do embargo e uma grande base instalada em versões que não receberão correção. A boa notícia é que a janela de preparação existe, e quem fizer o dever de casa agora chegará ao momento do patch com inventário pronto, superfície reduzida e monitoramento ativo.

Na Dolutech, nossa recomendação é objetiva: inventarie hoje, aplique a mitigação temporária onde for viável, monitore processos filhos e falhas de segmentação, e atualize assim que o php.net publicar as versões corrigidas. Para ambientes em PHP fora de suporte, este é o momento de transformar a migração adiada em prioridade de negócio.

Continuaremos acompanhando o caso e atualizaremos este artigo do Blog Dolutech com os detalhes técnicos oficiais, as versões confirmadas e os IoCs, assim que forem divulgados.

Referências

• CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP
• PHP.net, Upcoming Critical PHP Security Release (20/10/2026)
• watchTowr, PHP Remote Code Execution FAQ: CVE-2026-109618
• Huntress, Rapid Response: php2shell
• Sansec, Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
• BleepingComputer, PHP warns admins of two critical flaws
• SecurityWeek, PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws
• Manual do PHP, Session Runtime Configuration e Session Upload Progress

Lucas Catão de Moraes

Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.