El 21 de octubre de 2026 el equipo de seguridad de PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas de ejecución remota de código (RCE) sin autenticación: CVE-2026-109618 y CVE-2026-109619. Ambas tienen una gravedad de 9,2 sobre 10 (CVSS v4.0). PHP recomienda actualizar de inmediato.

Esta guía te cuenta qué es oficial, cómo saber si estás afectado, cómo parchar según dónde corra tu PHP, qué hacer si no puedes actualizar hoy y cómo revisar si alguien entró antes. Al final tienes un prompt listo para pegar en tu agente de IA (Claude Code, Codex, Cursor, etc.) y todos los recursos y fuentes.

Resumen rápido

  • Son dos fallos en el núcleo de PHP, no en WordPress, Laravel ni en ninguna librería: si tu PHP está sin parchar, tu aplicación está expuesta aunque no tenga ninguna vulnerabilidad propia.
  • Permiten ejecutar código en el servidor sin autenticación y con los privilegios del proceso web (el usuario con el que corre Apache o PHP-FPM).
  • Versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
  • PHP 8.1 y anteriores no reciben parche del proyecto. Solo te salvas con un backport de tu distribución o proveedor LTS, con una compilación desde código fuente o migrando.
  • Ya hay explotación reportada en internet y circula código sin verificar. No descargues ni ejecutes pruebas de concepto de origen dudoso: es una vía frecuente de malware.
  • Después de actualizar hay que reiniciar PHP-FPM o Apache: un paquete nuevo en disco no protege a los procesos viejos que siguen en memoria.

Qué versión necesitas

Rama Versión corregida Estado
PHP 8.5 8.5.12 Parche oficial
PHP 8.4 8.4.27 Parche oficial
PHP 8.3 8.3.36 Parche oficial
PHP 8.2 8.2.35 Parche oficial
PHP 8.1 y anteriores — Sin parche del proyecto: solo backports de terceros o de código fuente

Los avisos de seguridad indican como afectadas todas las versiones anteriores a esas cuatro dentro de cada rama.

Qué son las dos vulnerabilidades

CVE-2026-109618: corrupción de memoria al quedarse sin memoria (OOM)

PHP usa longjmp() para salir cuando una reserva de memoria falla. Si eso ocurre mientras la petición todavía se está inicializando, PHP sale con las estructuras internas a medio construir, y el cierre de la petición las procesa como si fueran válidas. Eso corrompe la memoria y puede acabar en ejecución de código.

El aviso explica que varios problemas del procesado de multipart/form-data pueden provocar ese agotamiento de memoria sin salirse de los límites que PHP anuncia, por ejemplo con peticiones sin una cabecera Content-Length utilizable o con partes con cabeceras sin límite.

CVE-2026-109619: estado global obsoleto

PHP conservaba estado global de una petición que apuntaba a memoria que ya se había liberado. Otra petición atendida por el mismo worker podía usar ese estado obsoleto antes de que se reiniciara. Los fatal errors, el agotamiento de memoria o algunos avisos pueden dejarlo en ese estado. Los casos confirmados pasan por el progreso de subida de sesiones (session.upload_progress) y por el backtrace de errores fatales. El resultado es un use-after-free en el heap, lectura de memoria y ejecución de código.

Quién está en riesgo

Según el aviso oficial, todas las instalaciones de PHP que atienden peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor con mod_php: PHP demostró un exploit en el que una petición sin autenticar dispara el ataque antes de que se ejecute código de la aplicación. Que tu sitio no tenga formularios de subida no te protege.

El impacto confirmado es ejecución de código con los privilegios del worker web. Con eso un atacante puede leer los archivos de tu aplicación (incluido el .env) y moverse hacia la base de datos y los servicios que tu aplicación use.

Qué se sabe de PHP2Shell y de la explotación

  • PHP2Shell es el nombre con el que se difundió la herramienta que, según un video filtrado, explota estos fallos. No es un nombre oficial de PHP.
  • Un video publicado en X muestra ejecución de código contra instalaciones por defecto de WordPress, Magento, Laravel, Symfony, Drupal, MediaWiki y phpBB. La clave: el fallo está en PHP, no en esas aplicaciones.
  • Según Sansec y Tenable, Cloudflare reportó los primeros ataques el 21 de octubre, antes del lanzamiento del parche, y desplegó reglas en su WAF para todos los planes como medida transitoria. watchTowr dice haber visto explotación en sus honeypots y haber reproducido CVE-2026-109618.
  • Todo lo anterior son informes de terceros. Lo oficial es lo que dicen php.net y los avisos GHSA que tienes en las fuentes.

Cómo saber qué tienes

Revisa cada servidor, contenedor, imagen de CI y entorno de staging. Una misma máquina puede tener varias versiones de PHP, y la que usa la web no siempre es la de php -v (que es la de la línea de comandos).

# Versión de la CLI y de FPM
php -v
php-fpm -v            # en Debian/Ubuntu: php-fpm8.4 -v (ajusta a tu versión)

# Qué procesos sirven la web y desde cuándo corren
ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm: master|[a]pache2|[h]ttpd'

# ¿Apache con mod_php?
apache2ctl -M 2>/dev/null | grep -i php     # en RHEL: httpd -M | grep -i php

# Contenedores en ejecución
docker ps --format '{{.Names}}' | while read c; do echo "== $c"; docker exec "$c" php -v 2>/dev/null | head -1; done

Ojo con los backports. Las distribuciones parchan sin cambiar el número de versión: un php -v que dice 8.3.6 en Ubuntu 24.04 puede estar ya corregido. Para saberlo, mira el registro de cambios del paquete:

# Debian/Ubuntu
dpkg -l 'php*' | awk '/^ii/ {print $2, $3}'
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'

# RHEL / Alma / Rocky
rpm -qa 'php*' --qf '%{NAME} %{VERSION}-%{RELEASE}\n'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961(8|9)'

Si el changelog menciona los dos CVE, tu paquete está corregido aunque el número no coincida con la tabla de arriba. Si no aparecen, no lo está.

Cómo parchar

Debian y Ubuntu

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt upgrade

Según los trackers de seguridad al momento de escribir esto (21 de octubre), Debian ya marcaba corregido php8.4 en trixie (8.4.27-1~deb13u1) y Ubuntu listaba correcciones para 22.04, 24.04 y 26.04, mientras que php8.2 de Debian bookworm aparecía aún pendiente. Esto cambia de hora en hora: confírmalo en los enlaces de fuentes y con apt changelog.

Si usas un repositorio de terceros para PHP (por ejemplo el de Ondřej Surý), comprueba que ya tenga publicada la versión corregida antes de dar el trabajo por hecho.

RHEL, AlmaLinux y Rocky

dnf module list --enabled php
sudo dnf upgrade --refresh 'php*'

PHP avisó de que rpms.remirepo.net (mantenido por voluntarios) no tendría actualizaciones el día del lanzamiento y pide cambiarse a los paquetes de la distribución o compilar desde código fuente para poder aplicar los parches de inmediato.

Docker

Reiniciar un contenedor no actualiza PHP: hay que reconstruir la imagen sobre una base ya corregida.

docker compose build --pull --no-cache
docker compose up -d
docker compose exec <servicio> php -v

Si tu Dockerfile fija una versión concreta (php:8.4.20-fpm), cámbiala a una corregida (8.4.27 o una etiqueta de rama como php:8.4-fpm, una vez publicada la imagen) y reconstruye. No olvides imágenes derivadas, imágenes de CI y entornos de preview.

Windows

Descarga la versión corregida desde la página oficial de descargas de Windows, sustituye la carpeta de PHP conservando tu php.ini y reinicia el servidor web o el proceso FastCGI (IIS, Apache). Si usas un paquete todo en uno (XAMPP, Laragon…), actualiza a una compilación que incluya la versión corregida.

Compilar desde el código fuente

PHP publica los tarballs en su página de descargas. Si compilas, mantén las mismas opciones de ./configure que tu instalación actual y prueba antes de pasar a producción.

Hosting y plataformas gestionadas

  • Laravel Cloud: se parchea automáticamente.
  • Laravel Forge: hay que actualizar PHP desde el panel; si no puedes, apaga el servidor.
  • Laravel Vapor: redespliega los proyectos con PHP 8 automáticamente; actualiza ya los que usen PHP 7.
  • Hosting compartido o WordPress gestionado: pregúntale a tu proveedor qué versión corre y cuándo la parcha. Si usa PHP 8.1 o anterior sin backport, plantéate cambiar de plan o de proveedor.

Después de actualizar: reinicia y verifica

sudo systemctl restart php8.4-fpm      # ajusta al nombre de tu servicio
sudo systemctl restart apache2         # o httpd en RHEL
  • Reinicia todos los workers: PHP-FPM, Apache, FrankenPHP, Octane, Swoole, RoadRunner, workers de colas y cron que corran PHP de larga duración. Los procesos persistentes conservan el binario viejo en memoria.
  • Vuelve a ejecutar php -v, php-fpm -v y el ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm: master' de arriba: la hora de arranque debe ser posterior al parche.
  • Si la distribución parchó por backport, confirma con apt changelog o rpm -q --changelog que aparecen los dos CVE.
  • Prueba tu aplicación: un cambio de versión menor puede tocar extensiones, php.ini o módulos de Apache.

Si no puedes actualizar hoy

PHP lo dice claro: solo actualizar es una solución completa. Estas medidas reducen la exposición a caminos concretos de ataque, pero no hacen segura una instalación. Úsalas solo como puente.

Contra CVE-2026-109618

  • Fija memory_limit=-1 de forma que la aplicación no pueda sobrescribirlo (con php_admin_value en el pool de FPM o en la configuración de Apache) y comprueba que ningún pool, directorio o aplicación vuelva a ponerle un límite finito. Elimina el fallo por límite de memoria controlable, pero un fallo de reserva de memoria del sistema operativo aún puede llegar al camino vulnerable.
  • Baja post_max_size: 8M si tu aplicación no necesita subir archivos y 32M si los necesita, con upload_max_filesize por debajo. Si puedes, aplica también límites en el servidor web o el proxy: tamaño decodificado de la petición, número de campos, número de partes multipart, número de cabeceras y profundidad de anidación. Deben cubrir también las peticiones sin Content-Length utilizable.
  • Pon un límite de memoria de contenedor o cgroup como frontera de disponibilidad, mejor con una política que mate solo al worker afectado. No uses RLIMIT_AS ni RLIMIT_DATA: provocan justo el fallo de reserva que activa el camino vulnerable.

Contra CVE-2026-109619

  • Desactiva session.upload_progress.enabled y reinicia todos los workers. Hazlo en php.ini, en el pool de FPM o en la configuración del servidor, no con ini_set() ni .user.ini. Bloquea los caminos de sesión confirmados, no otras variantes.
  • En PHP 8.5, desactiva fatal_error_backtraces. Bloquea solo el camino confirmado del backtrace de errores fatales.
  • Elimina ajustes inválidos u obsoletos que se apliquen por petición y emitan avisos antes de la inicialización. Esconder los avisos con error_reporting, display_errors o @ no ayuda.
  • Corrige los errores fatales y timeouts de ejecución que un atacante pueda alcanzar: callbacks, procesado de subidas o importaciones y limpiezas.

Ejemplo para un pool de PHP-FPM (/etc/php/8.4/fpm/pool.d/www.conf, ajusta la ruta):

php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M        ; 32M si tu aplicación sube archivos
php_admin_flag[session.upload_progress.enabled] = off
; Solo PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off

Ejemplo con Apache y mod_php:

php_admin_value memory_limit -1
php_admin_value post_max_size 8M
php_admin_flag session.upload_progress.enabled off

Con memory_limit=-1 un solo proceso puede consumir toda la memoria disponible si algo falla: por eso PHP pide combinarlo con un límite de contenedor o cgroup. Y un WAF (por ejemplo las reglas que desplegó Cloudflare) también es solo un parche transitorio. Reinicia los servicios después de cambiar cualquier ajuste.

Si usas PHP 8.1 o anterior

PHP 8.1, 8.0, 7.x y 5.x ya no reciben actualizaciones del proyecto. Tus opciones, de mejor a peor:

  1. Migrar a una rama soportada (8.2 a 8.5; lo ideal es la más reciente que tu aplicación permita).
  2. Usar el backport de tu distribución o proveedor LTS, si lo ofrece. Verifícalo con apt changelog o rpm -q --changelog.
  3. Compilar desde código fuente con los backports mínimos que el equipo de seguridad de PHP publicó para ayudar en estos casos: ramas PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 y PHP-8.1-CVE-2026-109618-109619 en el repositorio de php-src. Es una solución de emergencia, no un reemplazo del soporte.
  4. Aislar o apagar lo que no puedas parchar: sin exposición directa a internet, detrás de un WAF y con red restringida, mientras migras.

Cómo revisar si te atacaron

Actualizar corrige el fallo, pero no elimina a alguien que ya esté dentro. Si tu servidor estuvo expuesto con una versión vulnerable, revisa:

  • Señales que describen los analistas: peticiones multipart inusuales seguidas de errores de límite de memoria, cookies PHPSESSID anormalmente grandes o mal formadas en las respuestas, y reinicios inesperados de workers de PHP.
  • Procesos hijos extraños de PHP-FPM:
for p in $(pgrep -f '^php-fpm: pool'); do ps --no-headers -o pid,user,lstart,cmd --ppid "$p"; done
  • Errores de memoria en los registros:
sudo grep -iE 'allowed memory size|out of memory|segfault' /var/log/php*-fpm.log /var/log/nginx/error.log /var/log/apache2/error.log 2>/dev/null | tail -50
  • Archivos PHP nuevos o modificados en las carpetas de la aplicación (webshells):
find /var/www -type f -name '*.php' -mtime -7 -ls     # ajusta la ruta y los días

Si encuentras algo sospechoso, la recomendación general es aislar el servidor, conservar los registros, rotar todos los secretos a los que el proceso web tenía acceso (.env, claves de base de datos, API keys, claves de sesión) y restaurar desde una copia limpia en lugar de limpiar a mano.

Prompt para tu agente de IA

Copia este prompt en tu agente (Claude Code, Codex, Cursor u otro) en la raíz de tu proyecto o en tu servidor. Está pensado para que audite, priorice y te guíe, sin tocar nada sin tu confirmación. Los datos que lleva dentro están contrastados con los avisos oficiales de PHP, pero le pide al agente que los verifique de nuevo, porque los trackers de las distribuciones cambian cada hora.

Actúa como ingeniero de seguridad y SRE con experiencia en PHP. Quiero que audites y me ayudes a corregir mi exposición a las vulnerabilidades críticas de PHP CVE-2026-109618 y CVE-2026-109619 (publicadas el 21 de octubre de 2026) en todo lo que puedas inspeccionar con mis permisos: este repositorio, esta máquina y la infraestructura que pueda alcanzar.

## Hechos (verifícalos contra las fuentes oficiales antes de apoyarte en ellos)
- Son dos RCE sin autenticación, CVSS v4.0 9.2 cada una, corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Se consideran afectadas las versiones anteriores a esas dentro de cada rama.
- CVE-2026-109618 ("RCE via OOM corruption", GHSA-w8hw-w9fx-j79w): el manejo de memoria agotada con longjmp() interrumpe PHP mientras los datos internos de la petición están a medio inicializar y el cierre de la petición los trata como válidos. Se puede provocar con parsing multipart sin salirse de los límites anunciados (por ejemplo peticiones sin Content-Length utilizable o partes con cabeceras sin límite).
- CVE-2026-109619 ("RCE via stale global state", GHSA-6wmf-4rv5-p3rp): estado global de una petición sobrevive a la liberación de su memoria y otra petición del mismo worker lo usa. Caminos confirmados: session.upload_progress y fatal_error_backtraces (PHP 8.5).
- Afectan a PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor con mod_php. El impacto es ejecución de código con los privilegios del worker web.
- PHP 8.1 y anteriores NO tienen parche del proyecto. Existen backports mínimos de código fuente en las ramas PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 y PHP-8.1-CVE-2026-109618-109619 de php-src. Algunas distribuciones y proveedores LTS aplican backports sin cambiar el número de versión, así que `php -v` NO basta para saber si un paquete está corregido.
- Hay explotación reportada en internet y circula código sin verificar.
- Fuentes oficiales: https://www.php.net/archive/2026.php (aviso del 21-oct-2026), https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w y https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp.

## Reglas de trabajo
1. Empieza en modo SOLO LECTURA. No instales, actualices, reinicies, borres ni cambies configuración sin mostrarme antes el comando exacto, qué hará y qué riesgo tiene, y sin esperar mi "sí" explícito.
2. No descargues ni ejecutes pruebas de concepto, exploits ni herramientas como "PHP2Shell" de orígenes no verificados: suelen traer malware. No intentes explotar nada. Si quieres validar una mitigación, hazlo solo con comprobaciones de configuración y versión.
3. No imprimas ni guardes secretos (.env, claves, tokens). Si los ves, no los copies a la respuesta.
4. Distingue siempre entre "verificado" (lo comprobaste tú en el sistema o en una fuente oficial) y "supuesto". Si un dato no se puede verificar, dilo.
5. Antes de cualquier cambio en producción, propón copia de seguridad o snapshot, ventana de mantenimiento y plan de reversión.

## Paso 1: inventario completo de PHP (todo lo posible)
Busca TODAS las formas en las que corre PHP, no solo la evidente:
- Binarios y servicios del sistema: php, php-cgi, php-fpm y sus variantes versionadas (php8.2, php8.3, php8.4, php8.5), mod_php en Apache, FrankenPHP, LiteSpeed/lsphp, Caddy/Nginx con FPM. Revisa que SAPI sirve realmente la web (puede no ser la misma versión que la CLI).
- Varias versiones en la misma máquina: un pool de FPM por sitio, sockets distintos por versión, alternativas (update-alternatives), versiones por usuario (cPanel/Plesk/CloudLinux alt-php, Herd, Valet, phpenv, asdf, Homebrew, snap).
- Contenedores y orquestación: Dockerfiles (FROM php:*, imágenes derivadas, multi-stage, imágenes fijadas por digest), docker-compose, Kubernetes (Deployments, Helm charts, CronJobs), imágenes de CI/CD, imágenes en registros que se vayan a desplegar, devcontainers.
- Serverless y plataformas: capas Lambda (Bref), Vapor, Cloud Run, Forge/Cloud/Ploi/RunCloud, hostings gestionados.
- Archivos de proyecto que fijan o sugieren versión: composer.json (require.php y config.platform.php), composer.lock (platform), .php-version, .tool-versions, mise.toml, .github/workflows (setup-php), .gitlab-ci.yml, Dockerfile*, Procfile, runtime.txt, Vagrantfile, Ansible/Terraform/Packer.
- Procesos de larga duración que conservan el binario viejo en memoria: Laravel Octane, Swoole, RoadRunner, FrankenPHP worker mode, Horizon, workers de colas, supervisor/systemd, cron.
- Entornos olvidados: staging, preview, demo, servidores antiguos, máquinas de clientes y servicios expuestos a internet.
Para cada hallazgo anota: ubicación, versión exacta, SAPI, si está expuesto a internet, si es producción, quién lo gestiona y cómo se actualiza.

## Paso 2: ¿está corregido?
- Compara con la tabla de versiones corregidas (8.5.12, 8.4.27, 8.3.36, 8.2.35).
- Para paquetes de distribución con backports, verifica el changelog del paquete: `apt changelog <paquete>` / `rpm -q --changelog <paquete>` buscando CVE-2026-109618 y CVE-2026-109619. Consulta también el tracker de seguridad de la distribución (Debian, Ubuntu, Red Hat/Alma/Rocky, Alpine) porque el estado puede haber cambiado hace minutos.
- Comprueba que los procesos en ejecución arrancaron DESPUÉS de instalar el parche (hora de arranque del proceso vs fecha de instalación del paquete). Un paquete parchado en disco no protege a un worker antiguo.
- Marca como CRÍTICO: PHP 8.1 o anterior sin backport verificado, mod_php expuesto, cualquier servidor sin parchar con acceso a internet.

## Paso 3: plan de parcheo priorizado
Ordena por exposición e impacto (expuesto a internet y sin parche > interno > desarrollo). Para cada entorno, dame los comandos exactos (apt, dnf, apk, brew, Docker build --pull --no-cache, Windows, compilación desde fuente), el servicio a reiniciar (systemctl restart php-fpm / apache2 / httpd, recreación de contenedores), la comprobación posterior y el plan de reversión. Si algo depende de PHP 8.1 o anterior, ofréceme opciones: migrar de rama, backport de la distribución, compilar los backports oficiales de código fuente, o aislar el servicio. Señala bloqueos de compatibilidad (extensiones, composer.json, frameworks) antes de proponer subir de versión.

## Paso 4: mitigaciones temporales solo si no se puede parchar ya
Propón (sin aplicar) las medidas oficiales, dejando claro que NO hacen segura la instalación:
- CVE-2026-109618: memory_limit=-1 fijado con php_admin_value (que la app no pueda sobrescribir) y verificando que ningún pool o directorio lo cambie; post_max_size bajo (8M sin subidas, 32M con subidas) con upload_max_filesize menor; límites en el servidor web o proxy de tamaño decodificado, número de campos, partes multipart, cabeceras y profundidad de anidación (también para peticiones sin Content-Length utilizable); límite de memoria de contenedor/cgroup como frontera de disponibilidad. NO usar RLIMIT_AS ni RLIMIT_DATA.
- CVE-2026-109619: session.upload_progress.enabled=0 en php.ini/pool/servidor (no con ini_set ni .user.ini) y reinicio de todos los workers; en PHP 8.5, fatal_error_backtraces=0; eliminar ajustes inválidos o deprecados aplicados por petición que emitan avisos antes de la inicialización; corregir errores fatales y timeouts alcanzables por un atacante (callbacks, subidas, importaciones, limpiezas).
- Complementos: reglas WAF (por ejemplo las de Cloudflare) solo como parche transitorio, y reducir la exposición de red.

## Paso 5: ¿hubo compromiso?
Busca indicios, solo lectura: procesos hijos inesperados de php-fpm, peticiones multipart anómalas seguidas de errores de límite de memoria, cookies PHPSESSID anormalmente grandes o mal formadas, reinicios inesperados de workers, segfaults, archivos .php nuevos o modificados en las carpetas de la aplicación y de subidas, cron o tareas programadas nuevas, usuarios o claves SSH nuevos, conexiones salientes inusuales. Si hay indicios: no limpies a mano; recomienda aislar, conservar registros, rotar todos los secretos accesibles por el proceso web y restaurar desde una copia limpia.

## Paso 6: endurecimiento posterior
Sugiere mejoras para que el próximo parche urgente sea fácil: fijar versiones de PHP en un solo lugar, imágenes base reconstruidas con regularidad, inventario automático de versiones, alertas de seguridad de PHP y de la distribución, PHP-FPM por usuario con privilegios mínimos, límites de petición en el proxy y monitorización de errores fatales.

## Entrega
Dame primero un resumen ejecutivo de 5 líneas (qué encontraste, qué es crítico, qué hacer hoy). Después una tabla con: entorno, versión, SAPI, ¿expuesto?, ¿corregido? (verificado/supuesto), acción y prioridad. Luego el plan por pasos con los comandos listos para revisar, y al final la lista de lo que NO pudiste verificar. No ejecutes ningún cambio hasta que yo apruebe el plan.

Recursos y fuentes

Oficiales (PHP)

Distribuciones

Análisis y noticias

Origen de la filtración y demostración

Esta nota se basa en los avisos oficiales de PHP del 21 de octubre de 2026. El estado de los parches en cada distribución cambia rápido: confírmalo en los enlaces anteriores antes de dar un servidor por corregido.