viernes, 30 de octubre de 202623°General Pico · 10° / 25°Dólar Oficial $1.560Dólar Blue $1.565Dólar MEP $1.568Dólar Tarjeta $2.028
PHP publica parches para dos vulnerabilidades críticas que permiten ejecutar código en servidores
Según informó The PHP Foundation, las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos fallas críticas. La publicación se adelantó un día tras la filtración de los identificadores de las vulnerabilidades.
Redacción Pico Tecno
2 min de lectura
(lmonk72 / Wikimedia Commons · CC0)
Según informó The PHP Foundation en su blog, el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos vulnerabilidades críticas. Bajo ciertas condiciones, estas fallas permiten que un atacante sin autenticación ejecute código en servidores que usan PHP, un lenguaje de programación muy extendido para sitios web y aplicaciones. La recomendación es actualizar cuanto antes.
Ambos problemas afectan partes de PHP que casi todas las solicitudes utilizan, como la gestión de memoria y el manejo de errores. Justamente por esa centralidad, las vulnerabilidades eran graves, pero también difíciles de corregir sin romper la compatibilidad con aplicaciones existentes, afectar el rendimiento o exigir cambios en la gran cantidad de extensiones de terceros.
Un problema que tardó meses en resolverse
Uno de los fallos está vinculado a un problema de memoria agotada (conocido como OOM, por sus siglas en inglés de out of memory), identificado con el código CVE-2026-109618. CVE es el sistema estándar que asigna identificadores a vulnerabilidades conocidas. Según la fundación, el problema ya había aparecido en una auditoría de seguridad realizada en 2024, pero entonces no se hallaron vectores de explotación concretos. Los distintos enfoques de solución propuestos tenían costos, como incompatibilidades hacia atrás o nuevas posibilidades de denegación de servicio, y el equipo de seguridad, que toma decisiones por consenso, demoró en elegir uno. La propia fundación reconoce que la demora fue un fallo estructural, vinculado tanto al proceso de decisión como a la falta de recursos.
En los últimos meses cambió la organización del trabajo de seguridad. En mayo de 2026 se creó el Ecosystem Security Team, que trabaja junto al equipo de seguridad de PHP en la clasificación de reportes, la coordinación y el endurecimiento del código. Además, la fundación incorporó personal para tareas de triaje, corrección y endurecimiento, y empezó a usar herramientas de inteligencia artificial para validar reportes y analizar fallas, aunque la fundación aclara que las decisiones y los parches siguen en manos de personas.
La coordinación previa a la publicación se complicó dos días antes de la fecha prevista. El 20 de octubre, alrededor de las 15:00 UTC, los identificadores de las vulnerabilidades empezaron a circular en foros y redes sociales, con una fecha de publicación incorrecta y una puntuación de gravedad errónea de 10.0, cuando la real es 9.2. Según el texto, no se filtraron detalles técnicos. Como respuesta, el proyecto adelantó el anuncio y trasladó la publicación del 22 al 21 de octubre, porque varias distribuciones todavía estaban empaquetando la corrección y una publicación inmediata habría dejado a muchos usuarios sin una vía sencilla de actualización.
La fundación también señala otros incidentes. La firma de seguridad Calif publicó por error un video con una prueba de concepto que mostraba la explotación contra varios objetivos, aunque revelaba detalles limitados. Además, el 21 de octubre, a las 07:41 UTC, la empresa Chainguard difundió imágenes con la corrección antes de la hora acordada, rompiendo el embargo, es decir, el compromiso de no divulgar la información hasta el momento coordinado. Según la fundación, esto permitió que cualquiera estudiara el parche en su forma binaria mientras el resto de los usuarios todavía esperaba la publicación oficial. Al cierre del texto, el equipo de seguridad afirmaba no haber identificado exploits funcionales en el momento de la divulgación.
