En la reciente conferencia KubeCon + CloudNativeCon Norteamérica 2026, el cofundador y director técnico de Chainguard, Matt Moore, defendió la controvertida decisión de su empresa de lanzar imágenes parcheadas de PHP con antelación a la liberación oficial acordada con otros socios de seguridad.
La polémica surgió cuando Chainguard distribuyó estas imágenes corregidas más de seis horas antes del aviso conjunto previsto para el 21 de octubre. Los responsables de PHP criticaron duramente esta acción, señalando que dio a los atacantes una ventaja para analizar y aprovechar las correcciones antes que la mayoría de usuarios. Sin embargo, Chainguard sostiene que los ciberdelincuentes ya estaban explotando activamente o intentando aprovechar estas vulnerabilidades, lo que justificó su movimiento.
En una entrevista con The New Stack, Moore afirmó: “Asumimos completamente la responsabilidad por nuestra decisión. Nadie nos obligó, pero tampoco actuamos sin consultar.” Explicó que, durante el periodo del embargo, otros participantes en el acuerdo y firmas de seguridad habían informado de actividad maliciosa dirigida a estas vulnerabilidades. 
Estas dos fallas, conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619), afectan directamente la gestión de memoria y el manejo de errores en PHP. Bajo ciertas condiciones, permiten que un atacante ejecute código arbitrario en un servidor PHP sin autenticación previa, un riesgo grave para millones de aplicaciones web en todo el mundo.
Los errores consisten en un fallo por agotamiento de memoria que puede dejar datos internos incompletos y un estado global obsoleto donde se mantienen referencias a memoria liberada. Ambas situaciones abren puertas para que atacantes comprometan el sistema, lo que se demostró en diferentes entornos, incluyendo servidores Apache con mod_php y PHP-FPM.
Gravedad y alcance de las vulnerabilidades
PHP calificó ambas vulnerabilidades con un nivel crítico de 9.2 según el sistema CVSS v4.0. La explotación depende de la configuración del servidor, extensiones y comportamiento de la aplicación, pero el impacto potencial es masivo, dado que PHP impulsa aproximadamente el 68.8% de los sitios web según W3Techs.
Las investigaciones sobre estos fallos empezaron a tomar forma tras una auditoría de seguridad en 2024, aunque fue en 2026 cuando empezaron a surgir informes de intentos reales de ejecución remota de código, incluidos reportes de entidades como OpenAI y Wiz. Por tanto, la Fundación PHP puso máxima prioridad en corregir estos defectos.
El desmoronamiento del embargo de seguridad
Tras coordinar la liberación con distintas partes, se filtraron detalles críticos antes del lanzamiento oficial, incluyendo los identificadores de las vulnerabilidades y un vídeo demo que se publicó por error, facilitando la tarea a posibles atacantes.
A pesar de ello, la Fundación PHP insistió en mantener el embargo hasta el mediodía del 21 de octubre para que distribuidores y proveedores prepararan sus actualizaciones. Chainguard, sin embargo, lanzó sus imágenes parcheadas a las 07:41 UTC, anticipándose más de seis horas al plan establecido.
La Fundación criticó esta acción advirtiendo que publicar las versiones corregidas en binario brinda herramientas a los ciberdelincuentes para analizar los fallos, mientras la mayoría de usuarios aún esperaban el parche oficial. “Un binario parcheado protege al que lo instala, pero también indica a atacantes dónde enfocarse,” alertaron.
La defensa de Moore: ventaja perdida para los defensores
Moore reconoció que facilitar el código parcheado puede ayudar a los atacantes, pero argumentó que para ese momento la ventaja de mantener una brecha en secreto ya se había perdido. Los atacantes disponían de suficientes indicios o estaban cerca de descubrir cómo explotar las vulnerabilidades, por lo que fue necesario actuar para proteger a los usuarios cuanto antes.
Moore relató cómo el equipo de Chainguard detectó y replicó rápidamente las vulnerabilidades con sus herramientas internas, lo que les apuntó a la gravedad de la situación. Además, aseguró que tras obtener nueva información mantuvieron conversaciones con otros miembros del embargo, aunque fue la compañía la que tomó la decisión final de adelantar la publicación.
Indicios de explotación previa al lanzamiento público
El informe público respalda la preocupación de Chainguard respecto a intentos de explotación antes del lanzamiento oficial. Amazon Threat Intelligence detectó intentos de explotación dirigidos a sus honeypots MadPot cuatro días antes y observó actividad probatoria en las horas previas a la divulgación.
Cloudflare también reportó tráfico malicioso contra sus usuarios, activando protecciones de firewall web desde muy temprano en la madrugada del 21 de octubre, antes del aviso oficial. Sin embargo, la evidencia técnica de que estos ataques fueran exitosos aún no está clara.
Impacto del AI y el desafío en los tiempos de respuesta
Moore señaló que la investigación asistida por inteligencia artificial podría intensificar este problema, ya que acelera la transformación de vulnerabilidades en exploits funcionales en un tiempo menor al que se tarda en compilar y distribuir parches.
Incluso con parches rápidos, los usuarios necesitan tiempo para integrar, probar y desplegar las actualizaciones, lo que crea una brecha inevitable entre la publicación del parche y la protección efectiva de sistemas.
“Más rápido no significa instantáneo, y el tiempo de publicación para un proveedor no es igual al tiempo de remediación para un cliente.”
Nuevos retos y aprendizaje para la comunidad
Este incidente revela fallos estructurales en la coordinación y recursos para gestionar vulnerabilidades críticas en proyectos de software abiertos como PHP. La disputa entre Chainguard y la Fundación PHP ejemplifica las complejidades a la hora de equilibrar la transparencia y la seguridad en procesos de divulgación coordinada.
Aunque muchos criticaron duramente a Chainguard, incluido un alto responsable de CISA que calificó su conducta de peligrosa, también hay esfuerzos por restaurar la confianza y definir protocolos claros para futuras situaciones similares.
Matt Moore definió la decisión como “muy difícil” al enfrentar dos opciones igualmente comprometidas. Subrayó la necesidad de pactar en anticipación cuáles condiciones justifican levantar un embargo temprano, cómo se comunica y quién toma esa decisión para evitar conflictos dañinos.
Mientras tanto, la seguridad global de software depende cada vez más de una reacción rápida y coordinada que minimice la ventana de oportunidad para los ciberdelincuentes, en un mundo donde la inteligencia artificial y la automatización aceleran las amenazas.
