PHP está presente en una parte importante de la web y trabaja detrás de escena: procesa las solicitudes que llegan al servidor y permite que funcionen sitios, aplicaciones y sistemas de publicación como WordPress. Por eso, una falla en el lenguaje puede tener consecuencias amplias para quienes administran páginas y para los proveedores que mantienen la infraestructura.
El 21 de octubre, el equipo de PHP publicó una alerta por dos vulnerabilidades críticas, identificadas como CVE-2026-109618 y CVE-2026-109619. Según el aviso oficial, bajo determinadas condiciones ambas podían permitir la ejecución remota de código sin autenticación. Una de las fallas se relaciona con el manejo de memoria cuando PHP se queda sin recursos; la otra, con datos internos que pueden permanecer disponibles después de que su memoria fue liberada. La calificación informada fue de 9,2 sobre 10 en CVSS 4.0. La alerta no significa que todos los sitios hayan sido atacados: describe el riesgo técnico para las instalaciones afectadas. Fuente: https://www.php.net/archive/2026.php
El aviso señala como afectadas a las instalaciones de PHP que procesan solicitudes web, con diferencias según la configuración y el modo en que el servidor ejecuta el lenguaje. El equipo de PHP advirtió que el riesgo era especialmente alto en algunas configuraciones de Apache con mod_php. La publicación también remarcó que las versiones antiguas que ya no reciben mantenimiento del proyecto pueden depender de parches preparados por el proveedor del sistema operativo o del hosting.
Para las ramas con soporte activo, PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. La recomendación fue actualizar cuanto antes. En servidores administrados, la instalación del parche suele depender del proveedor; por eso, que el número de versión visible no cambie no alcanza por sí solo para confirmar si un servidor recibió o no una corrección. Algunos proveedores aplican parches retroactivos —backports— y conservan el número menor de versión. El aviso oficial de PHP indica además que las versiones 8.1 y anteriores ya no reciben actualizaciones regulares del proyecto, aunque ciertos distribuidores pueden ofrecer correcciones propias.
La respuesta de seguridad también tuvo efectos visibles en funciones cotidianas. Mientras se distribuían los parches, proveedores de infraestructura aplicaron medidas preventivas relacionadas con solicitudes multipart, utilizadas, entre otras cosas, para enviar archivos desde formularios. En algunos sitios, esas protecciones pudieron coincidir con errores al adjuntar imágenes o documentos, guardar contenido o enviar formularios. CloudLinux describió en su página de estado medidas temporales y el proceso de publicación de paquetes corregidos: https://cloudlinux.statuspage.io/
WNPower informó que aguardaba la publicación de los paquetes de cPanel y CloudLinux y que, una vez disponibles, su equipo aplicaría las acciones necesarias. El estado del incidente se marcó como resuelto el 21 de octubre a las 20:58, hora argentina. El proveedor aclaró que sus versiones corregidas podían conservar números menores distintos de los publicados por PHP porque se trataba de parches retroactivos. Entre las compilaciones informadas figuraban ea-php84 8.4.26-2 y ea-php83 8.3.35-2, entre otras. El seguimiento del proveedor puede consultarse en https://status.wnpower.com/
En Free Media Argentina, durante esa ventana se registraron respuestas 403 Forbidden al intentar guardar publicaciones desde el área de redacción. Los registros mostraron rechazos a solicitudes de WordPress y al formulario de PNA. El hecho de que el error también apareciera al publicar texto sin adjuntar una imagen hizo necesario distinguir entre el problema de carga de archivos y el rechazo de la solicitud completa de guardado. Un 403 indica que la petición fue denegada, pero por sí solo no identifica qué regla o componente la bloqueó.
La secuencia de esos días muestra cómo una actualización urgente puede involucrar varias capas: el código de PHP, los paquetes que distribuye el sistema del hosting, las reglas de seguridad y los formularios de cada sitio. Para quienes usan un plan administrado, la actualización del servidor puede quedar a cargo del proveedor; ante un error persistente al publicar, conviene guardar el texto fuera del formulario, anotar la hora y el tipo de operación que falló, y conservar el mensaje exacto para poder identificar qué componente respondió. La recomendación de seguridad de PHP sigue siendo usar una versión corregida y consultar al proveedor cómo se aplicó el parche en cada entorno.
FREE MEDIA ARGENTINA · EDICIÓN N.º 22 · 22/10/2026
COMENTÁ LA NOTICIA
Lo siento, debes estar conectado para publicar un comentario.