Actualizado el 27 de octubre de 2026.
| Rama | Instala |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
¿Tienes PHP expuesto? Revisamos tu infraestructura.
Qué hacer ahora
El 21 de octubre PHP publicó el parche de seguridad para dos fallas críticas de ejecución remota de código sin autenticación: CVE-2026-109618 y CVE-2026-109619. En el preaviso del 20 de octubre PHP les asignó CVSS v4.0 de 9,2. No hay una mitigación completa.
Si no puedes actualizar de inmediato, saca de internet el sitio hasta poder hacerlo. Es la recomendación de CERT-EU. Las descargas oficiales están en php.net/downloads.
El 26 de octubre la explotación dejó de ser solo un aviso. BleepingComputer publicó el registro de un honeypot de Perplexity: ejecución remota de código contra Apache con mod_php en PHP 8.4.26. Marcus Hutchins, de Expel, la describió como la confirmación más clara hasta ahora. Es un señuelo, no el parte de un organismo ya comprometido. Alcanza para dejar de tratar los intentos como ruido.
En España, la Junta de Castilla-La Mancha empezó el viernes 24 a desconectar servicios web tras la alerta del CCN-CERT. El 26 de octubre seguía sin fecha para volver a encenderlos, y pidió al sector privado que también se proteja (ABC).
En Chile, el CSIRT de la ANCI publicó el 21 de octubre la alerta AVC26-00740 y la actualizó el 23. Además de las cuatro versiones, pide revisar los registros desde el 17 de octubre. Si la superficie es más que el runtime, empresa de ciberseguridad en Chile: pentesting y cumplimiento.
¿Qué versiones de PHP están afectadas?
Cualquier instalación que atiende peticiones web y no está en una de esas cuatro versiones. PHP nombra PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto, según PHP, es mod_php: una petición sin autenticación puede disparar el fallo antes de que corra el código de la aplicación.
PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto. Algunas distribuciones y vendors de soporte extendido publican su propio backport. Para quien compila desde el código, PHP dejó backports mínimos de las fuentes para 7.4, 8.0 y 8.1. PHP 5 queda fuera de eso. PHP 8.2 llega a fin de soporte el 31 de diciembre de 2026: este parche es de los últimos.
Quien esté en un release candidate de PHP 8.6 debe pasar al RC4, que ya incluye el arreglo, y no usarlo en producción.
Cómo saber qué versión de PHP tiene tu servidor
En el servidor, por SSH:
php -v
La primera línea dice la versión. Si hay varios binarios (el de la web y el de la consola no siempre coinciden), revisa el que usa el sitio. Un archivo temporal con phpinfo() en la raíz web muestra la versión del PHP que responde por HTTP. Bórralo en cuanto lo leas.
En WordPress no hace falta un plugin: Salud del sitio, Información, bloque Servidor. En hosting compartido, el panel suele mostrar la versión de PHP del dominio. Si no aparece, pregúntale al proveedor. Un PHP embebido en un appliance o en un software de escritorio no sale en esa pantalla.
Cómo aplicar el parche de seguridad PHP
Servidor propio
Instala el paquete de tu distribución si ya lo publicaron. Esos vendors recibieron el parche antes del anuncio. Si compilas desde la fuente, usa 8.5.12, 8.4.27, 8.3.36 o 8.2.35 desde php.net/downloads. Después reinicia PHP-FPM o Apache y vuelve a correr php -v en el binario que sirve el sitio.
Hosting compartido
Tú no eliges el tarball. Abre un ticket o cambia la versión en el selector de PHP del panel, si ya ofrece una de las versiones corregidas. Mientras el proveedor no publique el paquete, el sitio sigue expuesto.
WordPress, Drupal, Joomla o Magento
Actualizar el CMS o los plugins no cambia la versión de PHP. El parche va en el runtime del hosting o del servidor. Cuando PHP ya esté en una versión corregida, recién ahí tiene sentido seguir con el resto de actualizaciones del sitio.
¿Qué hacer si no puedes actualizar todavía?
Aislar de internet lo que no puedas parchar. CERT-EU lo dice así: si el parche no es viable de inmediato, separa las aplicaciones expuestas de la red pública hasta verificar el arreglo. Un WAF reduce ruido. No cierra estas fallas.
PHP publicó medidas de configuración temporales y avisó que no dejan la instalación segura. El 23 de octubre añadió un aviso aparte: deja session.upload_progress.enabled=0 hasta el próximo release regular, para cubrir un vector poco probable (CVE-2026-115560) que solo aplica si la aplicación cambia session.serialize_handler en tiempo de ejecución y el upload progress sigue activo. Si ya lo habías apagado por el aviso del 21, no hace falta otro cambio. El detalle está en el aviso del 23 de octubre.
Qué pasó, en orden
El 20 de octubre PHP avisó un release de seguridad para el 21 a las 14:00 UTC, por dos fallas críticas con CVSS v4.0 de 9,2. La información se filtró antes. watchTowr confirmó que las fallas eran reales. El 21 de octubre salió el aviso y los cuatro releases. CERT-EU sitúa la publicación de los parches a las 13:30 UTC y dice que ya circulan pruebas de concepto, así que es probable que haya explotación.
CVE-2026-109618 está en el manejo de una condición de memoria agotada mientras la petición todavía se está inicializando. CVE-2026-109619 está en estado interno de una petición que puede sobrevivir y reutilizarse en el mismo worker. El advisory enlaza el detalle. Aquí no se reproduce.
Sobre explotación: PHP confirmó un exploit demostrado contra mod_php. Amazon Threat Intelligence reportó un intento contra un honeypot el 17 de octubre, antes del aviso público. watchTowr dice haber visto explotación en honeypots desde el 21 de octubre. El aviso de CISA, revisado el 23 de octubre, todavía decía que no había observado explotación exitosa. El 26 de octubre BleepingComputer publicó una ejecución remota confirmada en un honeypot con PHP 8.4.26. El apodo que circula es PHP2Shell. No es un nombre de PHP.
También alertaron el NCSC del Reino Unido y el ACSC australiano.
Por qué el inventario importa más que el CMS
PHP está debajo de WordPress, Drupal, Joomla y Magento, y también de paneles, appliances y software que nadie llama "servidor web". Según W3Techs, al 23 de octubre de 2026 PHP está en el 69,3% de los sitios cuyo lenguaje de servidor se puede identificar. No es el 69,3% de toda la web: es el porcentaje entre los sitios en los que W3Techs reconoce el lenguaje.
Cuando la falla está en el lenguaje, el alcance es cada intérprete, no cada plugin. La misma semana Node.js publicó el suyo, por una falla en Brotli: qué versión de Node.js instalar.
Fuentes
- Security advisory: Critical remote code execution vulnerabilities, update now, PHP, 21 de octubre de 2026
- Informational advisory: Session upload progress, PHP, 23 de octubre de 2026
- Upcoming Critical PHP Security Release, PHP, 20 de octubre de 2026
- Critical Vulnerabilities in PHP (2026-018), CERT-EU, 21 de octubre de 2026
- Critical security issue affecting PHP, NCSC del Reino Unido
- Critical vulnerabilities in PHP, ACSC, Australia
- Usage statistics of PHP, W3Techs, 23 de octubre de 2026
- PHP - Vulnerabilidad Crítica (AVC26-00740), CSIRT Nacional de la ANCI, 21 de octubre de 2026, actualizada el 23
- PHP2Shell security flaws now successfully exploited in the wild, BleepingComputer, 26 de octubre de 2026
- La Junta garantiza los plazos administrativos tras apagar servicios web, ABC, 26 de octubre de 2026
- Critical Vulnerabilities in PHP Require Immediate Patching, CISA, revisado el 23 de octubre de 2026
Preguntas frecuentes
¿Qué versión de PHP debo instalar?
La de tu rama: PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. En Linux mira primero el paquete de tu distribución. PHP 8.1 y anteriores ya no reciben un release del proyecto.
¿Actualizar WordPress o los plugins corrige el parche de seguridad PHP?
No. WordPress corre sobre PHP, pero la versión de PHP la pone el servidor o el hosting. Hay que actualizar el runtime, no solo el CMS.
¿Hay explotación activa de estas fallas?
El 26 de octubre BleepingComputer documentó ejecución remota de código en un honeypot con PHP 8.4.26 y mod_php. Antes, Amazon vio un intento el 17 de octubre y watchTowr reportó actividad en honeypots desde el 21. El aviso de CISA del 23 de octubre todavía decía que no había visto explotación exitosa.
¿Qué hago si mi hosting todavía no publicó el paquete?
Pide el paquete y, mientras tanto, aísla de internet lo que no puedas parchar. CERT-EU lo recomienda así. Un WAF no reemplaza la actualización.