En resumen: las vulnerabilidades de PHP se notifican de forma confidencial, de preferencia mediante el formulario privado de advisories del repositorio de GitHub php/php-src y, como alternativa, a security@php.net. Los desarrolladores de PHP clasifican el hallazgo como alto, medio o bajo; los fallos graves se corrigen en un repositorio de seguridad separado y solo se publican con la versión, junto con un GitHub Security Advisory y, normalmente, un número CVE. En PHP2Shell este proceso se desarrolló a toda velocidad: preaviso el 20/10/2026, parches el 21/10/2026 y nota complementaria el 23/10/2026.
Quién se ocupa de la seguridad en PHP
PHP es un proyecto de código abierto. La política de seguridad del wiki lo describe como un proyecto de voluntarios sin presupuesto para recompensas. Para cada versión hay release managers que responden de las publicaciones. A ello se suma la PHP Foundation que, según su propia descripción, financia a un equipo de desarrolladores a tiempo parcial y completo que trabaja en el mantenimiento, la seguridad y las nuevas funciones de PHP.
Para las empresas significa que no hay un fabricante con contrato, línea de atención o tiempos de respuesta garantizados. Quien necesita compromisos vinculantes los obtiene de su distribución de Linux, de su proveedor de hosting o de un proveedor de soporte a largo plazo, no del propio proyecto PHP. Conviene conocer esta cadena de suministro.
Cómo se notifica una vulnerabilidad
El camino está descrito en la política de seguridad de GitHub:
- Notificar: mediante el formulario privado de Security Advisories del repositorio
php/php-src. Quien no pueda usarlo o quiera tratar un asunto que no es un informe de error escribe a security@php.net. - Describir brevemente: se desea un ejemplo breve que muestre el fallo, no un informe largo sobre las posibles consecuencias. Así el equipo puede revisarlo antes.
- Confidencialidad: la notificación permanece privada hasta su publicación.
- Mención: a quienes notifican se les cita como colaboradores según el sistema de créditos de MITRE.
La página más antigua del wiki menciona además el rastreador de errores clásico con el tipo «Security». Hoy es determinante la vía a través de GitHub.
Qué considera el proyecto PHP una vulnerabilidad de seguridad
No todo fallo es una vulnerabilidad de seguridad. El wiki menciona cuatro criterios: un error permite acciones no autorizadas, rebasa límites de seguridad, abre el acceso a datos ajenos o perjudica gravemente la disponibilidad o el rendimiento. La clasificación se hace en tres niveles:
| Nivel | Significado según la política | Número CVE |
|---|---|---|
| Alto | terceros pueden comprometer la mayoría de las instalaciones, ejecutar código o leer archivos | por lo general sí |
| Medio | efecto similar, pero solo en condiciones menos frecuentes, por ejemplo una extensión o configuración poco habitual | casi siempre sí |
| Bajo | teóricamente posible, en la práctica muy difícil de explotar | casi siempre no |
Igual de reveladora es la lista de lo que expresamente no es una vulnerabilidad de seguridad: código malicioso que se ejecuta a propósito, elusiones de open_basedir y disable_functions, entradas maliciosas enviadas a unserialize(), el uso de FFI y una interrupción normal por memoria en la que actúa memory_limit y solo termina la petición actual. Para los operadores significa: disable_functions es un refuerzo útil, pero no una muralla de protección.
De la corrección a la publicación
Según el wiki, las correcciones de las vulnerabilidades altas y medias se incorporan en un repositorio de seguridad separado antes de crear la versión. Los fallos clasificados como bajos siguen el curso de las correcciones de errores normales. La vulnerabilidad se publica según el principio de divulgación responsable: primero la corrección, después los detalles. Según el wiki, las versiones suelen salir los jueves, con frecuencia dentro de las publicaciones mensuales regulares.
Con la versión aparece un GitHub Security Advisory con identificador propio (GHSA) y nivel de gravedad. En el repositorio, por ejemplo, el 24/09/2026 aparecieron varios advisories sobre stream wrappers, FastCGI y filtros, con niveles de gravedad de bajo a alto. Los paquetes de código fuente de php.net se ofrecen con sumas de verificación SHA-256 y firmas GPG de los release managers; las etiquetas de Git están firmadas. Qué ramas de versiones siguen recibiendo correcciones de seguridad lo muestra la página sobre las versiones de PHP y el ciclo de versiones.
PHP2Shell como ejemplo de un caso grave
PHP2Shell muestra cómo transcurre el proceso bajo presión:
- 20/10/2026: php.net anuncia una versión de seguridad crítica para el 21/10/2026 a las 14:00 UTC y se reserva la posibilidad de publicar antes si los detalles se hacen públicos o aparecen ataques. Según varios informes, los detalles se habían conocido realmente antes de que expirara el plazo; los antecedentes los explica Por qué se conoció la vulnerabilidad de PHP antes del parche.
- 21/10/2026: salen PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, junto con los advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) y GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), ambos clasificados como críticos. Según php.net, las distribuciones de Linux y los proveedores de soporte a largo plazo habían recibido las correcciones por adelantado. Para 7.4, 8.0 y 8.1 hay backports mínimos.
- 23/10/2026: una nota informativa sobre CVE-2026-115560 recomienda
session.upload_progress.enabled=0; el advisory completo seguirá con la próxima versión.
Qué deben deducir los operadores
- Suscribirse a las fuentes: php.net, los advisories de GitHub de
php/php-srcy los avisos de seguridad de su distribución. - Conocer la cadena de suministro: ¿quién suministra su paquete de PHP y con qué rapidez llegan allí los backports?
- Planificar la ventana de tiempo: las versiones críticas pueden salir fuera del ritmo habitual; debe ser posible abrir una ventana de parcheo con poca antelación.
- Prever el reinicio: una actualización solo surte efecto cuando se han reiniciado todos los procesos de PHP.
- Asegurar la prueba: documentar la versión, el estado del paquete y el momento.
¿Cómo ayuda PHP SOS en concreto?
Con el servicio de parches de PHP asumimos la parte que corresponde a usted:
- Seguir los avisos: observamos php.net, los advisories y los avisos de las distribuciones y valoramos si sus sistemas están afectados.
- Aplicar el parche: actualización desde la fuente adecuada, reinicio de todos los procesos y control de la versión en ejecución.
- Asegurar la transición: donde la actualización se atasca, aplicamos las medidas provisionales oficiales.
- Documentar: recibirá un justificante con las versiones, los estados de los paquetes y los momentos.
Preguntas frecuentes
¿Cómo se notifica una vulnerabilidad de PHP?
De preferencia mediante el formulario privado de Security Advisories del repositorio de GitHub php/php-src. Quien no pueda usarlo escribe a security@php.net. La notificación permanece confidencial hasta su publicación.
¿Paga el proyecto PHP una recompensa por las vulnerabilidades encontradas?
No. Según la política de seguridad, PHP es un proyecto de voluntarios sin dinero para bug bounties. Pero a quienes notifican se les cita como colaboradores.
¿Es una vulnerabilidad de seguridad eludir disable_functions?
Según la política del proyecto PHP, no. Las elusiones de open_basedir y disable_functions no se consideran un problema de seguridad de PHP. Los ajustes son refuerzo, pero no un límite de seguridad fiable.
¿Dónde me entero de nuevas vulnerabilidades de PHP?
En la página de inicio de php.net, con los avisos de versiones, y en los Security Advisories del repositorio de GitHub php/php-src. Quien obtiene PHP de su distribución sigue además los avisos de seguridad de esta.
¿Por qué se publicó PHP2Shell un miércoles?
Según el wiki, las versiones suelen salir los jueves. Para PHP2Shell, php.net anunció el 20/10/2026 una versión de seguridad para el miércoles 21/10/2026 a las 14:00 UTC y se reservó la posibilidad de publicar antes si los detalles se hacían públicos.