Ochenta y siete minutos, reconstruidos con una semana de retraso

La intrusión en si duro unos 87 minutos en la madrugada del 27 al 28 de julio de 2026. Según el director de tecnología David Simpson, una clave de acceso de AWS estaba expuesta dentro de los artefactos de compilación de JavaScript que la propia web pública de Beacon entregaba directamente, es decir, el paquete que descarga el navegador de cualquier visitante sin activar ninguna alerta.

Beacon no detectó la intrusión en tiempo real. Según Simpson, la empresa solo reconstruyo lo ocurrido analizando a posteriori los informes de coste y uso de AWS de mayo a julio de 2026, y encontró un pico en los costes de transferencia de datos exactamente en esos dos días, una prueba que coincide con la actividad de descarga en lugar de proceder de un sistema de detección en vivo.

Ese método retrospectivo explica el retraso en la notificación: la brecha ocurrió el 27 y 28 de julio, Beacon informó a sus clientes el 4 de agosto y publicó una actualización el 13 de agosto que todavía no pudo cerrar todas las preguntas. Simpson dijo directamente a los clientes que habrá cosas que quizá nunca lleguen a saber sobre este incidente, y prometió más detalles en las semanas siguientes.

Quién está realmente expuesto

La cartera de clientes de Beacon supera las 1.500 organizaciones benéficas, y la empresa ha dicho explícitamente que aun no ha determinado a cuántas se les sustrajeron datos, solo que se hizo una copia completa de la base de datos, incluidos los archivos adjuntos, y que casi con toda seguridad se descargó en texto legible.

The Register nombra organizaciones concretas afectadas, entre ellas Molly Rose Foundation, Macmillan Cancer Support Jersey, English National Ballet, Sheffield Hospitals Charity, Shrewsbury and Telford Hospital Charity, British Deaf Association y Lincoln Cathedral, un abanico que va del acompañamiento en el duelo a la recaudación hospitalaria, pasando por la defensa de las personas sordas y el patrimonio cultural.

Nada de esto son datos clínicos como los de un hospital propiamente dicho, pero los registros de donantes y simpatizantes de este tipo de organizaciones incluyen habitualmente a personas en duelo, enfermedad o crisis, precisamente el colectivo que un responsable del tratamiento debería proteger con más cuidado, no menos, que una lista de correo cualquiera.

La brecha que DORA y NIS2 debian cerrar, pero no alcanzan

El Reglamento DORA de la UE obliga a las entidades financieras a mantener, en virtud de sus artículos 28 a 30, un registro de cada proveedor de TIC externo y a evaluar el riesgo que representa cada uno, precisamente para que la postura de seguridad de un proveedor se audite antes de un incidente, no después. NIS2 impone obligaciones comparables de seguridad y notificación a las entidades esenciales e importantes de sectores como la energía, la sanidad, la infraestructura digital y la administración pública.

Las organizaciones benéficas y los proveedores de software que las atienden quedan totalmente fuera de ambos regímenes. Su única red de seguridad es el principio general de rendición de cuentas del RGPD británico, que sigue haciendo responsable a la organización como responsable del tratamiento aunque falle el producto de un encargado, y el proceso voluntario de notificación de incidentes graves de la Charity Commission, que el propio regulador describe como una priorizacion por riesgo y no como una respuesta simultanea a todas las notificaciones.

Esa es la lectura de Servola que no aparece en ningun informe por separado: una clave de acceso olvidada dentro de JavaScript público es exactamente el tipo de fallo basico de higiene de secretos que la prueba de penetracion obligatoria y el rastro de auditoría de DORA existen para atrapar en un proveedor regulado antes de firmar el contrato. Retirado ese régimen, como ocurre en el sector no lucrativo, la revisión que debería producirse en la contratación sucede ahora después del hecho, notificación a notificación ante la Charity Commission.

Que debería preguntar una organización benéfica antes de renovar

La respuesta práctica no requiere una ley nueva. Cualquier organización que firme o renueve un contrato de software como servicio puede pedir directamente al proveedor pruebas de detección automatizada de secretos en su canal de compilación, un compromiso escrito sobre el plazo de respuesta ante incidentes y la confirmacion de que campos de donantes o beneficiarios son realmente necesarios y cuales solo cómodos.

El patrón no es exclusivo de Beacon. Las brechas de proveedores causadas por fallos básicos de higiene de credenciales, desde el incidente de ingeniería social todavía sin explicar de RingCentral hasta el compromiso del proveedor de envíos de Trezor y ShipMonk, se repiten porque las garantias de seguridad de la cadena de suministro pensadas para sectores regulados no se extienden automáticamente a sectores adyacentes que compran la misma clase de herramientas con una fracción del presupuesto de seguridad y sin ninguna palanca contractual.

Mientras esa palanca no exista para las organizaciones benéficas como existe para los bancos bajo DORA, la notificación voluntaria ante la Charity Commission está haciendo el trabajo de control que ningun regulador externo puede asumir hoy, una organización con pocos recursos y una notificación cada vez.

Leer a continuación: 45.601 fallos y solo 171 se están usando  |  Un solo mensaje alcanzó las claves SSH