Actualiza y audita tus sistemas hoy

Descarga el script y léelo antes de ejecutarlo

Regla de oro: nunca ejecutes un script de internet sin mirar qué hace. Este tiene alrededor de 650 líneas, comentadas.

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

O clona el repositorio: git clone https://github.com/inematds/auditoria-seguranca.

Ejecútalo en la máquina

Sin sudo audita tu usuario (y los contenedores, si estás en el grupo docker). Con sudo ve también las carpetas de otros usuarios. La búsqueda en el disco tarda hasta 3 minutos; --rapido se salta esa parte.

./audita.sh                 # completo
sudo ./audita.sh            # incluye contenedores Docker y otros usuarios
./audita.sh --rapido        # sin buscar venvs, Node, Deno, Bun y JDKs en el disco
./audita.sh --sem-docker    # no entra en los contenedores
./audita.sh --comandos      # muestra los comandos de corrección (no ejecuta ninguno)
./audita.sh --go            # también prueba Go de verdad (mira abajo)
./audita.sh --raiz /opt     # busca en el disco solo en esa carpeta (repite --raiz para varias)

Dos pruebas no son de conexión, y el script lo avisa en la línea. Java: revisa si el archivo de confianza de Java (cacerts) todavía tiene las dos raíces, porque probar la conexión exigiría compilar código Java. Go: la prueba real compila un programa pequeño en una carpeta temporal (unos 100 MB, borrada al final). Como eso escribe en el disco, solo se ejecuta con --go.

Con sudo, el Node instalado por el nvm de tu usuario no está en la ruta estándar; la búsqueda en el disco todavía lo encuentra (no uses --rapido en ese caso).

Lee el 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

Fragmento de ejemplo (la salida real tiene más líneas; el script escribe en portugués). G3 y AAA son los dos "caminos de confianza" probados: cada certificado de sitio está firmado por un intermediario, que está firmado por una raíz en la que confía tu programa.

• EXPOSTO (EXPUESTO): conectó (o, en Java, la lista todavía tiene las raíces; en PHP, la versión es vulnerable). Corrige esa capa (sección Actualizar).
• protegido (protegido): rechazó con error de certificado.
• SEM TESTE (SIN PRUEBA): la prueba no terminó o no prueba nada. Red, DNS, timeout, contenedor sin shell o sin la herramienta, salida cortada, SSH que falló, búsqueda en el disco interrumpida, programa que no es seguro ejecutar, o el wget de busybox con rechazo ambiguo (esa solo cuenta como protegida si la lista de certificados del sistema no tiene la raíz de esa cadena). Nunca cuenta como protegido. Repite o prueba de otra forma antes de concluir.
• VERIFIQUE (VERIFICA): PHP en versión de prueba (RC, beta, dev: un número mayor no prueba corrección) o por debajo de la versión corregida, pero con número de la distribución (puede tener la corrección por backport). En Debian/Ubuntu el script ya busca el CVE en el changelog local del paquete; si no lo encuentra, confírmalo con apt changelog <paquete> | grep CVE-2026-109618. ¿Verificado y corregido? Ejecuta con --php-ok y el VERIFIQUE deja de retener la salida.
• REINICIE (REINICIA): proceso que empezó antes de la corrección y todavía usa el programa o la lista antigua. Mira a quién reiniciar.

Al final viene el bloque o que corrigir, por tipo: cuántos elementos de cada tipo, un ejemplo y el comando sugerido. El resumen cuenta líneas (cada herramienta aparece dos veces, G3 y AAA); el bloque cuenta elementos. Con --comandos sale la lista completa, un comando por elemento, para que la revises y ejecutes uno por uno. El script nunca ejecuta la corrección.

Al final viene también el bloque escopo desta rodada: lo que quedó fuera (--rapido, --sem-docker, --raiz, --php-ok, Go sin --go, y con qué usuario se ejecutó).

Código de salida: 0 las verificaciones hechas pasaron, dentro del alcance impreso; 1 hay EXPOSTO; 2 hay SEM TESTE; 3 nada conecta, pero falta reiniciar procesos o revisar PHP. La salida 0 no quiere decir que toda la máquina esté segura. En monitoreo, trata cualquier salida distinta de 0 como alerta y no liberes un deploy automático solo por la salida 0.

Audita varios servidores por SSH

El script va por el propio SSH y se ejecuta allá, sin copiar nada al servidor. Usa acceso por llave.

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

# o una lista (un destino por línea; no versiones este archivo)
./audita.sh --hosts servidores.txt

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

Si el SSH no conecta o se cae a la mitad (tiempo agotado, bash ausente allá), la línea dice SEM TESTE con el código y la salida no es 0: un servidor que no respondió nunca pasa como limpio. Ejemplo de servidores.txt: una línea root@203.0.113.10, otra deploy@vps2 # loja. Allí, el script se ejecuta con el usuario del SSH: para ver los contenedores y las carpetas de otros usuarios, entra como root (o con un usuario del grupo docker).

Corrige, reinicia y ejecuta de nuevo

La auditoría solo termina cuando el resumen muestra 0 EXPOSTO · 0 SEM TESTE · 0 VERIFIQUE · 0 REINICIE (salida 0) en todas las máquinas, en una pasada completa (sin --rapido, y con el bloque de alcance sin nada importante afuera). Un proceso que ya estaba corriendo guarda la lista antigua en la memoria: actualizar sin reiniciar no resuelve.

Sistema (ca-certificates)

# Ubuntu / Debian
sudo apt update && sudo apt install --only-upgrade ca-certificates
dpkg-query -W ca-certificates          # comprueba la versión
# Alpine
apk upgrade --no-cache ca-certificates
# Fedora / RHEL
sudo dnf upgrade ca-certificates

Deja activada la actualización automática (unattended-upgrades en Ubuntu/Debian). En nuestro caso fue ella la que corrigió el sistema sola.

Python: el certifi de cada entorno

requests y muchos paquetes usan certifi, no la lista del sistema. Cada venv tiene el suyo. audita.sh lista los desactualizados.

/caminho/do/venv/bin/python -m pip install -U certifi pip
python3 -c "import certifi; print(certifi.__version__, certifi.where())"  # 2026.10.19 o más
# herramientas instaladas con pipx / uv tool
pipx upgrade-all        # o: pipx runpip <app> install -U certifi
uv self update          # uv 0.13.5 o más
uv tool upgrade --all
# entornos conda (miniconda/anaconda)
conda update -n <entorno> certifi

Atención al Python "del sistema": si aparece EXPOSTO (EXPUESTO) en el modo certifi, hay un certifi instalado con pip --user en tu carpeta (~/.local/lib/python3.X/). La ruta que muestra el comando de arriba dice cuál es. En Ubuntu 24.04 y en Debian 12+ pip se niega a tocar ahí ("externally-managed-environment"); como el cambio queda solo en tu carpeta de usuario, usa:

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

El certifi del paquete del sistema (/usr/lib/python3/dist-packages) no necesita esto: en Debian/Ubuntu apunta a la lista de ca-certificates.

Venv sin pip (creado por uv): el comando -m pip falla. Usa uv apuntando al Python del venv:

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

Node: cambia de versión (Node 20 no tiene corrección)

Node trae la lista de certificados dentro del propio programa. Actualizar el sistema no cambia nada para él.

# con nvm
nvm install 22 && nvm alias default 22     # 22.23.4 o más
# con el repositorio NodeSource (apt): está separado por versión.
# Si estás en el 20, cambia el repositorio al 22 antes de instalar:
curl -fsSLo nodesource_setup.sh https://deb.nodesource.com/setup_22.x
less nodesource_setup.sh                  # léelo
sudo bash nodesource_setup.sh && sudo apt install -y nodejs
# ¿ya estás en el 22 o 24? basta con actualizar
sudo apt update && sudo apt install --only-upgrade nodejs
node -v

Paliativo para quien no puede cambiar hoy (probado por nosotros): hacer que Node use la lista del sistema ya actualizada. Solo funciona si el ca-certificates está corregido. --use-system-ca no sirve: suma las dos listas y siguió EXPOSTO (EXPUESTO) en nuestra prueba.

export NODE_OPTIONS=--use-openssl-ca   # en el servicio/entorno de la app; luego reinicia

Un Node descargado de nvm o de nodejs.org puede no encontrar solo la lista del sistema: si la prueba da error en todo, agrega SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt y confirma con audita.sh. NODE_OPTIONS es la variable de entorno que pasa opciones a todo Node iniciado ahí (en systemd: Environment=NODE_OPTIONS=--use-openssl-ca; en Docker: environment: del compose).

Busca también Node embebido: Playwright, agentes de IA y apps traen un Node propio. audita.sh encuentra esos binarios en el disco; actualiza la herramienta que los trajo. En el caso de Playwright dentro de un venv de Python, el Node queda en …/site-packages/playwright/driver/node: actualiza el paquete (pip install -U playwright; en npm, npm i playwright@latest) o usa el paliativo NODE_OPTIONS=--use-openssl-ca en el servicio que lo usa.

Go: actualiza y recompila

Instala Go 1.27.3 o 1.26.10 y genera el binario de nuevo (go build). Programas Go de terceros: actualiza a la versión que lancen después del 21/10.

Lo que vimos en nuestra prueba, en Linux: un programa hecho con Go 1.26.3 rechazó las dos cadenas con la lista del sistema corregida y conectó cuando apuntamos a una lista antigua (SSL_CERT_FILE). O sea, en Linux Go sigue la lista del sistema, o la del contenedor donde corre. Corregir el ca-certificates ya protege a buena parte de los programas Go; quien embebe su propia lista (paquete x509roots/fallback) o corre en un contenedor con imagen antigua sigue expuesto. Por eso recompila de todos modos. Para la prueba real: ./audita.sh --go.

Java: el archivo cacerts se queda atrás

Java no lee la lista del sistema directamente: usa un archivo propio, el cacerts. En Debian/Ubuntu ese archivo se genera a partir de ca-certificates, pero puede no rehacerse en la actualización. En nuestro caso, el sistema ya estaba corregido y el cacerts de OpenJDK 8 seguía siendo de 2025, con las dos raíces dentro.

# dónde está el cacerts del Java que usas
readlink -f $(dirname $(readlink -f $(which java)))/../lib/security/cacerts
ls /usr/lib/jvm/                        # otros JDK instalados
# ¿todavía tiene las raíces?
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: guarda una copia y quita las dos raíces del 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 con cacerts propio (descargado aparte, dentro de un IDE, en un /opt): actualiza el JDK. changeit es la contraseña predeterminada del archivo, pública; solo protege contra escritura accidental. Después, reinicia los programas Java.

Deno y Bun: la lista viene dentro del programa

Como Node, los dos traen la lista embebida. En nuestra prueba, Deno 2.7.12 y Bun 1.3.13 conectaron; después de actualizar, Deno 2.9.8 y Bun 1.4.4 rechazaron las dos cadenas.

deno upgrade
bun upgrade
# prueba de una línea (error 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/')"

Los dos quedan en la carpeta del usuario (~/.deno, ~/.bun): corre la actualización con el usuario dueño, no con sudo.

Docker: cada contenedor es una máquina

El contenedor no usa el ca-certificates del servidor. Imagen antigua = lista antigua. La corrección depende de cómo llegó la imagen ahí, y audita.sh ya separa los contenedores expuestos en estos grupos (con docker inspect, sin tocar nada).

Un contenedor sin curl, wget, Node ni Python (ej.: postgres:16 Debian) aparece como SEM TESTE "nenhuma ferramenta de teste" (ninguna herramienta de prueba) (cuenta como prueba que no se ejecutó, y la salida no es 0): el script no tiene cómo probar la conexión. Comprueba la lista por el paquete (docker exec <c> dpkg-query -W ca-certificates o apk list -I ca-certificates-bundle) y compárala con la tabla de versiones.

Grupo A: haz pull y recrea

docker compose up -d --pull always redis      # un servicio; repite para los demás
docker compose pull && docker compose up -d   # todos de una vez (mira el aviso sobre bases de datos abajo)
# prueba: el paquete de la lista dentro del contenedor (Alpine)
docker compose exec redis apk list -I ca-certificates-bundle   # 20261020-r0 o más

Si pruebas a mano con el wget de busybox (Alpine), el rechazo aparece como ssl_client: SSL_connect o Connection reset by peer, que parece un error de red. Para estar seguro, prueba un sitio bueno con el mismo wget (wget -O /dev/null https://www.google.com/): si ese abre, la falla del sitio de prueba fue de certificado. audita.sh ya hace esa comprobación.

• Contenedor sin compose (creado con docker run): guarda la receta antes, docker inspect redis > redis.inspect.json, y mira .Mounts. Sin volumen, los datos mueren con el contenedor: en Redis, redis-cli save y docker cp redis:/data/dump.rdb . antes; después levanta el nuevo con los mismos puertos y variables y devuelve el archivo.
• Imagen nueva ya en el disco, contenedor antiguo corriendo: pasa cuando otro proyecto hizo pull de la misma etiqueta. No hace falta descargar nada, solo recrear (docker compose up -d <servicio>). audita.sh muestra esos como "solo recrear".
• "latest" todavía antigua: el proveedor puede no haber publicado la imagen corregida. En nuestro caso, una imagen :main del 16/10 siguió EXPOSTA (EXPUESTA) después del pull. Ahí usa la capa por encima (abajo) hasta que salga la oficial.

Grupo B: la capa por encima de la imagen antigua

Reconstruir con docker compose build --pull baja la base nueva y todas las dependencias sin versión fija. En nuestro caso, una app en Node subió plugins nuevos y dejó de funcionar. La técnica que funcionó: mantener la imagen que ya corre y cambiar solo la lista y Node por encima.

# 1) guarda la imagen actual con otro nombre (es tu camino de vuelta)
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   # solo si la imagen tiene Node 22; misma versión principal y misma distro de la 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                                           # si la app tiene Python con pip propio
USER app                                                                        # vuelve al usuario original (mira: docker inspect -f '{{.Config.User}}' meuapp:pre-emudhra)

# 3) construye por encima y recrea
docker build -f Dockerfile.emudhra -t meuapp:latest .
docker compose up -d meuapp
# ¿salió mal? vuelve: docker tag meuapp:pre-emudhra meuapp:latest && docker compose up -d meuapp

• El Node copiado tiene que tener la misma versión principal que el que ya está en la imagen (22 por 22): los módulos nativos (.node) hechos para Node 20 no cargan en el 22. Una imagen con Node 20 no se puede corregir así; hay que reconstruirla con base 22.
• Si pip se niega con externally-managed-environment, el Python es el del sistema de la imagen (apt): el ca-certificates actualizado ya cubre ese Python. Quita la línea de pip; no uses || true, que esconde el error.
• El node:22-… del COPY tiene que ser de la misma familia que la base (bookworm con Debian 12, alpine con Alpine), si no el binario no corre.
• App que arranca con uv run: uv resincroniza el venv con uv.lock y deshace el certifi nuevo. Sube el certifi en el lock, o cambia solo el archivo cacert.pem del certifi fijado por el de la lista nueva.
• ¿Hay un nginx delante (proxy)? Después de recrear la app, reinicia también el nginx: guarda la dirección interna antigua y pasa a responder 502.
• docker-compose antiguo (1.29) con KeyError: 'ContainerConfig': docker-compose rm -f -s <servicio> antes del up.
• Con calma, después: cambia la base node:20 por node:22 (o 24) en el Dockerfile, fija las versiones de las dependencias y reconstruye de verdad (docker compose build --pull).

Grupo C: versión fija (y el Supabase local)

Sube la versión en el compose o en la configuración a una lanzada después del 21/10/2026 y prueba de nuevo. Si el proveedor todavía no reconstruyó la imagen, no hay nada que bajar: la espera es por él.

Supabase local (el de la CLI supabase start) es el caso típico: la CLI fija cada imagen. El camino es este, en este orden:

# 1) respaldo de la base de datos (con todo corriendo)
docker exec supabase_db_<proyecto> pg_dumpall -U postgres > supabase-backup.sql
# 2) CLI nueva + parar y levantar (en la carpeta del proyecto; sin --no-backup, que borraría los datos)
npx -y supabase@latest stop && npx -y supabase@latest start
# 3) prueba de nuevo
./audita.sh                       # completo: el --rapido no encuentra venvs ni a quién reiniciar

• Nunca quites los contenedores de Supabase a mano (docker rm): usa la CLI.
• En nuestra prueba, la CLI nueva trajo imágenes nuevas, pero 10 de 12 contenedores siguieron EXPOSTOS (EXPUESTOS): solo algunas imágenes ya venían corregidas. Mientras el proveedor no reconstruya, no hay más que hacer que esperar y probar de nuevo.
• No cambies la imagen oficial por una capa local con la misma etiqueta: el próximo supabase start descarta la tuya.
• El start puede levantar más servicios que antes (en nuestro caso, de 4 a 12 contenedores). Revisa la memoria de la máquina.
• Riesgo: con todo solo en localhost, la exposición es baja. Los que hacen conexión HTTPS de salida son pocos servicios (autenticación, panel, logs).

n8n: respaldo, luego actualiza

n8n corre en Node. Versión antigua = Node antiguo dentro del contenedor.

# 1) encuentra el nombre del volumen (el compose suele poner el nombre de la carpeta delante)
docker volume ls | grep n8n                 # ej.: meuprojeto_n8n_data
# 2) para n8n y haz el respaldo (con él parado la base no sale a medias)
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) si el compose fija la versión (image: n8nio/n8n:2.4.8), cámbiala por la actual antes:
#    image: n8nio/n8n:2.44.6   (o más nueva; revisa las notas de versión)
# 4) actualiza
docker compose pull n8n && docker compose up -d n8n
docker compose exec n8n node -v                     # confirma el Node nuevo

Hacer pull de la misma etiqueta puede traer una imagen republicada. Revisa si el digest cambió (docker image inspect -f '{{.RepoDigests}}' n8nio/n8n:2.4.8, antes y después): si no cambió, subir la versión es el camino.

Otras formas de guardar los datos: si n8n usa una carpeta montada (ej.: ./n8n_data o ~/.n8n), copia la carpeta con él parado; si usa Postgres, haz el pg_dump de la base. En todos los casos guarda junto la clave de cifrado (N8N_ENCRYPTION_KEY o el archivo config de la carpeta de n8n): sin ella las credenciales guardadas no vuelven.

Después de actualizar, mira el log (docker compose logs n8n). Los saltos grandes de versión pueden traer avisos nuevos, como el del ejecutor de Python del nodo Code.

Windows, macOS, celular y apps

• Windows: Windows Update (corrección de Microsoft del 20/10).
• macOS / iPhone: actualización del sistema (Apple, 22/10).
• Navegadores: reinicia el navegador para aplicar; Firefox 158.0.1 o más.
• Apps Electron (VS Code, Slack, Discord y otras): actualiza cada app. Quien desarrolla: Electron 44.9.1 / 43.8.1 / 42.11.16.
• Rust: cargo update -p rustls-webpki -p webpki-roots y recompila.

Reinicia los servicios (y encuentra a quién reiniciar)

El programa que ya está corriendo guardó la lista antigua en la memoria: actualizar sin reiniciar no resuelve. Bots, APIs, workers, agentes, n8n y cualquier servidor Python con venv (uvicorn, gunicorn) necesitan reiniciar después de la corrección. audita.sh lista en la sección processos a reiniciar a quien todavía corre con el programa antiguo (Node se cambió después de que el proceso empezó) o empezó antes del certifi nuevo de su venv.

# a mano: procesos Python de venv y Node, con el tiempo de ejecución en segundos
ps -eo pid,etimes,args | grep -E "venv/bin/python|/node " | grep -v grep
# servicios que están corriendo
systemctl list-units --type=service --state=running
systemctl --user list-units --type=service --state=running
pm2 list
# reinicia
sudo systemctl restart <servicio>     # servicios del sistema
systemctl --user restart <servicio>   # servicios de tu usuario
pm2 restart all                       # apps Node gestionadas por pm2 (pm2 update reinicia el propio pm2)
docker compose up -d                  # contenedores: recrea con la imagen nueva

En la lista del script, cada proceso viene con lo que hay que reiniciar: (sistema) es sudo systemctl restart, (--user) es systemctl --user restart, y processo avulso es algo que abriste en la terminal, en tmux o en pm2: reinicia solo ese programa.

Atención: docker compose restart solo reinicia el mismo contenedor, con la imagen vieja. Después de pull o build, lo correcto es docker compose up -d.

Y corre audita.sh de nuevo.

Prueba: el verificador de OpenAI

OpenAI publicó el php2shell-checker (licencia Apache 2.0). Lee la versión que el sitio anuncia en los encabezados; no envía ningún ataque. Necesita git y Node instalados en tu computadora (no en el 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)

O pídele a tu agente (Claude Code, Codex): "ejecuta el php2shell-checker solo contra mi sitio y explícame el resultado". UNKNOWN no es luz verde: el sitio oculta la versión; confírmala en el panel o en el servidor.

En el servidor: mira la versión real

php -v
php-fpm8.3 -v                       # ajusta el número de la versión
apt changelog php8.3-fpm | head -30  # Debian/Ubuntu: busca CVE-2026-109618
# PHP dentro de contenedores (paneles, WordPress, adminer, phpMyAdmin)
for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec $c php -v 2>/dev/null | head -1)"; done

No olvides los contenedores: una imagen con PHP antiguo es tan vulnerable como el servidor, y los paneles de base de datos suelen quedar expuestos en un puerto. El audita.sh ya muestra la versión de PHP de cada contenedor y del servidor y la compara con las corregidas (EXPOSTO (EXPUESTO) por debajo de ellas; VERIFIQUE (VERIFICA) cuando el número es de un paquete de la distribución). Para corregir: descarga la imagen nueva y recrea el contenedor (grupo A de la sección Docker).

Corrige: actualiza y reinicia todos los procesos

Antes: haz un respaldo del sitio (sudo tar czf site-$(date +%F).tgz /var/www) y de la base de datos (mysqldump --all-databases > wp-$(date +%F).sql), y anota si la home y /wp-admin abren. Después: revisa los dos de nuevo y el php -v. Mira la sección antes y después de actualizar.

• Versiones corregidas: 8.5.12, 8.4.27, 8.3.36, 8.2.35 (o el paquete corregido de tu distribución).
• PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. Algunas distribuciones y proveedores LTS tienen la corrección: pregúntales o sube a una versión con soporte. Por la gravedad, el equipo de PHP publicó correcciones mínimas en código fuente para 7.4, 8.0 y 8.1, para quien compila.

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php   # mira qué va a cambiar
sudo apt install --only-upgrade $(dpkg -l 'php*' | awk '/^ii/{print $2}')   # solo los paquetes PHP instalados
sudo systemctl restart php8.3-fpm    # o apache2, si usas mod_php

¿Usas el repositorio PPA ondrej/php (común para tener varias versiones)? También debe tener la versión corregida; confírmalo con php -v después. mod_php es PHP ejecutándose dentro de Apache; PHP-FPM es PHP como servicio separado, usado con nginx o Apache.

¿No puedes actualizar ahora? Reduce la exposición

El propio equipo de PHP avisa: estas medidas reducen caminos de ataque conocidos, no hacen segura la instalación. Solo la actualización lo resuelve. Aplícalas en el php.ini, en el pool de FPM o en la configuración del servidor (no con ini_set() ni en .user.ini) y reinicia todos los workers.

# en el pool de FPM (ej.: /etc/php/8.3/fpm/pool.d/www.conf), que la aplicación no puede cambiar:
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          # 32M si el sitio necesita subir archivos
php_admin_value[upload_max_filesize] = 6M    # siempre por debajo de post_max_size
php_admin_flag[session.upload_progress.enabled] = off
# solo en PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off

• memory_limit = -1 (contra la CVE-2026-109618) quita el límite de memoria de PHP. Esto elimina la falla de memoria que controla el atacante, pero no cierra el camino por completo: una falla real de asignación (la memoria del servidor agotándose) aún puede llegar al punto vulnerable. Y un script con errores puede consumir toda la RAM del servidor. Por eso el equipo de PHP recomienda poner un límite fuera de PHP: el límite de memoria del contenedor (Docker) o del servicio (cgroup, en systemd MemoryMax=), de preferencia terminando solo el proceso afectado.
• No uses RLIMIT_AS/RLIMIT_DATA (límites de memoria de ulimit) en su lugar: pueden provocar justamente la falla de memoria vulnerable.
• session.upload_progress.enabled y fatal_error_backtraces desactivados (contra la CVE-2026-109619) bloquean solo los caminos confirmados, no otras variantes.

¿Quedó expuesto? Busca señales de intrusión

# archivos .php creados o modificados en los últimos 7 días dentro del sitio
find /var/www -name '*.php' -mtime -7 -ls
# .php dentro de la carpeta de uploads de WordPress (ahí no debería haber ninguno)
find /var/www -path '*wp-content/uploads*' -name '*.php' -ls
# tareas programadas que tú no creaste
crontab -l; sudo crontab -l -u www-data; ls -la /etc/cron.*
# accesos recientes y usuarios nuevos
last -20; tail -5 /etc/passwd
wp user list --role=administrator --path=/var/www/seusite   # WP-CLI; como root, agrega --allow-root

¿Encontraste algo que tú no creaste? Saca el sitio del aire, cambia contraseñas y claves, y restaura desde un respaldo anterior a la intrusión.