Aviso de seguridad de PHP · 21/10/2026Aviso PHP · 21/10/2026
Krauser Cybersecurity · Seguridad de aplicaciones
Las vulnerabilidades recientes de PHP refuerzan la importancia de mantener aplicaciones, dependencias e infraestructura actualizadas. En Krauser evaluamos riesgos, identificamos problemas de seguridad y te ayudamos a definir un plan de corrección.
La primera conversación no tiene costo. La evaluación técnica se cotiza según el alcance.
Versión: 8.1.xEstado: Rama sin soporte del proyectoVersión: 8.3.36Estado: Versión corregidaVersión: a relevarEstado: Compatibilidad a validarVersión: composer.lockEstado: Con avisos publicadosVersión: php:8.1-fpmEstado: A reconstruirVersión: Apache · mod_phpEstado: Configuración a revisarDatos ficticios para mostrar cómo se ordena un relevamiento. Esta página no analiza ningún sistema.
Actualidad · 21/10/2026
El 21 de octubre de 2026, el equipo de PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen CVE-2026-109618 y CVE-2026-109619. Según el aviso oficial, pueden permitir la ejecución remota de código sin autenticación en instalaciones que atienden pedidos web.
Aviso de seguridad del 21 de octubre de 2026 en php.net (se abre en otra pestaña)
Información revisada el 23 de octubre de 2026 contra las fuentes oficiales.
PHP-FPMApache con mod_phpphp-cgiFrankenPHPLiteSpeedEl aviso considera mayor el riesgo con Apache con mod_php.
CVE-2026-109618
Si PHP se queda sin memoria mientras los datos internos de un pedido están a medio inicializar, la limpieza del pedido puede tratarlos como válidos.
Detalle técnico: GHSA-w8hw-w9fx-j79w (se abre en otra pestaña)
CVE-2026-109619
Información interna de un pedido puede sobrevivir a la liberación de su memoria, y un pedido posterior que atienda el mismo proceso puede usarla antes de que se reinicie.
Detalle técnico: GHSA-6wmf-4rv5-p3rp (se abre en otra pestaña)
| Rama | Versión corregida |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35Recibe correcciones de seguridad hasta el 31 de diciembre de 2026. |
| PHP 8.1 y anteriores | Sin versión del proyectoFuera de soporte. Consultá a tu proveedor por correcciones retroactivas. Para quienes compilan, el equipo de PHP publicó adaptaciones mínimas del código fuente para 7.4, 8.0 y 8.1. |
Aplicá la versión corregida o el paquete actualizado de tu proveedor (distribución, hosting o imagen de contenedor) y confirmá que los servicios de PHP se reiniciaron con ella. Según el aviso, las mitigaciones temporales reducen la exposición pero no vuelven segura una instalación. Una auditoría complementa la actualización: no la reemplaza.
Las distribuciones y los proveedores con soporte extendido incorporan las correcciones en sus propios paquetes, a veces sin cambiar a la numeración del proyecto. Para saber si un servidor está corregido, revisá el aviso de seguridad de tu proveedor, no solo lo que muestra php -v.
PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto: ni por este aviso ni por los próximos. Si tu proveedor no ofrece correcciones retroactivas, conviene planificar la actualización a una rama con soporte.
Actualizar el intérprete puede afectar extensiones, configuraciones y código heredado. Conviene probar primero en un entorno de staging y verificar que la versión corregida sea la que efectivamente atiende los pedidos, no solo la de la consola.
El equipo de PHP sugirió además configurar session.upload_progress.enabled=0 hasta la próxima versión regular, por un vector poco probable (CVE-2026-115560) que solo aparece con una combinación inusual de configuración y código. Ese ajuste ya figuraba entre las mitigaciones del aviso del 21 de octubre: si lo aplicaste, no hace falta nada más.
Ver el aviso complementario en php.net (se abre en otra pestaña)
Las vulnerabilidades son del intérprete PHP, no de frameworks como Laravel, Symfony o Yii ni de plataformas como WordPress: las aplicaciones construidas con ellos dependen de la versión de PHP del servidor donde corren. Y el aviso no significa que todos los sistemas PHP estén comprometidos: significa que hay que verificar versiones y aplicar las correcciones.
Qué evaluar
Los que sostienen la operación y están expuestos a internet o a otros sistemas. En cada uno, una evaluación ordena qué riesgos existen y qué conviene corregir primero.
¿Tu sistema no está en la lista?
Contanos cuál es y en qué tecnología está hecho: lo vemos en la primera conversación.
Cómo ayudamos
Las capacidades de Krauser Cybersecurity que más se usan frente a un aviso como este. Cada evaluación combina las que correspondan a tu caso.
Inventario de intérpretes, frameworks, librerías e imágenes de contenedores, contrastado con los avisos de seguridad publicados.
Dentro de Seguridad de código y aplicaciones
Exposición, autenticación, permisos y configuración de cada aplicación y de las APIs que usa o publica.
Dentro de Auditorías de seguridad
Lectura del código para encontrar vulnerabilidades y prácticas inseguras, con el acceso al repositorio que acordemos.
Dentro de Seguridad de código y aplicaciones
Servidores web, PHP-FPM, contenedores, configuraciones cloud, accesos y gestión de secretos.
Dentro de Seguridad cloud e infraestructura
Pruebas de penetración de alcance definido, siempre con la autorización expresa y por escrito del propietario del sistema.
Dentro de Penetration Testing
Pasos de corrección concretos, acompañamiento a tu equipo o a tu proveedor y revalidación de lo corregido.
Dentro de Seguridad continua
El alcance, la profundidad y el precio se definen en cada contratación: una evaluación inicial no incluye de por sí todas estas actividades.
Metodología
Cada evaluación sigue el mismo recorrido. Lo que cambia es el alcance, y lo definimos juntos antes de empezar.
Entendemos qué sistemas usan PHP, dónde corren, quién los mantiene y qué te preocupa.
Resultado: Sistemas y objetivos
Acordamos qué se evalúa, con qué tipo de prueba, en qué horarios y qué queda afuera.
Resultado: Alcance por escrito
Sin autorización expresa y por escrito del propietario del sistema no empieza ninguna prueba.
Resultado: Autorización por escrito
Los especialistas ejecutan las revisiones acordadas, sin salir del alcance, y validan cada posible hallazgo.
Resultado: Hallazgos validados
Un informe ejecutivo para la dirección y otro técnico para tu equipo, con evidencia y prioridades.
Resultado: Informe ejecutivo y técnico
Acompañamos las correcciones y, si lo acordamos, revalidamos lo corregido.
Resultado: Correcciones revalidadas
Ninguna evaluación puede asegurar que un sistema no tiene vulnerabilidades. Lo que sí podemos asegurar es un trabajo dentro del alcance autorizado, hallazgos validados y recomendaciones que tu equipo pueda aplicar.
Entregables
Según el alcance contratado, la evaluación termina con información para decidir y un plan para corregir.
Resumen ejecutivo
El nivel de riesgo y las prioridades, en el lenguaje de la dirección.
Inventario de riesgos relevantes
Qué sistemas, versiones y componentes requieren atención.
Hallazgos técnicos validados
Cada hallazgo comprobado, con su evidencia, para descartar falsos positivos.
Priorización por severidad e impacto
Qué corregir primero según el riesgo para tu operación.
Recomendaciones concretas
Pasos de corrección que pueda aplicar tu equipo o tu proveedor.
Propuesta de próximos pasos
Actualizaciones, revalidación o un programa de seguimiento, si corresponde.
Los entregables dependen del alcance de cada evaluación.
Resumen ejecutivo
La aplicación principal corre sobre una rama de PHP sin soporte del proyecto y dos componentes tienen avisos de seguridad publicados. Se recomienda actualizar primero el entorno de producción y revalidar antes del próximo lanzamiento.
| Hallazgo | Severidad | Prioridad |
|---|---|---|
| El servidor de producción usa una rama de PHP sin soporteEntorno PHP | Alta | 1 |
| Un endpoint de la API no valida los permisos de cada usuarioAPI | Alta | 1 |
| Una dependencia de Composer tiene un aviso de seguridad publicadoDependencias | Media | 2 |
| El panel de administración es accesible desde cualquier redAplicación | Media | 2 |
| Los errores detallados se muestran en producciónConfiguración | Baja | 3 |
Próximos pasos sugeridos
Datos ficticios. Los hallazgos reales dependen del alcance de cada evaluación.
Quiénes somos
Krauser es una software factory argentina, con sede en Viedma, Río Negro, que desde 2020 desarrolla sistemas de gestión, integraciones e infraestructura cloud. Krauser Cybersecurity suma esa experiencia a cada evaluación: entendemos cómo se construye, se despliega y se mantiene el software que revisamos.
Krauser forma parte de la OpenAI Daybreak Defense Network y está autorizada a ofrecer servicios comerciales que incorporan sus capacidades de ciberdefensa. La inteligencia artificial amplía lo que nuestros especialistas pueden investigar; ellos definen el alcance, validan cada hallazgo y responden por el informe.
OpenAI y el logotipo de OpenAI son marcas comerciales o marcas registradas de OpenAI. Daybreak es un programa de OpenAI.
Preguntas frecuentes
¿Tenés otra pregunta? Contanos tu caso y la respondemos en la primera conversación.
No de la misma forma. Según el aviso del 21 de octubre de 2026, alcanzan a las instalaciones de PHP que atienden pedidos web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed) con versiones anteriores a las corregidas, y el riesgo es mayor con Apache con mod_php. Eso no quiere decir que esos sistemas estén comprometidos: quiere decir que conviene verificar la versión o el paquete instalado y actualizar. Son vulnerabilidades del intérprete, no de frameworks como Laravel, Symfony o Yii ni de WordPress.
Esas ramas ya no reciben actualizaciones del proyecto PHP, así que no tienen una versión oficial corregida. Algunas distribuciones y proveedores de soporte extendido publican correcciones retroactivas: lo primero es consultarle al tuyo. Para quienes compilan PHP desde el código fuente, el equipo de PHP publicó adaptaciones mínimas para 7.4, 8.0 y 8.1; el aviso no incluye adaptaciones para versiones anteriores. Más allá de este aviso, una rama sin soporte no va a recibir las correcciones futuras, por eso conviene planificar la actualización. Podemos ayudarte a evaluar la compatibilidad y el orden de los cambios.
No. Las correcciones son del intérprete PHP: se aplican actualizando PHP o el paquete de tu proveedor, sin cambiar de framework. Lo que sí puede pasar es que una versión vieja de tu framework no sea compatible con una rama de PHP con soporte; en ese caso conviene actualizar el framework dentro de su misma familia, con pruebas. Migrar a otra tecnología es una decisión aparte, que se justifica por otros motivos.
Son cosas distintas y se complementan. Frente a este aviso, lo prioritario es aplicar la versión o el paquete corregido: ninguna auditoría reemplaza eso. La auditoría responde otras preguntas: si la actualización quedó bien aplicada, qué otros componentes están desactualizados y si la aplicación tiene problemas propios, como permisos mal controlados o configuraciones inseguras, que ninguna actualización de PHP corrige.
Sí, siempre que quien es titular del sistema autorice la evaluación por escrito. Si lo mantiene un proveedor, conviene sumarlo desde el principio: facilita los accesos y las correcciones. Si intervienen servicios de terceros, como un hosting o una nube, también se respetan sus condiciones.
No es obligatorio. Se puede evaluar sin acceso al código, desde afuera y con información limitada, o con acceso al repositorio, que permite una revisión más profunda. Lo definimos en el alcance. El código nunca se manda por el formulario: si hace falta, acordamos un canal seguro.
La auditoría revisa en amplitud: versiones, configuraciones, permisos y controles de un entorno. El pentesting simula, de forma controlada y con autorización expresa, lo que intentaría un atacante, para comprobar qué debilidades se pueden aprovechar y hasta dónde. Se complementan: muchas evaluaciones empiezan por una auditoría y suman pruebas de penetración sobre lo más expuesto.
La primera conversación, en la que relevamos tu caso y definimos qué conviene evaluar, no tiene costo. La evaluación técnica profesional se cotiza según el alcance: cantidad de sistemas, tipo de prueba, profundidad y plazos. Antes de empezar recibís una propuesta con el alcance y el precio.
Acordamos la confidencialidad antes de empezar y pedimos solo los accesos necesarios, con cuentas de prueba y permisos mínimos cuando es posible. Las credenciales, el código y la evidencia se intercambian por un canal seguro que definimos juntos, nunca por el formulario, por WhatsApp ni por correo sin cifrar, y los accesos se revocan al terminar. La información se usa solo para la evaluación, y los datos del formulario se tratan según nuestra política de privacidad.
Próximo paso
Contanos qué sistemas usan PHP en tu empresa y te ayudamos a definir qué conviene revisar primero.
Solicitud
Contanos qué sistema querés revisar. Te contactamos para la primera conversación, que no tiene costo.
Qué pasa después
Si para evaluar hacen falta accesos, credenciales o código, los pedimos por un canal seguro, una vez acordado el alcance.
¿Preferís otro canal? WhatsApp (se abre en otra pestaña) · contacto@krauser.com.ar
Atendemos de lunes a viernes, de 9 a 18.