Una petición. Sin login. Tu servidor PHP. Actualiza hoy.
El 21 de octubre de 2026, PHP corrigió dos fallas críticas en su motor. Juntas permiten ejecutar código en un servidor PHP con una sola petición sin autenticación. WordPress, Drupal, Joomla, Magento y la mayoría de las apps PHP quedan expuestas hasta que se actualiza el servidor.
PHP2Shell en cifras
- 9.2 severidad CVSS v4.0 de ambos CVE
- 0 logins o fallas de la app necesarios
- 5.4+ versiones afectadas desde 2012
- ~70% de los sitios web usan PHP
Fuentes: aviso de seguridad de PHP y Wiz Research, 21 oct 2026.
Semanas de trabajo discreto. Luego, un día para actualizar.
Investigadores de Calif y de Wiz encontraron las fallas por separado y las reportaron al equipo de seguridad de PHP. La corrección y los detalles públicos salieron el mismo día. CVE-2026-109618 y CVE-2026-109619 tienen severidad 9.2.
Ago 2026 — Hallazgo
Calif y Wiz Research encuentran, cada uno por su lado, fallas de memoria en cómo PHP maneja los errores fatales. Wiz confirma ejecución remota sin autenticación en Drupal y WordPress en dos días.
24 ago 2026 — Reporte
Wiz reporta sus hallazgos al equipo de seguridad de PHP y se suma a la divulgación coordinada que Calif inició el 11 de agosto.
21 sep 2026 — Corrección en curso
PHP confirma los reportes y arranca una corrección coordinada con distribuciones de Linux y proveedores LTS.
20 oct 2026 — Aviso previo
PHP anuncia una versión crítica para el día siguiente. Empiezan a filtrarse detalles.
21 oct, 07:43 UTC — Empiezan los ataques
Cloudflare reporta tráfico de ataque contra sus clientes, horas antes de que el parche sea público.
21 oct, 14:00 UTC — Parche y divulgación
PHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Wiz, Calif y otros publican su investigación.
Estatus de explotación al 21 de octubre: Cloudflare reportó tráfico de ataque. El equipo de PHP dijo no haber identificado exploits funcionales al publicar. CERT-EU dice que ya circulan pruebas de concepto. Ningún CVE está aún en el catálogo KEV de CISA. Trata cada servidor PHP expuesto a internet como urgente.
La falla está en PHP, no en tu código.
Puedes tener un WordPress o una app Laravel limpia y actualizada y aun así estar expuesto. El ataque ocurre mientras PHP prepara la petición, antes de que corra tu aplicación.
01 Una sola petición
El atacante envía una petición de carga de archivos manipulada a cualquier página PHP. Sin login, sin plugin, sin falla de la app.
PHP sin actualizar
02 Forzar un error fatal
La petición lleva a PHP más allá de su límite de memoria mientras aún arma los datos internos de la petición.
Manejo de falta de memoria
03 Dejar estado viejo
PHP libera memoria pero conserva punteros a ella. La siguiente petición en el mismo worker reutiliza ese estado.
Use-after-free
04 Filtrar memoria
Una ruta devuelve memoria del worker en una cookie de sesión: contraseñas, tokens, llaves de API y llaves TLS de otras peticiones.
Secretos expuestos
05 Ejecutar código
Encadenadas, las fallas dieron a los investigadores ejecución de código sin autenticación en WordPress, Drupal, Joomla, Magento y más.
Control total del servidor
Si corre PHP y no está en estas versiones, sí.
En riesgo: toda instalación de PHP que atiende peticiones web, incluidos PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera mod_php el de mayor riesgo.
| Rama de PHP | Corregido en | Notas |
|---|---|---|
| 8.5 | 8.5.12 | Si aún no actualizas, configura también fatal_error_backtraces=0. |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | La rama termina soporte el 31 dic 2026. Planea la migración. |
| 8.1 y anteriores | Sin corrección oficial | PHP publicó backports mínimos de código para 7.4, 8.0 y 8.1. Pregunta a tu proveedor o migra. |
Revisa lo que corre el servidor web, no la línea de comando.
El comando php -v muestra la versión de línea de comando. Tu sitio puede correr otra versión de PHP-FPM. Revisa el binario de FPM, o una verificación servida por el servidor web, en cada equipo.
Actualizar WordPress, plugins o tu framework no lo corrige. El modo mantenimiento tampoco ayuda, porque PHP procesa la petición antes de que tu app revise esa opción.
Actualiza, reinicia y verifica.
En este orden. Primero los servidores expuestos a internet.
Actualiza cada instalación de PHP
Sube a 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Incluye versiones que tus sitios no usan, contenedores, appliances y paneles de control. Si tienes hosting administrado, pide a tu proveedor la versión y la fecha del parche.
Reinicia todo
PHP-FPM, Apache y los procesos de larga duración, como colas, mantienen el PHP viejo en memoria hasta que se reinician.
Verifica lo que está corriendo
Confirma la versión que sirve el servidor web en cada equipo, no solo la de línea de comando.
¿No puedes actualizar hoy? Reduce la exposición
Pasos interinos de PHP: memory_limit=-1 con un post_max_size bajo, y session.upload_progress.enabled=0 en php.ini o en el pool de FPM, y reinicia los workers. Activa la regla PHP2Shell de tu CDN o WAF. Esto baja el riesgo. No te deja seguro.
Busca señales de compromiso
Procesos PHP que abren shells, curl o wget. Archivos nuevos en el directorio web, cron jobs o cuentas nuevas. Errores 500 repetidos, errores de límite de memoria tras peticiones de carga, cookies PHPSESSID anormalmente grandes.
Rota secretos en servidores expuestos
La fuga de memoria puede exponer contraseñas, llaves de API, tokens de sesión y llaves privadas TLS. Si un servidor estuvo expuesto antes del parche, rótalos.
Solo una actualización es una solución completa.Equipo de seguridad de PHP, 21 oct 2026
Encontramos cada servidor PHP, lo actualizamos y revisamos que nadie haya entrado antes.
Nuestros ingenieros trabajan con tu equipo, con tu autorización y dentro de un alcance acordado. Recibes la lista de cada sistema expuesto, qué se actualizó o mitigó y una respuesta clara sobre compromiso.
Inventario de PHP
Cada servidor, contenedor, appliance y sitio hospedado que corre PHP, incluidos los que nadie recuerda.
Versión y reinicio
La versión que realmente corre el servidor web, comparada con las versiones corregidas.
Actualizar o mitigar
Actualizamos con tu equipo, o aplicamos las mitigaciones interinas de PHP y reglas en el borde donde el parche tenga que esperar.
Revisión de compromiso
Directorios web, cron jobs, cuentas e historial de procesos revisados en busca de webshells y persistencia.
Plan de rotación de secretos
Qué contraseñas, llaves de API, tokens y certificados rotar, y en qué orden.
Plan de fin de soporte
Una ruta para dejar PHP 8.1 y anteriores, y 8.2 antes de que termine su soporte el 31 dic 2026.
Cómo empieza
Llamada de 30 minutos
Un ingeniero de seguridad revisa tu huella de PHP y tu hosting.
Alcance
Acordamos sistemas, accesos y tiempos.
Parche y reporte
Sistemas actualizados o mitigados, hallazgos de compromiso y siguientes pasos.
Cinco preguntas. Con honestidad.
Responde por tu empresa hoy. No se envía nada.
- Conocemos cada servidor, contenedor y sitio hospedado que corre PHP, incluidos sitios WordPress y appliances.
- Todos corren PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o posterior.
- Reiniciamos PHP-FPM, Apache y los workers de PHP de larga duración después de actualizar.
- Ninguno de nuestros sitios corre PHP 8.1 o anterior.
- Notaríamos en horas un proceso PHP abriendo una shell o un archivo nuevo en un directorio web.
0 de 5 respondidas.
Lo que más nos preguntan.
¿WordPress, Drupal, Joomla o Magento están afectados?
Sí, si corren sobre un PHP sin actualizar. La falla está en PHP, así que la versión del CMS no importa. Los investigadores confirmaron ejecución de código sin autenticación en los cuatro.
¿Actualizar WordPress o los plugins lo corrige?
No. Hay que actualizar y reiniciar el PHP del servidor. Si tienes hosting administrado, pide a tu proveedor que confirme la versión de PHP y cuándo la actualizó.
¿Ya lo están explotando?
Cloudflare reportó tráfico de ataque el 21 de octubre, horas antes de que el parche fuera público. CERT-EU dice que ya circulan pruebas de concepto. Prioriza los servidores PHP expuestos a internet.
Usamos PHP 7.4 u 8.1. ¿Qué hacemos?
No hay versión oficial. PHP publicó backports mínimos de código para 7.4, 8.0 y 8.1, y algunos proveedores de Linux ofrecen paquetes con el parche. La solución real es una versión con soporte. Mientras tanto, aplica las mitigaciones interinas y limita la exposición.
¿Nuestro WAF o CDN nos protege?
En parte. Cloudflare, AWS, Google, Microsoft, Akamai, Fastly y otros publicaron guías o mitigaciones. Reducen el riesgo mientras actualizas. La actualización es la única solución completa.
¿Trabajan en México y en Estados Unidos?
Sí. iNBest tiene ingenieros en México y Estados Unidos y trabaja en español e inglés.
Fuentes
- Wiz Research: PHP2Shell, critical RCE in PHP (Oct 21, 2026)
- PHP: Security advisory, critical remote code execution vulnerabilities (Oct 21, 2026)
- Sansec: PHP2Shell (CVE-2026-109618, CVE-2026-109619)
- Laravel Forge: PHP security advisory, patching steps
- Rescana: fixed versions, mitigations and exploitation status
- SOCRadar: PHP2Shell exposure and detection
Actualiza hoy. Luego confirma que nadie entró antes.
Agenda 30 minutos con un ingeniero de seguridad. Te ayudamos a encontrar cada servidor PHP, actualizarlo o mitigarlo, y revisar señales de compromiso.
Envíanos tu contexto.
Un ingeniero de seguridad responderá con un siguiente paso práctico.