Dos fallos críticos en el núcleo de PHP (CVSS 9.2) permiten ejecutar código en tu servidor sin iniciar sesión. Los parches ya están disponibles: revisa si estás afectado y protégete hoy, tengas WordPress, Laravel, Docker, Coolify o hosting compartido.
Si tu sitio web usa PHP, hoy es el día de actuar. El equipo de PHP publicó este 21 de octubre actualizaciones de emergencia para dos vulnerabilidades críticas del núcleo del lenguaje, conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619), con una severidad de 9.2 sobre 10. Permiten que un atacante ejecute código en tu servidor sin usuario ni contraseña, y los detalles técnicos se filtraron antes de tiempo, así que la carrera entre atacantes y administradores ya empezó.
Afecta a WordPress, tiendas en Magento o PrestaShop, sistemas en Laravel, paneles de hosting y prácticamente cualquier servidor que procese peticiones web con PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. La telemetría de Palo Alto Networks identificó más de 22 millones de servidores expuestos a internet con versiones potencialmente vulnerables. En esta guía te explicamos, en lenguaje claro y con pasos concretos, qué pasó, cómo saber si estás afectado y cómo protegerte hoy mismo, tengas un hosting compartido, un VPS, contenedores Docker o una plataforma como Coolify.
multipart/form-data, las mismas que usa cualquier formulario con subida de archivos. El fallo se dispara antes de que corra el código de tu aplicación: pedir login no protege.PHP procesa cada petición web en procesos trabajadores (workers) que atienden muchas peticiones seguidas. Los dos fallos rompen la memoria de ese proceso de dos maneras complementarias, según el análisis del aviso oficial y de firmas como Sonatype y watchTowr:
memory_limit), PHP puede interrumpirla dejando datos internos a medio inicializar. La limpieza de esa petición trata esos datos inválidos como si fueran válidos.El resultado práctico es el peor escenario posible: un atacante envía peticiones de subida de archivos especialmente construidas y consigue que el servidor ejecute su código o le entregue trozos de memoria del worker. Esa memoria puede incluir la cookie PHPSESSID y secretos de la aplicación, aunque tu aplicación nunca use sesiones, porque todo ocurre antes de que tu código se ejecute. La configuración de mayor riesgo, según el propio equipo de PHP, es Apache con mod_php.
El nombre "PHP2Shell" viene de una herramienta de explotación cuya captura circuló tras la filtración: su autor presume compatibilidad con PHP desde la versión 5.4. La firma watchTowr confirmó que los fallos son reales y logró reproducir el primero; Sansec, especializada en proteger tiendas en línea, anticipa ataques masivos en cuestión de minutos una vez que los atacantes comparen el código viejo con el parcheado.
Moraleja de la cronología: esto no es un susto teórico. Hay exploit circulando, gobiernos apagando sitios por precaución y una ventana de exposición que se mide en horas, no en semanas.
Estás afectado si tu servidor web corre PHP por debajo de la versión corregida de tu rama:
Formas rápidas de comprobarlo:
# En el servidor o dentro del contenedor
php -v
# En Docker Compose
docker compose exec app php -v
# Desde fuera, si tu servidor expone la cabecera
curl -sI https://tu-sitio.com | grep -i x-powered-by
# X-Powered-By: PHP/8.3.35 ← vulnerableDos advertencias importantes. Primera: si instalas PHP con los paquetes de Debian o Ubuntu, tu distribución puede aplicar el parche sin cambiar el número de versión; en ese caso manda el aviso de seguridad de tu distribución, no solo el php -v. Segunda: actualizar WordPress, Laravel o tu CMS no corrige nada de esto. El fallo está en PHP, una capa por debajo de tu aplicación.
Y ojo con el inventario completo: no revises solo tu sitio principal. El WordPress de marketing que nadie toca, el entorno de pruebas, el phpMyAdmin expuesto y esa tienda vieja en un subdominio también cuentan. Los escáneres automáticos no distinguen entre "el sitio importante" y "el olvidado".
No hay atajo: la única corrección completa es correr una versión parcheada (o un paquete de tu proveedor con el parche aplicado y verificado). Según tu entorno:
apt update && apt upgrade y reinicia los servicios: no basta recargar el servidor web, hay que reiniciar los workers de PHP-FPM (y Apache si usas mod_php), porque un worker viejo puede seguir vivo con el código vulnerable.Dato para quien usa los repositorios rpms.remirepo.net: el propio aviso de PHP señala que hoy no tendrán paquetes actualizados; usa los paquetes de tu distribución o compila desde la fuente oficial.
Si no puedes actualizar en este momento, estas medidas reducen el riesgo. Ninguna sustituye el parche: el propio equipo de PHP advierte que no existe una configuración que corrija el fallo por completo.
Todos los vectores conocidos usan peticiones multipart/form-data. Rechazarlas en el servidor web, antes de que lleguen a PHP, corta el ataque. El costo: se rompen las subidas de archivos (formularios con adjuntos, la biblioteca de medios de WordPress, importaciones CSV y algunos checkouts). Prueba tu sitio después de aplicarlo.
Nginx (en cada bloque server que pase peticiones a PHP):
if ($http_content_type ~* "multipart/form-data") {
return 403;
}Apache (en cada VirtualHost):
<If "%{HTTP:Content-Type} =~ /multipart\/form-data/i">
Require all denied
</If>Caddy / FrankenPHP (en el bloque del sitio):
@multipart header Content-Type *multipart/form-data*
respond @multipart 403¿Necesitas subidas sí o sí en tu panel? Pedir contraseña no protege, porque el fallo ocurre antes de tu aplicación. La salida razonable es permitir multipart solo desde IPs de confianza (tu oficina o tu VPN) y bloquearlo para el resto del mundo.
Sansec recomienda desactivar el registro de progreso de subida de sesiones, uno de los vectores confirmados:
session.upload_progress.enabled = 0Algunos análisis añaden memory_limit = -1 porque el detonante es un error de falta de memoria. Tómalo con pinzas: es una capa parcial, tiene el riesgo de que una sola petición consuma toda la memoria del servidor, y el aviso oficial insiste en que ninguna combinación de ajustes equivale al parche. Si lo aplicas en contenedores, ponle un límite de memoria al contenedor y restaura tu valor normal en cuanto actualices. En PHP 8.5, CyberPanel también sugiere fatal_error_backtraces = 0 para cerrar una ruta concreta; igualmente parcial.
Cloudflare desplegó reglas de WAF contra los vectores conocidos, también en el plan gratuito. Si tu dominio pasa por su proxy (nube naranja), ya tienes una capa extra. Pero protege solo el tráfico que pasa por Cloudflare: si tu servidor también responde por su IP directa, un atacante puede saltarse el escudo.
Para sitios mayormente informativos, aceptar solo GET y HEAD en el servidor web mantiene el sitio visible mientras parcheas. Los formularios dejan de funcionar, pero el ataque también. Ojo: el "modo mantenimiento" de Laravel o WordPress no sirve, porque PHP sigue procesando la petición antes de responder; el bloqueo tiene que estar en Nginx, Apache o Caddy, delante de PHP.
En contenedores el parche no "llega": hay que reconstruir la imagen y redesplegar. Antes de nada, verifica si Docker Hub ya trae la versión corregida:
docker pull php:8.4-fpm && docker run --rm php:8.4-fpm php -vSi devuelve 8.4.27 o superior, reconstruye y redespliega:
docker compose build --pull
docker compose up -d --force-recreate
docker compose exec app php -vDos trampas que dejan a mucha gente expuesta creyendo que ya actualizó: usar tags fijos en el Dockerfile (FROM php:8.3.12-fpm o un digest @sha256:... nunca cambia: hay que editarlo) y reconstruir sin --pull, reutilizando la imagen base vieja que ya está en caché.
Si despliegas con Nixpacks (lo usan Railway, Coolify, Dokploy y EasyPanel, entre otros), hay un problema extra: Nixpacks instala PHP desde una instantánea fija de nixpkgs definida dentro del propio Nixpacks. Hasta que Nixpacks publique una versión con la instantánea actualizada, cada despliegue seguirá trayendo el PHP vulnerable, aunque redespliegues hoy.
Qué puedes hacer mientras tanto:
php:8.4-fpm (o la rama que uses) controlas tú cuándo se actualiza PHP: basta reconstruir con --pull.Aquí no controlas el servidor, pero sí puedes (y debes) moverte hoy:
Traducción práctica: entra a tu panel, revisa qué versión de PHP corre tu sitio (cPanel lo muestra en "Select PHP Version" o "MultiPHP Manager") y, si sigue vulnerable, abre un ticket hoy preguntando por el plan de parcheo de CVE-2026-109618. Un proveedor serio ya está en ello; uno que no responde a esto tampoco responderá el día del incidente.
Que tu WordPress esté actualizado no te protege: el fallo está en PHP, no en el CMS. Se demostró el ataque contra instalaciones recientes de WordPress, Drupal, Joomla y Magento. Lo que sí puedes hacer desde el panel: confirmar la versión de PHP del hosting (Salud del sitio en WordPress lo muestra), exigir el parche a tu proveedor y, si tu hosting lo permite, subir tu sitio a una rama 8.2+ ya corregida desde el selector de versión de PHP.
php -v en cada servidor y contenedor, y reinicia los workers: una recarga del servidor web puede dejar procesos PHP viejos atendiendo peticiones.php.ini y, muy importante, restaura tu memory_limit normal si lo habías cambiado.APP_KEY de Laravel y tokens que vivieran en ese proceso.php -v o el panel de hosting).--pull y redesplegué; nada de tags fijos viejos.memory_limit, roté secretos y revisé logs.No. La vulnerabilidad está en el propio PHP. Puedes tener el CMS más actualizado del mundo y seguir expuesto si el PHP del servidor es vulnerable.
No necesariamente. El atacante no usa tu formulario: envía directamente la petición multipart maliciosa al servidor, y PHP la procesa antes de que tu aplicación decida nada. Por eso pedir login tampoco protege.
Esas ramas no recibirán versión oficial corregida. Algunos proveedores (CloudLinux, TuxCare) publican sus propios parches, y el equipo de PHP facilitó parches de código fuente para 7.4, 8.0 y 8.1. Si tu proveedor no ofrece ninguna de esas vías, la respuesta es migrar a PHP 8.2 o superior cuanto antes.
Hay código de explotación circulando desde la filtración del 20 de octubre, watchTowr confirmó que el fallo es explotable, Cloudflare reportó ataques antes del parche y Sansec espera explotación masiva inmediata tras la publicación de las correcciones (los atacantes pueden deducir el fallo comparando versiones). Varios organismos públicos europeos bajaron sitios por precaución. No es momento de "esperar a ver".
Rompe las subidas de archivos legítimas mientras esté activa: formularios con adjuntos, subida de imágenes en paneles, importaciones. El resto del sitio sigue funcionando. Es un sacrificio temporal y consciente hasta completar la actualización.
Si despliegas con Nixpacks, redesplegar no basta por la instantánea fija de PHP. Aplica el bloqueo de multipart en el proxy, o mejor: añade un Dockerfile propio a tu proyecto (Coolify lo detecta automáticamente) basado en la imagen php:8.3-fpm u 8.4-fpm ya corregida, reconstruye y verifica con php -v dentro del contenedor.
PHP2Shell es de esas vulnerabilidades que separan a los equipos que reaccionan en horas de los que se enteran por las noticias de la semana siguiente. El parche ya existe: actualiza a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, y si tu entorno no te lo permite todavía, bloquea las peticiones multipart en el borde y desactiva el upload_progress de sesiones como red de seguridad temporal.
En ARCADIG HUB estamos ayudando a nuestros clientes a auditar servidores, contenedores y despliegues en Coolify frente a CVE-2026-109618 y CVE-2026-109619. Si tienes aplicaciones PHP en producción y no sabes por dónde empezar, conversemos: revisamos tu exposición y te dejamos parcheado, no solo informado.
Desarrollamos soluciones web, aplicaciones móviles e Inteligencia Artificial adaptadas a tus requerimientos.
Pioneros en desarrollo de sistemas empresariales, inteligencia artificial y plataformas cloud en República Dominicana.
PHP2Shell, un RCE en Node.js, dos CVSS 10.0 en GitLab, LiteLLM comprometido, Railway, PingCAP, eMudhra y 404,607 certificados de GoDaddy revocados: todo pasó la misma semana. Aquí está qué se rompió, si te afecta y cómo arreglarlo, con los enlaces a cada parche.
Guía 2026: las pasarelas de pago que operan en República Dominicana (Azul, CardNet, PayPal), sus requisitos, comisiones y cómo integrarlas a tu tienda online.
Qué debe tener la página web de un restaurante en RD: reservas online, menú digital, delivery propio y pagos locales para llenar tus mesas sin depender de intermediarios.
Marco legal y normativo aplicable a la contratación de servicios de desarrollo de software, inteligencia artificial y diseño digital prestados por ARCADIG HUB bajo las leyes de la República Dominicana.
Tratamiento confidencial de datos personales protegido por la Ley No. 172-13 sobre Protección de Datos de República Dominicana.
Validez legal inmediata de contratos electrónicos, presupuestos aceptados y firma digital bajo la Ley No. 126-02 de RD.
Protección estricta de propiedad intelectual, código fuente y sistemas frente a ciberdelitos según la Ley No. 53-07 de RD.
Garantía post-lanzamiento, entregables transparentes y derechos protegidos conforme a la Ley No. 358-05 de Protección al Consumidor.