id: "BATCH-298" title: "Atualização de Segurança PHP2Shell no Lab, Prod, Docker e Composer (REQ-290)" status: "implemented-pending-review" date: "2026-10-21" author: "executor" target_repo: "conn2flow" summary_short: "Mitigação emergencial das vulnerabilidades críticas PHP2Shell (CVE-2026-109618 e CVE-2026-109619). Atualização de pacotes nos servidores SSH (Lab e Prod), rebuild dos containers Docker locais e restrição de versão no composer.json do Core."

BATCH-298 — REQ-290

• Branch Sugerida: feat/req-290 (no repositório conn2flow)

• Requisição: req-290.md

? Live Todo List

• [ ] 1. Diagnóstico Inicial de Versões

  • [ ] Verificar versão local do PHP (php -v)

  • [ ] Verificar versão no Lab via SSH ([REDACTED] php -v)

  • [ ] Verificar versão em Produção via SSH ([REDACTED] php -v)

• [ ] 2. Atualização dos Servidores Remotos (SSH)

  • [ ] Lab: Atualizar pacotes PHP (apt update && apt upgrade ...), reiniciar serviços (systemctl restart php*-fpm apache2) e validar php -v

  • [ ] Prod: Atualizar pacotes PHP, reiniciar PHP-FPM / webserver e confirmar estabilidade de conn2flow.com

• [ ] 3. Atualização do Ambiente Docker Local (dev-environment/docker)

  • [ ] Inspecionar Dockerfile e Dockerfile.php85

  • [ ] Recompilar containers com docker compose build --no-cache

  • [ ] Testar container e validar versão via docker compose exec ... php -v

• [ ] 4. Governança no Core (conn2flow/composer.json)

  • [ ] Inserir restrição segura de versão mínima de PHP no composer.json

  • [ ] Executar suíte de testes unitários (vendor/bin/phpunit) para garantir regressão zero

• [ ] 5. Evidências e Fechamento

  • [ ] Anotar versões finais instaladas em Lab e Prod

  • [ ] Commit explícito das alterações de arquivos (sem git add -A)

Evidências — Diagnóstico (2026-10-21, ~16:20 UTC, executor)

Branch feat/req-290 criada a partir de main (c19151bc).

• php.net confirma os releases de segurança 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 de 21/10/2026.

• Bloqueio upstream: o PPA ondrej ainda não publicou as versões corrigidas (Launchpad respondendo 503 no apt-get update do Lab) e as imagens oficiais do Docker ainda não têm build amd64. Rodar apt upgrade agora só levaria às versões anteriores ao patch, ainda vulneráveis.

• conn2flow.com → HTTP 200, [REDACTED] (a Cloudflare anunciou regras de WAF iniciais para os vetores conhecidos).

• PHP 8.1 (instalado em Lab e Prod): fora de suporte; correção só por backport.

• Composer: ">=8.2.35" não barra 8.3.35 nem 8.5.10 (são numericamente maiores). O gestor/vendor/composer/platform_check.php é versionado: uma restrição correta derrubaria com erro fatal toda instalação ainda sem patch, inclusive as nossas hoje. Decisão de arquitetura pendente.

• Nenhuma alteração feita em Lab, Prod ou containers ativos. A imagem de teste local foi removida.

Evidências — Exposição da origem em Prod (2026-10-21, ~16:40 UTC)

• A origem [REDACTED] responde 200 (nginx) nas portas 80 e 443 com [REDACTED], sem passar pela Cloudflare: o WAF pode ser contornado.

• O painel do Hestia na porta 8083 responde 200 em [REDACTED] e [::]. Roda hestia-php 8.5.9, também vulnerável.

• IPv6 2a02:4780:6e:3d80::1: política INPUT ACCEPT, sem regras; o firewall do Hestia só gerencia IPv4. Os sites só escutam no IPv4; no IPv6 só o 8083 fica exposto.

• Firewall do Hestia: as regras 2 (8083) e 9 (80,443) aceitam [REDACTED]/0. Não há ipsets.

• DNS: os três sites e os subdomínios ia-parceria, dev.[REDACTED] e fsmjd.[REDACTED] são proxied pela Cloudflare. Ficam fora do proxy (DNS-only): server.conn2flow.com, webmail.{conn2flow,[REDACTED],[REDACTED]}.com, webmail.server.conn2flow.com e mail.*.

• A mitigação no firewall foi autorizada pelo humano, mas o comando de escrita remota foi negado pela política de permissões do agente. Nada foi alterado em Prod.

Evidências — Mitigação de rede em Prod (2026-10-21, 13:31 hora do servidor, aplicada pelo humano)

O humano executou como root os comandos preparados pelo executor; o agente só verificou, em modo leitura.

• Backup em [REDACTED] (iptables-before.rules, firewall-data-before/).

• ipset cloudflare criado a partir de [REDACTED] (15 faixas, AUTOUPDATE='yes').

• Regra 9: 80,443 só de ipset:cloudflare. Regra 11: 80,443 do IP do operador [REDACTED]. Regra 2: 8083 só de [REDACTED].

• IPv6: ip6tables -A INPUT -p tcp --dport 8083 -j DROP (a política continua ACCEPT; a regra não sobrevive a reboot).

• Verificação pela Cloudflare: conn2flow.com 200, [REDACTED].com 200, [REDACTED].com 200, ia-parceria 200, dev.[REDACTED] 302, fsmjd.[REDACTED] 200.

• Efeito colateral esperado: webmail.* e server.conn2flow.com (DNS-only) passam a responder só para o IP do operador. IMAP, SMTP e POP não foram afetados.

• Pendências: ligar o proxy da Cloudflare em webmail.*; atualizar o PHP (sury) e o hestia-php quando os pacotes corrigidos saírem; reconstruir o Docker quando as imagens amd64 8.3.36/8.5.12 forem publicadas; decidir a restrição no composer.

Evidências — Lançamentos parciais e tentativa no Lab (2026-10-21, ~16:40 UTC)

• Verificador (check-php2shell.sh): o PPA ondrej publicou 8.2.35 e 8.3.36. Continuam pendentes 8.4 (em 8.4.26), 8.5 (em 8.5.11), hestia-php (em 8.5.9) e as imagens Docker amd64.

• Prod por PHP: 8.5 atende conn2flow.com, [REDACTED].com, dev.[REDACTED], [REDACTED].com, ia-parceria e server; 8.2 atende fsmjd.[REDACTED]; 8.3 (pool www) atende o webmail.

• Lab, apt-get install --only-upgrade dos 44 pacotes php8.2/8.3 com status ii: falhou com 503 do Launchpad em 16 .deb. O apt abortou antes de instalar, então o Lab segue em 8.2.33/8.3.33 com fpm ativo e sem erros no journal.

• Certificados de origem: válidos (ssl_verify=0) em todos os nomes, menos dev.[REDACTED].com. O webmail proxied entrou em loop de 301 com o SSL Flexible; a orientação é Full (strict) nas zonas conn2flow e [REDACTED] e Full na [REDACTED].

• O agendamento do verificador foi negado pela política do agente (persistência); o loop fica a cargo do humano (/loop).

Evidências — Docker local corrigido (2026-10-21, ~17:15 UTC)

• As imagens oficiais amd64 php:8.3.36-apache e php:8.5.12-apache foram publicadas. Fixei as tags em dev-environment/docker/Dockerfile e Dockerfile.php85, para que um cache antigo nunca volte a uma versão vulnerável.

• docker compose build --no-cache --pull app (via WSL) nos três compose: docker-compose.yml → PHP 8.3.36; docker-compose.php85-mysql.yml e docker-compose.php85-pgsql.yml → PHP 8.5.12. Os três geram a mesma imagem docker-app e o último build vence; por isso reconstruí o principal por último (8.3.36).

• Varredura nos 8 repositórios da workspace (arquivos versionados): só o conn2flow usa imagem PHP. [REDACTED] e nexus são Python, o mcp-hub é Node; o gestor/vendor/cakephp/chronos/Dockerfile é de terceiros e não entra no ambiente. O phpmyadmin/phpmyadmin:latest não está fixado e não estava em execução.

• Vigia no Lab (php2shell-watch.timer) instalado pelo humano. A primeira versão tinha um bug de locale: o apt-cache em pt-BR escreve "Candidato:". Corrigido com LC_ALL=C; falta o humano reinstalar o script.

Evidências — Lab no PHP 8.2.35 (2026-10-21, ~18:15 UTC)

• O vigia do Lab instalou 8.2.35 (cli e fpm, serviço ativo, journal limpo). O 8.3.36 segue pendente por 503 do Launchpad.

• Compatibilidade: gestor/vendor/composer/platform_check.php exige >= 8.2.0. php8.2 -l no gestor instalado no Lab, sem vendor/: 0 erros em 7.559 arquivos (v3.1 685, [REDACTED] 4.577, [REDACTED] 651, [REDACTED] 1.646).

• v-change-sys-php 8.2 trocou o PHP padrão, mas regenera os domínios antes do update-alternatives. Foi preciso rodar v-rebuild-web-domains em cada usuário para levar os pools para /etc/php/8.2/fpm/pool.d/ (11 sockets 8.2; no 8.5 ficou só o dummy).

• Regressão causada pela regeneração e corrigida: 6 sites com o template nginx conn2flow (listen %ip%:port) entraram em loop de 301. O Caddy chega por host.docker.internal ([REDACTED]:8443) e caía no default_server. Os arquivos tinham sido ajustados à mão antes (havia backup .orig-ip na v3.1). Correção duradoura: v-change-web-domain-tpl ... conn2flow-req092 (idêntico, só com listen %web_ssl_port%) em [REDACTED], [REDACTED], [REDACTED].local, [REDACTED].local, [REDACTED] e [REDACTED]; nginx -t ok.

• Resultado pelo Caddy: 10 sites com 200 e página completa, nenhum fatal. [REDACTED] segue em 301 por SSL='no' (situação anterior, sem relação com a troca).

• [REDACTED] (sugerido no fórum do Hestia, post de eris em 21/10/2026) já publica para jammy: 8.2.35, 8.3.36, 8.4.27 e 8.5.12. O Launchpad (PPA) está atrasado e devolvendo 503.

Evidências — Lab definitivo pelo [REDACTED] (2026-10-21, ~18:40 UTC)

• Fonte do apt: ondrej-ubuntu-php-jammy.list renomeada para .disabled; criada php-sury.list (deb [signed-by=/usr/share/keyrings/[REDACTED]-php.gpg] [REDACTED] jammy main), chave RSA 3072 de 2019.

• apt-get install --only-upgrade de 62 pacotes php8.3/8.4/8.5 com status ii: rc=0, 50 Setting up, sem E:/W:. Vigia pausado durante a atualização e reativado depois.

• php-fpm -v: 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, todos active.

• v-change-sys-php 8.5 + v-rebuild-web-domains em cada usuário: 11 sockets 8.5, nginx -t ok, CLI PHP 8.5.12. Os 10 sites conn2flow responderam 200 pelo Caddy, sem fatal; o template conn2flow-req092 segurou a regeneração.

Evidências — Produção corrigida (2026-10-21, ~19:00 UTC, aplicado pelo humano)

• O humano trocou a fonte para o [REDACTED] e atualizou os pacotes php8.2 a 8.5 com status ii. php-fpm -v: 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, todos active; CLI PHP 8.5.12. O needrestart adiou só serviços do sistema (dbus, logind, networkd-dispatcher, unattended-upgrades, user@0).

• Pela Cloudflare: conn2flow.com 200 (263 KB), www 200, ia-parceria 200, [REDACTED].com 200, dev.[REDACTED] 200, [REDACTED].com 200, fsmjd.[REDACTED] 200 (7,4 s: primeiro acesso com o pool ondemand frio). Nenhum fatal.

• Webmail direto na origem (IP do operador liberado): os três webmail.* respondem 200 com Roundcube.

• Pools: 8.5 atende conn2flow, dev.[REDACTED], ia-parceria, server, [REDACTED] e [REDACTED]; 8.2 atende fsmjd; 8.3 atende o www (webmail). Nenhum fatal nos logs de erro dos últimos 15 minutos.

• Pendências: hestia-php (painel, 8.5.9, aguardando o Hestia; a 8083 segue restrita); remover o PHP 8.1 (sem correção oficial); SSL Full/Full (strict) na Cloudflare para o proxy do webmail; ip6tables da 8083 não persiste após reboot; decisão sobre a restrição de PHP no composer.json.

• E-mail do cron durante o upgrade (transitório): undefined symbol em mysqlnd/mysqli/mbstring/dom e o fatal mysqli_report() em cron.php. O cron das 15:32:01 rodou entre a troca do php8.5-mysql (15:31:57) e a do php8.5-common (15:32:10). Depois disso: CLI 8.5.12 com mysqli, mbstring e dom carregados, 0 avisos de startup; o cron das 15:34 às 15:36 roda "Concluido" com tarefas [sucesso]. As extensões PECL (apcu, redis, imagick, igbinary, imap, pspell) têm versão própria, o que é normal.

Handoff para o Macro-Arquiteto (topologia dupla)

• Projeto: conn2flow (Core) · Raiz: [REDACTED] · REQ-290 / BATCH-298 · branch feat/req-290, sem push.

• Critérios de aceite:

  1. Lab atualizado: ✅ 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12; 10 sites com 200.

  2. Prod atualizado: ✅ mesmas versões; 7 sites e 3 webmails respondendo; cron saudável.

  3. Docker local: ✅ 8.3.36 / 8.5.12, com tags fixadas.

  4. Composer: ⚠️ não aplicado. ">=8.2.35" não barra 8.3.35 nem 8.5.10, e o platform_check.php versionado transforma qualquer restrição em fatal nas instalações sem patch. Pede decisão do Arquiteto: restrição por ramo (~8.2.35 || ~8.3.36 || ~8.4.27 || >=8.5.12) ou aviso no painel (recomendado). A suíte phpunit não foi rodada porque não houve mudança de código PHP.

  5. Evidências: ✅ neste arquivo.

• Fora do escopo original, feito por necessidade: firewall de Prod (80/443 só Cloudflare, 8083 só para o IP do operador, DROP da 8083 em IPv6) aplicado pelo humano; fonte do apt trocada para [REDACTED] no Lab e em Prod; template nginx conn2flow-req092 em 6 domínios do Lab.

• Pendências: hestia-php 8.5.9 (aguardando o Hestia; 8083 restrita); remover o PHP 8.1 de Lab e Prod; SSL Full/Full (strict) na Cloudflare para o webmail; persistir o ip6tables; decisão sobre o composer; marcar o VALIDATION-CHECKLIST na homologação.

• Autonomia: escritas em Prod e persistência no Lab foram barradas pelo classificador do agente e executadas pelo humano. O agente não fez deploy nem alteração autônoma em produção.