Atualize e audite seus sistemas hoje

Baixe o script e leia antes de rodar

Regra de ouro: nunca rode script da internet sem olhar o que ele faz. Este tem cerca de 650 linhas, comentadas.

curl -fsSLO https://raw.githubusercontent.com/inematds/auditoria-seguranca/main/audita.sh
less audita.sh            # leia
chmod +x audita.sh

Ou clone o repositório: git clone https://github.com/inematds/auditoria-seguranca.

Rode na máquina

Sem sudo ele audita o seu usuário (e os containers, se você está no grupo docker). Com sudo ele enxerga também as pastas de outros usuários. A busca no disco leva até 3 minutos; --rapido pula essa parte.

./audita.sh                 # completo
sudo ./audita.sh            # inclui containers Docker e outros usuários
./audita.sh --rapido        # sem procurar venvs, Node, Deno, Bun e JDKs no disco
./audita.sh --sem-docker    # não entra nos containers
./audita.sh --comandos      # mostra os comandos de correção (não executa nenhum)
./audita.sh --go            # também testa o Go de verdade (veja abaixo)
./audita.sh --raiz /opt     # busca no disco só nessa pasta (repita --raiz para várias)

Dois testes não são de conexão, e o script avisa isso na linha. Java: ele confere se o arquivo de confiança do Java (cacerts) ainda tem as duas raízes, porque testar a conexão exigiria compilar código Java. Go: o teste real compila um programa pequeno numa pasta temporária (cerca de 100 MB, apagada no fim). Como isso grava no disco, só roda com --go.

Com sudo, o Node instalado pelo nvm do seu usuário não fica no caminho padrão; ele ainda é achado pela busca no disco (não use --rapido nesse caso).

Leia o resultado: cinco estados

== meuservidor · Ubuntu 24.04.3 LTS · 23/10/2026 02:36 · audita.sh 1.1.2
-- versões
ca-certificates 20260816ubuntu0.24.04.1
-- conexão real (G3 = cadeia emSign ECC Root CA - G3 · AAA = cadeia cruzada AAA Certificate Services)
protegido  curl                               G3
protegido  curl                               AAA
EXPOSTO    node v24.13.0 /usr/bin/node        G3
protegido  node v24.13.0 /usr/bin/node        AAA
          versão: ATUALIZE para 24.22.1+
EXPOSTO    deno 2.7.14 ~/.deno/bin/deno       G3
EXPOSTO    venv ~/projetos/app/.venv           G3
protegido  venv ~/projetos/app/.venv           AAA
-- Java: lista de confiança (cacerts) — conferida pelo keytool, sem conexão
EXPOSTO    java /etc/ssl/certs/java/cacerts   G3   (lista do keystore, não conexão)
-- containers Docker em execução (teste de dentro de cada um)
   [n8n] n8nio/n8n:2.4.8
   EXPOSTO    node v20.19.0                      G3
   [painel-db] adminer:latest
   EXPOSTO    php 8.4.21                         PHP  PHP2Shell: atualize para 8.4.27+
-- processos a reiniciar (não reinicie no meio de job, upload ou live; escolha a hora)
REINICIE   pid 3361     meubot.service (sistema)           /usr/bin/node dist/index.js
           o binário foi atualizado depois que o processo começou
-- resumo meuservidor: 7 EXPOSTO · 0 SEM TESTE · 0 VERIFIQUE · 1 REINICIE
-- o que corrigir, por tipo (conta itens; o resumo acima conta linhas, 2 por item: G3 e AAA)
     1  Node
        ex.: /usr/bin/node (v24.13.0)
        → sudo apt update && sudo apt install --only-upgrade nodejs
     1  Deno
        ex.: ~/.deno/bin/deno (2.7.14)
        → ~/.deno/bin/deno upgrade
     1  containers de versão fixada (grupo C: subir a versão)
        ex.: n8n (n8nio/n8n:2.4.8)
        → versão fixada: a tag pode ter sido republicada com a base corrigida — salve o digest atual, puxe a mesma tag e recrie; se o digest não mudou ou seguir EXPOSTO, suba a versão
     1  processos a reiniciar (fora de job, upload ou live)
        ex.: meubot.service (sistema)
        → sudo systemctl restart meubot.service

Trecho de exemplo (a saída real tem mais linhas; o script escreve em português). G3 e AAA são os dois "caminhos de confiança" testados: cada certificado de site é assinado por um intermediário, que é assinado por uma raiz que o seu programa confia.

• EXPOSTO: conectou (ou, no Java, a lista ainda tem as raízes; no PHP, a versão é vulnerável). Corrija essa camada (seção Atualizar).
• protegido: recusou por erro de certificado.
• SEM TESTE: o teste não terminou ou não prova nada. Rede, DNS, timeout, container sem shell ou sem ferramenta, saída cortada, SSH que falhou, busca no disco interrompida, programa que não é seguro executar, ou o wget do busybox com recusa ambígua (essa só conta como protegida se a lista de certificados do sistema não tem a raiz daquela cadeia). Nunca conta como protegido. Repita ou teste de outro jeito antes de concluir.
• VERIFIQUE: PHP em versão de teste (RC, beta, dev: número maior não prova correção) ou abaixo da versão corrigida, mas com número da distribuição (pode ter a correção por backport). No Debian/Ubuntu o script já procura o CVE no changelog local do pacote; se não achar, confira com apt changelog <pacote> | grep CVE-2026-109618. Conferido e corrigido? Rode com --php-ok e o VERIFIQUE deixa de segurar a saída.
• REINICIE: processo que começou antes da correção e ainda usa o programa ou a lista antiga. Veja quem reiniciar.

No fim vem o bloco o que corrigir, por tipo: quantos itens de cada tipo, um exemplo e o comando sugerido. O resumo conta linhas (cada ferramenta aparece duas vezes, G3 e AAA); o bloco conta itens. Com --comandos sai a lista completa, um comando por item, para você revisar e rodar um por um. O script nunca executa a correção.

No fim vem também o bloco escopo desta rodada: o que ficou de fora (--rapido, --sem-docker, --raiz, --php-ok, Go sem --go, e com qual usuário rodou).

Código de saída: 0 as verificações feitas passaram, dentro do escopo impresso; 1 há EXPOSTO; 2 há SEM TESTE; 3 nada conecta, mas falta reiniciar processos ou conferir o PHP. Saída 0 não quer dizer que a máquina inteira está segura. Em monitoramento, trate qualquer saída diferente de 0 como alerta e não libere deploy automático só pela saída 0.

Audite vários servidores por SSH

O script vai pelo próprio SSH e roda lá, sem copiar nada para o servidor. Use acesso por chave.

./audita.sh --ssh root@servidor1 --ssh deploy@servidor2

# ou uma lista (um destino por linha; não versione esse arquivo)
./audita.sh --hosts servidores.txt

# chave SSH específica (vale para todos os destinos)
./audita.sh --chave ~/.ssh/minha_chave --ssh root@servidor1

Se o SSH não conecta ou cai no meio (tempo esgotado, bash ausente lá), a linha diz SEM TESTE com o código e a saída não é 0: um servidor que não respondeu nunca passa como limpo. Exemplo de servidores.txt: uma linha root@203.0.113.10, outra deploy@vps2 # loja. Lá, o script roda com o usuário do SSH: para ver os containers e as pastas de outros usuários, entre como root (ou com um usuário do grupo docker).

Corrija, reinicie e rode de novo

A auditoria só termina quando o resumo mostra 0 EXPOSTO · 0 SEM TESTE · 0 VERIFIQUE · 0 REINICIE (saída 0) em todas as máquinas, numa passada completa (sem --rapido, e com o bloco de escopo sem nada importante de fora). Processo que já estava rodando guarda a lista antiga na memória: atualizar sem reiniciar não resolve.

Sistema (ca-certificates)

# Ubuntu / Debian
sudo apt update && sudo apt install --only-upgrade ca-certificates
dpkg-query -W ca-certificates          # confira a versão
# Alpine
apk upgrade --no-cache ca-certificates
# Fedora / RHEL
sudo dnf upgrade ca-certificates

Deixe a atualização automática ligada (unattended-upgrades no Ubuntu/Debian). No nosso caso foi ela que corrigiu o sistema sozinha.

Python: o certifi de cada ambiente

O requests e muitos pacotes usam o certifi, não a lista do sistema. Cada venv tem o seu. O audita.sh lista os desatualizados.

/caminho/do/venv/bin/python -m pip install -U certifi pip
python3 -c "import certifi; print(certifi.__version__, certifi.where())"  # 2026.10.19 ou mais
# ferramentas instaladas com pipx / uv tool
pipx upgrade-all        # ou: pipx runpip <app> install -U certifi
uv self update          # uv 0.13.5 ou mais
uv tool upgrade --all
# ambientes conda (miniconda/anaconda)
conda update -n <ambiente> certifi

Atenção ao Python "do sistema": se aparecer EXPOSTO no modo certifi, existe um certifi instalado com pip --user na sua pasta (~/.local/lib/python3.X/). O caminho mostrado pelo comando acima diz qual é. No Ubuntu 24.04 e no Debian 12+ o pip recusa mexer ali ("externally-managed-environment"); como a mudança fica só na sua pasta de usuário, use:

python3 -m pip install --user --break-system-packages -U certifi

O certifi do pacote do sistema (/usr/lib/python3/dist-packages) não precisa disso: no Debian/Ubuntu ele aponta para a lista do ca-certificates.

Venv sem pip (criado pelo uv): o comando -m pip falha. Use o uv apontando para o Python do venv:

uv pip install --python /caminho/do/venv/bin/python -U certifi

Node: troque de versão (Node 20 não tem correção)

O Node traz a lista de certificados dentro do próprio programa. Atualizar o sistema não muda nada para ele.

# com nvm
nvm install 22 && nvm alias default 22     # 22.23.4 ou mais
# com o repositório NodeSource (apt): ele é separado por versão.
# Se está no 20, troque o repositório para o 22 antes de instalar:
curl -fsSLo nodesource_setup.sh https://deb.nodesource.com/setup_22.x
less nodesource_setup.sh                  # leia
sudo bash nodesource_setup.sh && sudo apt install -y nodejs
# já está no 22 ou 24? basta atualizar
sudo apt update && sudo apt install --only-upgrade nodejs
node -v

Paliativo para quem não consegue trocar hoje (testado por nós): mandar o Node usar a lista do sistema já atualizada. Só funciona se o ca-certificates estiver corrigido. --use-system-ca não serve: ele soma as duas listas e continuou EXPOSTO no nosso teste.

export NODE_OPTIONS=--use-openssl-ca   # no serviço/ambiente do app; depois reinicie

Node baixado do nvm ou do nodejs.org pode não achar a lista do sistema sozinho: se o teste der erro em tudo, acrescente SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt e confirme com o audita.sh. NODE_OPTIONS é a variável de ambiente que passa opções para todo Node iniciado ali (no systemd: Environment=NODE_OPTIONS=--use-openssl-ca; no Docker: environment: do compose).

Procure também Node embutido: o Playwright, agentes de IA e apps trazem um Node próprio. O audita.sh acha esses binários no disco; atualize a ferramenta que os trouxe. No caso do Playwright dentro de um venv Python, o Node fica em …/site-packages/playwright/driver/node: atualize o pacote (pip install -U playwright; no npm, npm i playwright@latest) ou use o paliativo NODE_OPTIONS=--use-openssl-ca no serviço que o usa.

Go: atualize e recompile

Instale Go 1.27.3 ou 1.26.10 e gere o binário de novo (go build). Programas Go de terceiros: atualize para a versão que eles lançarem depois de 21/10.

O que vimos no nosso teste, no Linux: um programa feito com Go 1.26.3 recusou as duas cadeias com a lista do sistema corrigida e conectou quando apontamos para uma lista antiga (SSL_CERT_FILE). Ou seja, no Linux o Go segue a lista do sistema, ou a do container onde roda. Corrigir o ca-certificates já protege boa parte dos programas Go; quem embute a própria lista (pacote x509roots/fallback) ou roda em container com imagem antiga continua exposto. Por isso recompile mesmo assim. Para o teste real: ./audita.sh --go.

Java: o arquivo cacerts fica para trás

O Java não lê a lista do sistema direto: ele usa um arquivo próprio, o cacerts. No Debian/Ubuntu esse arquivo é gerado a partir do ca-certificates, mas pode não ser refeito na atualização. No nosso caso, o sistema já estava corrigido e o cacerts do OpenJDK 8 ainda era de 2025, com as duas raízes dentro.

# onde está o cacerts do Java que você usa
readlink -f $(dirname $(readlink -f $(which java)))/../lib/security/cacerts
ls /usr/lib/jvm/                        # outros JDKs instalados
# ainda tem as raízes?
keytool -list -keystore /etc/ssl/certs/java/cacerts -storepass changeit | grep -qiE "emsign_ecc_root_ca_-_g3|comodo_aaa" && echo EXPOSTO || echo limpo
# Debian/Ubuntu: guarde uma cópia e tire as duas raízes do cacerts
sudo cp -a /etc/ssl/certs/java/cacerts /etc/ssl/certs/java/cacerts.bak
sudo keytool -delete -alias debian:emsign_ecc_root_ca_-_g3.pem -keystore /etc/ssl/certs/java/cacerts -storepass changeit
sudo keytool -delete -alias debian:comodo_aaa_services_root.pem -keystore /etc/ssl/certs/java/cacerts -storepass changeit

JDK com cacerts próprio (baixado à parte, dentro de uma IDE, num /opt): atualize o JDK. changeit é a senha padrão do arquivo, pública; ela só protege contra gravação acidental. Depois, reinicie os programas Java.

Deno e Bun: a lista vem dentro do programa

Como o Node, os dois trazem a lista embutida. No nosso teste, Deno 2.7.12 e Bun 1.3.13 conectaram; depois de atualizar, Deno 2.9.8 e Bun 1.4.4 recusaram as duas cadeias.

deno upgrade
bun upgrade
# teste de uma linha (erro de certificado = protegido)
deno eval "await fetch('https://dv-g3b-emudhra.we-have-a-problem.com/')"
bun -e "await fetch('https://dv-g3b-emudhra.we-have-a-problem.com/')"

Os dois ficam na pasta do usuário (~/.deno, ~/.bun): rode a atualização com o usuário dono, não com sudo.

Docker: cada container é uma máquina

O container não usa o ca-certificates do servidor. Imagem antiga = lista antiga. A correção depende de como a imagem chegou aí, e o audita.sh já separa os containers expostos nesses grupos (pelo docker inspect, sem mexer em nada).

Container sem curl, wget, Node ou Python (ex.: postgres:16 Debian) aparece como SEM TESTE "nenhuma ferramenta de teste" (conta como teste que não rodou, e a saída não é 0): o script não tem como testar a conexão. Confira a lista pelo pacote (docker exec <c> dpkg-query -W ca-certificates ou apk list -I ca-certificates-bundle) e compare com a tabela de versões.

Grupo A: puxe e recrie

docker compose up -d --pull always redis      # um serviço; repita para os outros
docker compose pull && docker compose up -d   # todos de uma vez (veja o aviso sobre bancos abaixo)
# prova: o pacote da lista dentro do container (Alpine)
docker compose exec redis apk list -I ca-certificates-bundle   # 20261020-r0 ou mais

Testando à mão com o wget do busybox (Alpine), a recusa aparece como ssl_client: SSL_connect ou Connection reset by peer, que parece erro de rede. Para ter certeza, teste um site bom com o mesmo wget (wget -O /dev/null https://www.google.com/): se esse abre, a falha do site de teste foi de certificado. O audita.sh já faz essa conferência.

• Container sem compose (criado com docker run): salve a receita antes, docker inspect redis > redis.inspect.json, e olhe .Mounts. Sem volume, os dados morrem com o container: no Redis, redis-cli save e docker cp redis:/data/dump.rdb . antes; depois suba o novo com as mesmas portas e variáveis e devolva o arquivo.
• Imagem nova já no disco, container antigo rodando: acontece quando outro projeto puxou a mesma tag. Não precisa baixar nada, só recriar (docker compose up -d <serviço>). O audita.sh mostra esses como "só recriar".
• "latest" ainda antiga: o fornecedor pode não ter publicado a imagem corrigida. No nosso caso, uma imagem :main de 16/10 continuou EXPOSTA depois do pull. Aí use a camada por cima (abaixo) até sair a oficial.

Grupo B: a camada por cima da imagem antiga

Reconstruir com docker compose build --pull baixa a base nova e todas as dependências sem trava de versão. No nosso caso, um app em Node subiu plugins novos e parou de funcionar. A técnica que funcionou: manter a imagem que já roda e só trocar a lista e o Node por cima.

# 1) guarde a imagem atual com outro nome (é o seu caminho de volta)
docker tag meuapp:latest meuapp:pre-emudhra

# 2) Dockerfile.emudhra
FROM meuapp:pre-emudhra
USER root                                                                       # instalar exige root
COPY --from=node:22-bookworm-slim /usr/local/bin/node /usr/local/bin/node   # só se a imagem tem Node 22; mesma versão principal e mesma distro da base
RUN apt-get update && apt-get install -y --only-upgrade ca-certificates && rm -rf /var/lib/apt/lists/*
# Alpine: RUN apk add -u ca-certificates ca-certificates-bundle
RUN python3 -m pip install -U certifi                                           # se o app tem Python com pip próprio
USER app                                                                        # volte ao usuário original (veja: docker inspect -f '{{.Config.User}}' meuapp:pre-emudhra)

# 3) construa por cima e recrie
docker build -f Dockerfile.emudhra -t meuapp:latest .
docker compose up -d meuapp
# deu errado? volte: docker tag meuapp:pre-emudhra meuapp:latest && docker compose up -d meuapp

• O Node copiado tem que ter a mesma versão principal do que já está na imagem (22 por 22): módulos nativos (.node) feitos para o Node 20 não carregam no 22. Imagem em Node 20 não tem como ser corrigida assim; ela precisa ser reconstruída com base 22.
• Se o pip recusar com externally-managed-environment, o Python é o do sistema da imagem (apt): o ca-certificates atualizado já cobre esse Python. Tire a linha do pip; não use || true, que esconde o erro.
• O node:22-… do COPY tem que ser da mesma família da base (bookworm com Debian 12, alpine com Alpine), senão o binário não roda.
• App que sobe com uv run: o uv ressincroniza o venv pelo uv.lock e desfaz o certifi novo. Suba o certifi no lock, ou troque só o arquivo cacert.pem do certifi travado pelo da lista nova.
• Tem um nginx na frente (proxy)? Depois de recriar o app, reinicie o nginx também: ele guarda o endereço interno antigo e passa a responder 502.
• docker-compose antigo (1.29) com KeyError: 'ContainerConfig': docker-compose rm -f -s <serviço> antes do up.
• Com calma, depois: troque a base node:20 por node:22 (ou 24) no Dockerfile, trave as versões das dependências e reconstrua de verdade (docker compose build --pull).

Grupo C: versão fixada (e o Supabase local)

Suba a versão no compose ou na configuração para uma lançada depois de 21/10/2026 e teste de novo. Se o fornecedor ainda não reconstruiu a imagem, não há o que puxar: a espera é por ele.

Supabase local (o da CLI supabase start) é o caso típico: a CLI fixa cada imagem. O caminho é este, nesta ordem:

# 1) backup do banco (com tudo rodando)
docker exec supabase_db_<projeto> pg_dumpall -U postgres > supabase-backup.sql
# 2) CLI nova + parar e subir (na pasta do projeto; sem --no-backup, que apagaria os dados)
npx -y supabase@latest stop && npx -y supabase@latest start
# 3) teste de novo
./audita.sh                       # completo: o --rapido não acha venvs nem quem reiniciar

• Nunca remova os containers do Supabase à mão (docker rm): use a CLI.
• No nosso teste, a CLI nova trouxe imagens novas, mas 10 de 12 containers continuaram EXPOSTOS: só algumas imagens já vinham corrigidas. Enquanto o fornecedor não reconstruir, não há o que fazer além de esperar e testar de novo.
• Não troque a imagem oficial por uma camada local com a mesma tag: o próximo supabase start descarta a sua.
• O start pode subir mais serviços do que antes (no nosso caso, de 4 para 12 containers). Confira a memória da máquina.
• Risco: com tudo só em localhost, a exposição é baixa. Quem faz conexão HTTPS de saída são poucos serviços (autenticação, painel, logs).

n8n: backup, depois atualize

O n8n roda em Node. Versão antiga = Node antigo dentro do container.

# 1) ache o nome do volume (o compose costuma pôr o nome da pasta na frente)
docker volume ls | grep n8n                 # ex.: meuprojeto_n8n_data
# 2) pare o n8n e faça o backup (com ele parado o banco não sai pela metade)
docker compose stop n8n
docker run --rm -v meuprojeto_n8n_data:/data -v "$PWD":/bk alpine tar czf /bk/n8n-backup.tgz -C /data .
# 3) se o compose fixa a versão (image: n8nio/n8n:2.4.8), troque pela atual antes:
#    image: n8nio/n8n:2.44.6   (ou mais nova; confira as notas de versão)
# 4) atualize
docker compose pull n8n && docker compose up -d n8n
docker compose exec n8n node -v                     # confirme o Node novo

Puxar a mesma tag pode trazer uma imagem republicada. Confira se o digest mudou (docker image inspect -f '{{.RepoDigests}}' n8nio/n8n:2.4.8, antes e depois): se não mudou, subir a versão é o caminho.

Outros jeitos de guardar os dados: se o n8n usa uma pasta montada (ex.: ./n8n_data ou ~/.n8n), copie a pasta com ele parado; se usa Postgres, faça o pg_dump do banco. Em todos os casos guarde junto a chave de criptografia (N8N_ENCRYPTION_KEY ou o arquivo config da pasta do n8n): sem ela as credenciais salvas não voltam.

Depois de atualizar, olhe o log (docker compose logs n8n). Saltos grandes de versão podem trazer avisos novos, como o do executor de Python do nó Code.

Windows, macOS, celular e apps

• Windows: Windows Update (correção da Microsoft de 20/10).
• macOS / iPhone: atualização do sistema (Apple, 22/10).
• Navegadores: reinicie o navegador para aplicar; Firefox 158.0.1 ou mais.
• Apps Electron (VS Code, Slack, Discord e outros): atualize cada app. Quem desenvolve: Electron 44.9.1 / 43.8.1 / 42.11.16.
• Rust: cargo update -p rustls-webpki -p webpki-roots e recompile.

Reinicie os serviços (e ache quem reiniciar)

Programa que já está rodando segurou a lista antiga na memória: atualizar sem reiniciar não resolve. Bots, APIs, workers, agentes, o n8n e qualquer servidor Python com venv (uvicorn, gunicorn) precisam reiniciar depois da correção. O audita.sh lista na seção processos a reiniciar quem ainda roda com o programa antigo (o Node foi trocado depois que o processo começou) ou começou antes do certifi novo do venv dele.

# à mão: processos Python de venv e Node, com o tempo de execução em segundos
ps -eo pid,etimes,args | grep -E "venv/bin/python|/node " | grep -v grep
# serviços que estão rodando
systemctl list-units --type=service --state=running
systemctl --user list-units --type=service --state=running
pm2 list
# reinicie
sudo systemctl restart <servico>     # serviços do sistema
systemctl --user restart <servico>   # serviços do seu usuário
pm2 restart all                       # apps Node gerenciados pelo pm2 (pm2 update reinicia o próprio pm2)
docker compose up -d                  # containers: recria com a imagem nova

Na lista do script, cada processo vem com o que reiniciar: (sistema) é sudo systemctl restart, (--user) é systemctl --user restart, e processo avulso é algo que você abriu no terminal, no tmux ou no pm2: reinicie só aquele programa.

Atenção: docker compose restart só reinicia o mesmo container, com a imagem velha. Depois de pull ou build, o certo é docker compose up -d.

E rode o audita.sh de novo.

Teste: o verificador da OpenAI

A OpenAI publicou o php2shell-checker (licença Apache 2.0). Ele lê a versão que o site anuncia nos cabeçalhos; não manda ataque. Precisa de git e Node instalados no seu computador (não no servidor).

git clone https://github.com/openai/php2shell-checker && cd php2shell-checker
node phpcheck.js "https://seusite.com.br"
# OK (0) · POTENTIALLY VULNERABLE (1) · UNKNOWN (3)

Ou peça ao seu agente (Claude Code, Codex): "rode o php2shell-checker só contra o meu site e me explique o resultado". UNKNOWN não é sinal verde: o site esconde a versão; confira no painel ou no servidor.

No servidor: veja a versão de verdade

php -v
php-fpm8.3 -v                       # ajuste o número da versão
apt changelog php8.3-fpm | head -30  # Debian/Ubuntu: procure CVE-2026-109618
# PHP dentro de containers (painéis, WordPress, adminer, phpMyAdmin)
for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec $c php -v 2>/dev/null | head -1)"; done

Não esqueça os containers: imagem com PHP antigo é tão vulnerável quanto o servidor, e painéis de banco costumam ficar expostos numa porta. O audita.sh já mostra a versão do PHP de cada container e do servidor e compara com as corrigidas (EXPOSTO abaixo delas; VERIFIQUE quando o número é de pacote da distribuição). Para corrigir: puxe a imagem nova e recrie o container (grupo A da seção Docker).

Corrija: atualize e reinicie todos os processos

Antes: backup do site (sudo tar czf site-$(date +%F).tgz /var/www) e do banco (mysqldump --all-databases > wp-$(date +%F).sql), e anote se a home e o /wp-admin abrem. Depois: confira os dois de novo e o php -v. Veja a chamada antes e depois de atualizar.

• Versões corrigidas: 8.5.12, 8.4.27, 8.3.36, 8.2.35 (ou o pacote corrigido da sua distribuição).
• PHP 8.1 e anteriores não recebem mais atualização do projeto PHP. Algumas distribuições e fornecedores LTS têm a correção: pergunte a eles ou suba para uma versão suportada. Pela gravidade, o time do PHP publicou correções mínimas em código-fonte para 7.4, 8.0 e 8.1, para quem compila.

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php   # veja o que vai mudar
sudo apt install --only-upgrade $(dpkg -l 'php*' | awk '/^ii/{print $2}')   # só os pacotes PHP instalados
sudo systemctl restart php8.3-fpm    # ou apache2, se usa mod_php

Usa o repositório PPA ondrej/php (comum para ter várias versões)? Ele também precisa estar com a versão corrigida; confira com php -v depois. mod_php é o PHP rodando dentro do Apache; PHP-FPM é o PHP como serviço separado, usado com nginx ou Apache.

Não dá para atualizar agora? Reduza a exposição

O próprio time do PHP avisa: estas medidas reduzem caminhos de ataque conhecidos, não tornam a instalação segura. Só a atualização resolve. Aplique no php.ini, no pool do FPM ou na configuração do servidor (não em ini_set() nem .user.ini) e reinicie todos os workers.

# no pool do FPM (ex.: /etc/php/8.3/fpm/pool.d/www.conf), que a aplicação não consegue mudar:
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          # 32M se o site precisa de upload
php_admin_value[upload_max_filesize] = 6M    # sempre abaixo do post_max_size
php_admin_flag[session.upload_progress.enabled] = off
# só no PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off

• memory_limit = -1 (contra a CVE-2026-109618) tira o limite de memória do PHP. Isso remove a falha de memória que o atacante controla, mas não fecha o caminho por completo: uma falha real de alocação (a memória do servidor acabando) ainda pode chegar ao ponto vulnerável. E um script com defeito pode consumir toda a RAM do servidor. Por isso o time do PHP recomenda pôr um limite fora do PHP: o limite de memória do container (Docker) ou do serviço (cgroup, no systemd MemoryMax=), de preferência derrubando só o processo afetado.
• Não use RLIMIT_AS/RLIMIT_DATA (limites de memória do ulimit) no lugar disso: eles podem provocar justamente a falha de memória vulnerável.
• session.upload_progress.enabled e fatal_error_backtraces desligados (contra a CVE-2026-109619) bloqueiam só os caminhos confirmados, não outras variantes.

Ficou exposto? Procure sinais de invasão

# arquivos .php criados ou mudados nos últimos 7 dias dentro do site
find /var/www -name '*.php' -mtime -7 -ls
# .php dentro da pasta de uploads do WordPress (lá não deveria haver nenhum)
find /var/www -path '*wp-content/uploads*' -name '*.php' -ls
# tarefas agendadas que você não criou
crontab -l; sudo crontab -l -u www-data; ls -la /etc/cron.*
# acessos recentes e usuários novos
last -20; tail -5 /etc/passwd
wp user list --role=administrator --path=/var/www/seusite   # WP-CLI; como root, acrescente --allow-root

Achou algo que você não criou: tire o site do ar, troque senhas e chaves, restaure de um backup anterior à invasão.