PHP2Shell y la divulgación prematura de vulnerabilidades: ¿quién responde por los daños transfronterizos?

I. Una amenaza digital que no entiende de fronteras

El 21 de octubre de 2026, el equipo responsable de PHP publicó actualizaciones de seguridad para corregir dos vulnerabilidades críticas que podían permitir, bajo determinadas condiciones, la ejecución remota de código. Esto significa que una persona situada fuera del sistema podría llegar a conseguir que un servidor ejecutase instrucciones elegidas por ella.¹

El episodio, conocido como PHP2Shell, no plantea únicamente un problema de seguridad informática. Antes de la publicación coordinada de las correcciones circularon identificadores de las vulnerabilidades, se difundió un vídeo que mostraba una prueba de concepto y una empresa publicó imágenes de software que incorporaban el parche. La conveniencia de esta última decisión fue objeto de valoraciones contrapuestas.²

Estas circunstancias invitan a formular una pregunta jurídica: ¿puede responder civilmente quien divulga información sobre una vulnerabilidad, o distribuye anticipadamente una corrección, si posteriormente empresas y usuarios situados en diferentes Estados sufren daños?

La cuestión exige evitar dos simplificaciones. Por un lado, la divulgación de un fallo puede facilitar su explotación. Por otro, también puede permitir que quienes utilizan el software adopten medidas de protección. Además, el defecto existe con anterioridad a su divulgación y un eventual ataque puede depender de decisiones de terceros. La respuesta no puede limitarse, por tanto, a identificar quién publicó primero la información.

II. Qué es PHP y por qué importa

Cuando una persona visita una página web, su navegador muestra textos, imágenes y botones. No obstante, una parte de las operaciones necesarias para ofrecer ese contenido se realiza en un servidor, es decir, en un equipo o servicio que recibe la solicitud del usuario y prepara una respuesta.

PHP es un lenguaje de programación que permite escribir instrucciones para realizar esas tareas. Por ejemplo, una aplicación puede emplearlo para preparar la información que se muestra en una tienda digital o para gestionar determinadas operaciones de un sitio web. Quien navega por la página ve el resultado, pero normalmente no las instrucciones ejecutadas en el servidor.

PHP no es una página concreta ni una empresa que controle todos los sitios que lo utilizan. Es una tecnología que puede emplearse en aplicaciones diferentes. Un ejemplo es WordPress, programa utilizado para crear y gestionar sitios web, cuyos requisitos de alojamiento incluyen PHP.³

Esta presencia en servicios distintos explica la relevancia del incidente. Una vulnerabilidad en una tecnología compartida puede afectar potencialmente a organizaciones que no tienen relación entre sí y cuyos servidores, trabajadores y clientes se encuentran en países diferentes. Ahora bien, utilizar PHP no equivale automáticamente a haber sufrido un ataque: el riesgo concreto depende, entre otros factores, de la versión instalada y de su configuración.

Los dos fallos identificados en PHP2Shell recibieron los códigos CVE-2026-109618 y CVE-2026-109619. Según PHP Foundation, ambos afectaban a componentes internos relacionados con la memoria y podían permitir la ejecución remota de código. La Fundación explicó, además, que una de las vías se había demostrado en un entorno determinado antes de que se ejecutase el código de la propia aplicación. Esa demostración técnica no acredita, por sí sola, que todos los servidores potencialmente expuestos fueran comprometidos.⁴

III. La divulgación coordinada y los hechos de PHP2Shell

Cuando se descubre una vulnerabilidad, una posibilidad consiste en comunicarla inicialmente a quienes mantienen el programa para que puedan verificarla, preparar una corrección y organizar su distribución. La divulgación coordinada de vulnerabilidades busca ordenar esa comunicación y acordar cuándo se informará públicamente del problema.

La lógica es sencilla: si se difunden instrucciones que facilitan un ataque antes de que las personas afectadas puedan protegerse, la exposición puede aumentar. Pero también existe el riesgo contrario. Una reserva demasiado prolongada puede dejar sin información a quienes deberían adoptar medidas, mientras otros investigadores o posibles atacantes descubren el mismo defecto por separado.

La cronología de PHP2Shell obliga a distinguir esas posibilidades. Según PHP Foundation, un investigador de Calif comunicó en agosto de 2026 una vía de ejecución remota vinculada a un problema del que ya se habían detectado indicios en 2024. Posteriormente se recibieron comunicaciones independientes de otras organizaciones. No sería correcto afirmar que el descubridor original se limitó a hacer público el fallo sin avisar previamente.

La Fundación explica que, el 20 de octubre, comenzaron a circular los identificadores de las vulnerabilidades con algunos datos incorrectos. En respuesta, el proyecto adelantó la publicación de las correcciones, inicialmente prevista para el día 22. Añade que Calif difundió por error un vídeo de prueba de concepto, que después retiró, aunque sus copias siguieron circulando.

Una prueba de concepto muestra cómo podría aprovecharse un fallo. No es lo mismo que distribuir una imagen de software corregida. Sobre esta segunda actuación, PHP Foundation sostiene que Chainguard publicó imágenes con el parche antes del momento coordinado. Por su parte, según una entrevista recogida por TechTarget, el director de Chainguard invocó el descubrimiento independiente del problema y la información que había recibido sobre una posible explotación activa. Se trata de posiciones atribuidas a sus respectivos protagonistas: las fuentes disponibles no permiten convertir esa controversia en una declaración de responsabilidad civil.⁵

La secuencia presenta, además, una dificultad para cualquier análisis causal. Amazon Threat Intelligence informó de un intento dirigido contra su red de sistemas señuelo el 17 de octubre, antes de la divulgación pública, y de otros intentos el día 21. La propia empresa precisó que no sabía cómo se había obtenido la información antes de la publicación y que no estaba claro si aquellos intentos habrían tenido éxito contra sistemas reales.⁶

Por ello, el episodio no demuestra que todos los riesgos surgieran de una publicación anticipada concreta. Pero tampoco permite descartar que determinadas divulgaciones posteriores pudieran aumentar la exposición de otros sistemas. Son cuestiones distintas que exigirían prueba diferenciada.

IV. ¿Existe un deber jurídico de comunicar antes de publicar?

Que la coordinación sea una práctica recomendable no significa que cualquier investigador tenga una obligación legal general de guardar silencio.

En la Unión Europea, el artículo 12.1 de la Directiva (UE) 2022/2555 (conocida como NIS2 o SRI 2) prevé que cada Estado miembro designe un equipo de respuesta a incidentes de seguridad informática como coordinador de la divulgación de vulnerabilidades. Entre sus funciones se encuentran facilitar la comunicación entre quien notifica el defecto y las entidades afectadas, prestar asistencia y negociar los plazos de divulgación. El precepto contempla también la posibilidad de realizar una notificación anónima cuando así se solicite.⁷

La Directiva impone deberes de transposición a los Estados y prevé medidas para sujetos comprendidos en su ámbito. De ello no se deduce, sin más, una prohibición universal de publicación dirigida a toda persona que descubra una vulnerabilidad. La posible invocación de sus disposiciones en España debe examinarse atendiendo al precepto concreto, a la relación jurídica de que se trate y al Derecho nacional aplicable. En particular, no cabe atribuir automáticamente a un investigador independiente obligaciones previstas para entidades sometidas a un régimen específico.

En cuanto a la transposición española, el 8 de julio de 2026 la Comisión Europea anunció su decisión de llevar a España ante el Tribunal de Justicia de la Unión Europea por no haber notificado la transposición completa de NIS2. La decisión se sitúa después del dictamen motivado de mayo de 2025. Ahora bien, una decisión de la Comisión de acudir al Tribunal no equivale, por sí sola, a una sentencia condenatoria ni permite describir como definitiva la situación en una fecha posterior. En la revisión realizada no se ha localizado una resolución o actuación posterior que permita establecer con seguridad el estado completo de la transposición a 27 de octubre de 2026.⁸

Por otro lado, el Reglamento (UE) 2024/2847 de Ciberresiliencia establece en su artículo 14 obligaciones de notificación para los fabricantes respecto de vulnerabilidades activamente explotadas e incidentes graves que afecten a productos con elementos digitales, bajo las condiciones previstas en dicho artículo. Según el calendario de su publicación original, el artículo 14 es aplicable desde el 11 de septiembre de 2026, con las precisiones transitorias del artículo 69.⁹

El Reglamento distingue esa posición de la de los administradores de comunidades de programas informáticos de código abierto. El artículo 24.3 les extiende determinadas obligaciones del artículo 14 en los supuestos que especifica: entre otros, cuando participen en el desarrollo de los productos afectados o, respecto de ciertos incidentes, cuando estos afecten a las redes y sistemas que proporcionan para dicho desarrollo. Sin embargo, el artículo 24.3 no figura entre las excepciones de aplicación anticipada del artículo 71.2; conforme al calendario original, se aplica desde el 11 de diciembre de 2027, no durante los hechos de octubre de 2026.

Estas categorías no deben confundirse con la de un investigador independiente que descubre un fallo. Tampoco puede presumirse, sin comprobar sus actividades y características jurídicas, que PHP Foundation, Chainguard o cualquiera de los investigadores implicados encajen en una u otra categoría.

Junto a las normas pueden existir acuerdos de confidencialidad, compromisos asumidos en un proceso de coordinación o políticas internas de un proyecto. Su relevancia jurídica no es idéntica. Un acuerdo válidamente asumido puede fundamentar una reclamación contractual; una política técnica o una recomendación institucional puede ayudar a valorar la diligencia exigible, pero no se transforma automáticamente en una obligación legal para cualquier tercero.¹⁰

V. La posible responsabilidad civil y sus dificultades

Si el Derecho español resultase aplicable, el artículo 1902 del Código Civil ofrece el punto de partida para examinar la responsabilidad extracontractual por una acción u omisión que cause daño mediando culpa o negligencia. Si existiera una obligación contractual de confidencialidad, también podría ser necesario examinar el régimen de incumplimiento contractual, incluido el artículo 1101. Sin embargo, ninguno de estos preceptos debe aplicarse antes de determinar cuál es la ley que rige el litigio internacional.¹¹

La publicación de información técnicamente verdadera no es, por ese solo motivo, una conducta ilícita. La valoración dependería de factores como el contenido difundido, el conocimiento que tuviera su autor de los riesgos, la existencia de un compromiso previo, el tiempo concedido para preparar una corrección y las medidas de protección disponibles. Publicar instrucciones que faciliten la explotación de un fallo puede crear un peligro; publicar una corrección también puede reducirlo.

El problema más complejo sería, probablemente, la causalidad. Una empresa podría alegar gastos extraordinarios por desconectar preventivamente un servicio, pérdidas por interrupción de actividad o daños en sus sistemas tras una intrusión. Pero habría que probar qué perjuicio se produjo realmente y cómo se relaciona con la conducta del demandado.

No son equivalentes el coste de una decisión preventiva, el daño causado por un ataque y la pérdida derivada de una vulnerabilidad preexistente. Tampoco puede presumirse que la intervención de un atacante rompe siempre la relación causal, ni que quien publica información responde automáticamente de cualquier ataque posterior. La solución dependerá de la prueba y de los criterios de imputación de la ley aplicable.

Si el incidente afecta a datos personales, puede entrar en juego el artículo 82 del Reglamento General de Protección de Datos (RGPD), siempre que concurran sus requisitos y que el tratamiento quede comprendido en sus ámbitos material y territorial. El Tribunal de Justicia ha precisado que la mera infracción del Reglamento no basta por sí sola para reconocer una indemnización y que el temor a un posible uso indebido puede constituir un daño inmaterial si se comprueba en el caso concreto. Estas decisiones no convierten automáticamente al divulgador de una vulnerabilidad en responsable del tratamiento de los datos afectados.¹²

VI. Competencia judicial y ley aplicable: el núcleo internacional

1. ¿Ante qué tribunales podría reclamarse?

Cuando el demandado está domiciliado en un Estado miembro y el Reglamento (UE) 1215/2012 (Bruselas I bis) resulta aplicable, la regla general del artículo 4 permite demandarlo ante los tribunales de ese Estado. Además, en materia delictual o cuasidelictual, el artículo 7.2 contempla la competencia del tribunal del lugar donde se haya producido o pueda producirse el hecho dañoso.¹³

Esta segunda regla obliga a distinguir entre el lugar del hecho causal y el lugar de materialización del daño. En un supuesto digital no basta con afirmar que la información era accesible desde un país para concluir que sus tribunales pueden conocer de todos los perjuicios alegados.

La sentencia del Tribunal de Justicia en el asunto Vereniging van Effectenbezitters/BP resulta útil como advertencia metodológica. El litigio trataba de pérdidas económicas vinculadas a información societaria accesible internacionalmente. En las circunstancias examinadas, la localización de una pérdida en una cuenta de inversión no bastaba por sí sola para fundamentar la competencia de los tribunales de ese Estado. La sentencia no resuelve un caso de vulnerabilidades informáticas, pero aconseja no identificar automáticamente el lugar donde se contabiliza una pérdida con el lugar jurídicamente relevante del daño.¹⁴

Tampoco debe trasladarse sin matices la solución de Gtflix Tv, relativa a comentarios presuntamente denigrantes publicados en internet. El Tribunal admitió allí una reclamación territorialmente limitada por los perjuicios sufridos en cada Estado en el que el contenido fuera accesible. El objeto del litigio era distinto: de ese pronunciamiento no se deduce que cualquier aviso técnico accesible en línea permita reclamar ante todos los tribunales europeos por cualquier pérdida empresarial.¹⁵

Cuando el demandado está domiciliado fuera de la Unión, el artículo 6 de Bruselas I bis remite, como regla general y con las excepciones previstas, a las normas de competencia internacional del Estado del tribunal que conoce del asunto. Si la demanda se presenta en España, será necesario examinar la Ley Orgánica del Poder Judicial y los posibles convenios aplicables. Además, una acción ejercitada por un interesado contra un responsable o encargado del tratamiento puede exigir el examen de los fueros específicos del artículo 79 del RGPD, sin confundirlos con su ámbito territorial de aplicación. Este régimen especial de competencia judicial también resulta aplicable a las acciones indemnizatorias por daños derivados de infracciones del RGPD, por remisión expresa de su artículo 82.6 a los fueros previstos en el artículo 79.2.¹⁶

2. ¿Qué ley regiría la reclamación?

La competencia judicial y la ley aplicable son preguntas distintas. Que un tribunal español pueda conocer de un litigio no significa necesariamente que deba aplicar el Código Civil español.

Para las obligaciones extracontractuales comprendidas en su ámbito, el Reglamento (CE) 864/2007 (Roma II) establece en su artículo 4.1, como regla general, la aplicación de la ley del país donde se produce el daño. El mismo precepto distingue ese daño de las consecuencias indirectas que puedan manifestarse en otros países. Sus apartados 2 y 3 contemplan, respectivamente, la residencia habitual común de las partes y la existencia de vínculos manifiestamente más estrechos con otro país.¹⁷

La dificultad consiste en localizar el daño directo cuando la información se publica en un Estado, los servidores están en otro y las pérdidas económicas se reflejan en varios más. La ubicación de un servidor puede ser relevante si allí se produjo la lesión de un sistema, pero no resuelve por sí sola dónde se originó cada perjuicio económico. Tampoco la sede de una empresa determina necesariamente la respuesta para todos sus daños.

Existe, además, una precisión sobre el ámbito material de Roma II. Su artículo 1.2.g) excluye las obligaciones extracontractuales que se deriven de violaciones de la intimidad y de derechos relacionados con la personalidad, incluida la difamación. Por ello, un mismo incidente puede dar lugar a reclamaciones de distinta naturaleza que no queden necesariamente sometidas al mismo régimen conflictual.

Así, una reclamación por daños en sistemas empresariales o pérdidas patrimoniales deberá analizarse según su propio fundamento y el ámbito de Roma II. Una reclamación derivada de una lesión de la intimidad o de derechos de la personalidad puede quedar excluida de ese Reglamento, lo que obliga a examinar las normas de conflicto pertinentes del foro. No sería correcto, sin embargo, equiparar automáticamente toda infracción del RGPD con una obligación excluida por el artículo 1.2.g): habrá que identificar la pretensión, el derecho lesionado y la relación entre las normas aplicables. A su vez, el artículo 82 del RGPD puede proporcionar una base sustantiva de indemnización cuando concurran sus requisitos, sin resolver necesariamente todas las cuestiones de Derecho nacional que puedan suscitarse.

El artículo 17 de Roma II añade que deben tenerse en cuenta, como cuestión de hecho y en la medida adecuada, las reglas de seguridad y comportamiento vigentes en el lugar y momento del hecho. Una política de divulgación podría ser relevante en esa valoración cuando se justifique su pertinencia, pero el artículo 17 no sustituye las reglas de conexión que determinan la ley aplicable.

Imaginemos que una empresa divulga anticipadamente información desde un Estado y que tres operadores establecidos en España, Francia y Países Bajos alegan perjuicios. Uno desconecta preventivamente su plataforma; otro sufre una intrusión en un servidor situado en un tercer país; el tercero registra una pérdida en su contabilidad. Antes de elegir tribunal y ley habría que identificar quién realizó la publicación, dónde se produjo la conducta, qué daño sufrió cada entidad y si ese perjuicio fue directo o consecuencia de otro anterior.

La pluralidad de afectados podría conducir a reclamaciones sometidas a leyes distintas. También podría existir una conexión contractual entre algunas de las partes que exigiera examinar separadamente el régimen de las obligaciones contractuales. Sin esos datos, ofrecer una única respuesta categórica sería prematuro.

VII. Conclusión: coordinación sí, responsabilidad automática no

PHP2Shell muestra que la divulgación de vulnerabilidades puede situar a los participantes ante decisiones difíciles: esperar puede dar tiempo a distribuir una corrección, pero también puede mantener desinformados a quienes necesitan protegerse. Publicar antes puede reducir determinados riesgos y aumentar otros.

La conclusión más defendible es que la divulgación anticipada no constituye por sí sola un supuesto de responsabilidad civil. Para exigir una indemnización deben identificarse los deberes aplicables al sujeto concreto y acreditarse, conforme al ordenamiento que rija el caso, una conducta jurídicamente relevante, un daño y una conexión causal suficiente. Los protocolos de coordinación pueden orientar la valoración de la diligencia, pero no equivalen automáticamente a una obligación universal de confidencialidad.

En los litigios transfronterizos conviene seguir un orden: individualizar primero la conducta y el perjuicio alegados; determinar después el tribunal competente; comprobar si la reclamación entra en el ámbito de Roma II o en un régimen especial; localizar, cuando proceda, el daño directo; y, solo entonces, valorar la diligencia y la causalidad conforme al ordenamiento aplicable. Este método no elimina la incertidumbre técnica, pero evita atribuir una responsabilidad global por el mero hecho de haber revelado una amenaza digital.