Etiqueta: Data Breach

Incidentes con compromiso de datos: brechas, hackeos con exfiltración, filtraciones.

  • Centro oncológico de Singapur expone datos de pacientes con cáncer hereditario por error de CC

    Centro oncológico de Singapur expone datos de pacientes con cáncer hereditario por error de CC

    El National Cancer Centre Singapore (NCCS) expuso involuntariamente los datos de identidad, contacto y lugar de trabajo de pacientes con condiciones genéticas de cáncer al enviar una invitación masiva con la lista de destinatarios visible, según se informó el 19 de septiembre de 2026.

    El incidente se originó en un correo electrónico de invitación a un evento denominado “Living with…” dirigido a personas con enfermedades oncológicas de origen genético. En lugar de ocultar a los destinatarios mediante copia oculta (CCO), el mensaje fue enviado con todos los contactos visibles en el campo CC, lo que expuso nombres, correos electrónicos, números de contacto y, en algunos casos, el empleador de los afectados. La información así revelada es especialmente sensible: la condición genética de cáncer es, por definición, un dato de salud que permite inferir antecedentes familiares.

    Datos confirmados sobre el incidente en Singapur

    • Organización involucrada: National Cancer Centre Singapore (NCCS), institución pública de referencia oncológica.
    • Tipo de dato expuesto: nombre, datos de contacto y, en varios casos, lugar de trabajo de los destinatarios.
    • Naturaleza del dato: condición genética de cáncer — categoría de salud de máxima sensibilidad.
    • Mecanismo del fallo: uso de campo CC en lugar de CCO en un correo masivo institucional.
    • Estado del incidente: calificado como “alegado” al momento de la publicación; no hay confirmación oficial pública de NCCS según se informó.

    Qué se sabe y qué falta confirmar

    Lo confirmado es el envío del correo con la lista de destinatarios visible y la sensibilidad de los datos involucrados. Lo que permanece sin verificar incluye la cantidad exacta de afectados, si NCCS notificó al regulador de Singapur (Personal Data Protection Commission, PDPC) dentro del plazo de tres días hábiles que exige la Personal Data Protection Act (PDPA) para brechas de datos significativas, y si la entidad activó un protocolo de respuesta ante el incidente. Tampoco se ha informado públicamente si los pacientes afectados recibieron notificación individual.

    El error CC —usar copia abierta en lugar de copia oculta— es uno de los vectores de exposición más recurrentes en organizaciones de salud a nivel global, y su persistencia indica fallas en controles básicos de emisión de comunicaciones masivas. En contextos de datos de salud, el impacto no es solo legal: revelar que alguien porta una condición genética oncológica puede tener consecuencias en su entorno laboral, familiar y asegurador. En América Latina, legislaciones como la Ley 25.326 de Argentina, la LGPD de Brasil y la LFPDPPP de México clasifican los datos de salud —y con mayor razón los datos genéticos— como datos sensibles, cuyo tratamiento inadecuado habilita sanciones agravadas y, en algunos marcos, responsabilidad penal. Un incidente equivalente protagonizado por un hospital público en la región activaría, según el país, la obligación de notificar tanto a la autoridad de control como a los titulares afectados en plazos de entre 24 y 72 horas.

    El próximo hito crítico es la confirmación —o ausencia— de notificación formal de NCCS ante la PDPC de Singapur, cuyo plazo obligatorio bajo la PDPA vence tres días hábiles después de que la organización tomó conocimiento del incidente.

  • El hackeo a Hugging Face y la paradoja de la seguridad en IA

    El hackeo a Hugging Face y la paradoja de la seguridad en IA

    Semanas después del incidente en OpenAI, Hugging Face sufrió un hackeo que expuso datos de la plataforma. La conclusión de Heidy Khlaaf, investigadora del AI Now Institute, es contundente: ingeniería de seguridad convencional habría sido suficiente para detenerlo. El problema no fue la IA —fue la gestión humana de los controles.

    El incidente en Hugging Face volvió a instalar una pregunta incómoda en la industria de la inteligencia artificial: ¿cuánto del riesgo que rodea a los sistemas de IA es realmente un problema de la tecnología, y cuánto es el resultado de prácticas de seguridad deficientes en las organizaciones que los construyen y hospedan? Según Khlaaf, la respuesta inclina la balanza hacia lo segundo. La investigadora del AI Now Institute sostuvo que “ingeniería de seguridad ordinaria habría detenido esto antes de llegar a los datos de Hugging Face”, según se informó desde el instituto.

    Qué falló en Hugging Face: controles, no algoritmos

    Hugging Face es una de las plataformas centrales del ecosistema de IA abierta: aloja modelos, datasets y aplicaciones que utilizan millones de desarrolladores en todo el mundo, incluyendo equipos de investigación y empresas en América Latina. Un compromiso en ese entorno no solo afecta datos propios de la plataforma —también puede afectar a los usuarios que confían sus modelos y datasets a esa infraestructura. La naturaleza exacta de los datos comprometidos no fue detallada con precisión en la declaración del AI Now Institute, más allá de la referencia general al alcance del acceso no autorizado.

    Lo que el caso deja en evidencia, según el análisis de Khlaaf, es que los vectores de ataque que afectaron a Hugging Face no eran exóticos ni requerían explotar vulnerabilidades propias de los modelos de lenguaje o de la infraestructura de IA. Se trató, según se informó, de fallas en controles de seguridad estándar —el tipo de controles que cualquier organización que maneja datos sensibles debería tener implementados independientemente de si trabaja con IA o no. Autenticación, segmentación de accesos, monitoreo de credenciales comprometidas: herramientas de seguridad conocidas y documentadas desde hace años.

    El patrón que conecta OpenAI y Hugging Face

    El hackeo a Hugging Face ocurrió semanas después de que OpenAI también reportara un incidente de seguridad. Que dos de los actores más visibles del sector de IA enfrenten brechas en un período corto no es una coincidencia operativa —es una señal de que la aceleración del desarrollo de modelos no siempre viene acompañada de una madurez equivalente en las prácticas de protección de la infraestructura. Las organizaciones que mueven velocidad de producto rara vez acompasan esa velocidad con revisiones de superficie de ataque, gestión de identidades o clasificación de activos.

    Desde la perspectiva del AI Now Institute, un think tank que viene documentando los riesgos sociales y legales de la IA, la lectura del incidente es en realidad optimista en un sentido técnico: si los controles humanos convencionales son suficientes para prevenir este tipo de brechas, entonces el problema es de governance y priorización, no de una amenaza tecnológicamente irresoluble. Los humanos pueden mantener a la IA bajo control —pero solo si aplican los mecanismos que ya existen.

    Cuándo aplica esta lectura / cuándo NO

    El argumento de Khlaaf aplica directamente a incidentes donde el vector de ataque pasa por la infraestructura que rodea a los sistemas de IA: APIs expuestas, credenciales filtradas, permisos excesivos, falta de segmentación. No aplica —o aplica con matices importantes— a riesgos emergentes propios de los modelos en sí: ataques de prompt injection, exfiltración de datos de entrenamiento vía inferencia, o manipulación de outputs. Esos requieren controles específicos que la seguridad convencional no cubre por completo. La distinción importa para no simplificar en exceso: decir que “los humanos pueden controlar la IA” con base en este caso no equivale a decir que todos los riesgos de IA son gestionables con herramientas de seguridad del año 2010.

    El ángulo regulatorio: qué exigen LGPD, Ley 25.326 y el AI Act ante un hackeo a un proveedor de IA

    Para organizaciones latinoamericanas que usan Hugging Face como infraestructura —para alojar modelos propios, procesar datasets que incluyen datos personales, o integrar APIs en productos— un incidente de este tipo activa obligaciones concretas. En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que el controlador notifique a la Autoridade Nacional de Proteção de Dados (ANPD) y a los titulares afectados ante una brecha que pueda generar riesgos relevantes, en un plazo que la ANPD ha precisado en resoluciones posteriores a la entrada en vigor de la ley. En Argentina, la Ley 25.326 y las disposiciones de la Agencia de Acceso a la Información Pública (AAIP) también contemplan obligaciones de notificación ante incidentes de seguridad que comprometan datos personales tratados por terceros bajo contrato. En México, el INAI tiene competencia para revisar si los encargados del tratamiento —rol que cumpliría Hugging Face para quienes le delegan procesamiento— contaban con medidas de seguridad adecuadas conforme a la LFPDPPP.

    El caso también es relevante bajo el AI Act europeo, que clasifica ciertos sistemas de IA como de alto riesgo y exige que los proveedores mantengan controles de seguridad específicos a lo largo del ciclo de vida del sistema. Si Hugging Face es parte de la cadena de suministro de un sistema de IA de alto riesgo desplegado en la Unión Europea, las obligaciones de reporte y remediación se amplían considerablemente.

    El caso Hugging Face no prueba que la IA sea segura —prueba que la seguridad de la IA depende de decisiones organizacionales que los equipos técnicos y legales ya tienen capacidad de tomar. La pregunta es si lo priorizan antes del próximo incidente.

  • ShinyHunters afirma haber expuesto 14 millones de registros de Panera Bread

    ShinyHunters afirma haber expuesto 14 millones de registros de Panera Bread

    El grupo ShinyHunters asegura haber comprometido 14 millones de registros de clientes de la cadena estadounidense Panera Bread, según informó TechRepublic el 16 de septiembre de 2026. La atribución proviene del propio grupo, que tiene antecedentes de brechas de alto perfil, aunque Panera Bread no había emitido confirmación oficial al momento de la publicación.

    ShinyHunters es el mismo grupo que en años anteriores reclamó responsabilidad por filtraciones masivas en empresas como AT&T y Ticketmaster. En este caso, el colectivo afirma haber exfiltrado una base de datos con 14 millones de registros asociados a clientes de Panera Bread, una cadena de restaurantes con presencia extensa en Estados Unidos y Canadá. La información sobre el incidente surgió de publicaciones del propio grupo en foros de ciberdelincuencia, canal habitual para este tipo de anuncios. No se detallaron públicamente los tipos de campos incluidos en la base de datos expuesta, ni si la información abarca datos de pago, credenciales o únicamente datos de perfil.

    Datos confirmados y qué sigue sin verificarse

    • Registros reclamados: 14 millones, según ShinyHunters.
    • Actor: ShinyHunters, grupo con historial documentado de brechas en AT&T, Ticketmaster y Santander Bank, entre otros.
    • Empresa afectada: Panera Bread (cadena de restaurantes, EE.UU./Canadá).
    • Fecha del reporte público: 16 de septiembre de 2026.
    • Confirmación oficial de Panera Bread: no disponible al cierre de esta nota.
    • Naturaleza de los datos: no especificada públicamente.

    Qué falta confirmar y por qué importa en la región

    La atribución unilateral por parte del grupo atacante es el único dato público disponible: no se cuenta con validación independiente del volumen declarado ni con confirmación del tipo de información comprometida. Panera Bread opera un programa de fidelidad con millones de cuentas activas, lo que eleva el riesgo potencial si los datos incluyen identificadores de usuario, historial de compras o métodos de pago vinculados. Hasta que la empresa notifique formalmente, el alcance real permanece sin determinar.

    Aunque Panera Bread no opera directamente en América Latina, el incidente tiene relevancia regional por dos vías. Primero, consumidores latinoamericanos con cuentas en la plataforma —creadas durante viajes o de forma remota— podrían estar incluidos en el conjunto de datos expuesto. Segundo, ShinyHunters ha demostrado apuntar a empresas con bases de datos de fidelización de gran escala sin distinción geográfica: el ataque a Santander Bank en 2024 afectó clientes en Chile, España y Uruguay, entre otros países. Las autoridades de protección de datos de la región —como la Agencia de Acceso a la Información Pública (AAIP) en Argentina o la Autoridade Nacional de Proteção de Dados (ANPD) en Brasil— no tienen jurisdicción directa sobre Panera Bread, pero sí pueden actuar si residentes locales resultan afectados y el responsable del tratamiento tiene presencia o dirige servicios al mercado regional.

    El próximo hito crítico es la notificación formal de Panera Bread a reguladores estadounidenses, cuyo plazo bajo legislaciones estatales como la de California (CCPA/AB 825) puede ser de 30 a 72 horas desde la confirmación del incidente: esa comunicación determinará el alcance real y habilitará eventuales acciones de autoridades en otras jurisdicciones.

  • AWS confirma pérdida permanente de datos en Medio Oriente por ataques iraníes

    AWS confirma pérdida permanente de datos en Medio Oriente por ataques iraníes

    Amazon Web Services confirmó que recursos de clientes alojados en sus regiones de Baréin y Emiratos Árabes Unidos son irrecuperables tras ataques iraníes que superaron la redundancia regional diseñada para resistir fallas. Una zona de disponibilidad en los EAU permanece inaccesible, según se informó el 16 de septiembre de 2026.

    Los impactos afectaron infraestructura física de AWS en dos regiones del Medio Oriente. En Baréin, los ataques sobrepasaron los mecanismos de redundancia entre zonas de disponibilidad —el esquema de aislamiento de fallas que AWS considera su primera línea de resiliencia—, dejando datos de clientes sin posibilidad de recuperación. En los EAU, al menos una zona de disponibilidad quedó directamente inaccesible, según se informó. AWS no especificó públicamente el volumen de recursos afectados ni el número de clientes impactados.

    Datos confirmados al 16 de septiembre de 2026

    • Región AWS Baréin (me-south-1): redundancia regional superada, recursos declarados irrecuperables.
    • Región AWS EAU (me-central-1): al menos una zona de disponibilidad inaccesible.
    • Causa confirmada por AWS: daño físico por ataques iraníes.
    • Fecha de comunicación oficial: 16 de septiembre de 2026.
    • Volumen de datos perdidos y número de clientes afectados: no divulgados.

    Qué se sabe y qué falta confirmar

    AWS reconoció la pérdida permanente de recursos, lo que implica que los SLA estándar de durabilidad —incluida la promesa de 99,999999999% (11 nueves) para Amazon S3— no cubren escenarios de daño físico por conflicto armado, situación expresamente excluida en las condiciones de servicio bajo la cláusula de fuerza mayor. No se confirmó si AWS activó procedimientos de notificación a clientes bajo marcos regulatorios aplicables, ni si existen clientes bajo jurisdicciones con obligaciones de notificación de brechas —como el GDPR en su extensión a empresas con filiales europeas— que procesen datos en esas regiones. Tampoco se informó si hay plazos de restablecimiento parcial de la zona EAU afectada.

    Para organizaciones latinoamericanas con operaciones en Medio Oriente —incluidas empresas con presencia en los EAU bajo acuerdos de libre comercio con México, y compañías con filiales en Baréin vinculadas a grupos financieros de Brasil o Argentina—, el escenario expone un riesgo que los marcos de gobernanza de datos de la región raramente contemplan: la pérdida definitiva de datos en la nube por eventos de fuerza mayor en zonas geopolíticamente inestables. Las políticas de respaldo multi-región fuera del área de conflicto serán el criterio diferenciador entre organizaciones que recuperen operaciones y las que no.

    El próximo hito crítico es la comunicación formal de AWS a clientes afectados con detalle de recursos irrecuperables, que determinará si se activan obligaciones de notificación regulatoria en las jurisdicciones de cada cliente.

  • Brecha en Revolut expone pasaportes y registros de transacciones

    Brecha en Revolut expone pasaportes y registros de transacciones

    Revolut, el neobanco británico con operaciones en varios países de América Latina, sufrió una brecha de seguridad que expuso pasaportes y registros de transacciones de clientes, según informó el medio especializado Safestate el 14 de septiembre de 2026. La magnitud exacta del incidente —número de afectados, ventana temporal de exposición y geografías involucradas— no había sido confirmada públicamente al momento de publicación.

    La información publicada indica que entre los datos comprometidos figuran documentos de identidad —pasaportes— y registros de movimientos financieros, una combinación especialmente sensible porque habilita tanto el robo de identidad como la reconstrucción del perfil económico de las personas afectadas. Según se informó, el incidente fue revelado por fuentes externas a la compañía, sin que Revolut haya emitido una comunicación oficial detallada al momento del reporte.

    Datos confirmados al cierre de esta edición

    • Tipos de datos expuestos: documentos de pasaporte y registros de transacciones financieras, según Safestate.
    • Actor involucrado: Revolut, fintech con licencia bancaria en la Unión Europea y presencia en mercados de LATAM.
    • Fecha del reporte: 14 de septiembre de 2026.
    • Número de afectados: no confirmado públicamente.
    • Vector de ataque: no divulgado.

    Qué se sabe y qué falta confirmar

    Lo confirmado hasta ahora es la naturaleza de los datos expuestos: documentación de identidad y registros financieros. Lo que permanece sin verificar es si el incidente involucra clientes de jurisdicciones latinoamericanas —donde Revolut ha expandido operaciones—, qué período de tiempo abarca la exposición, y si existió exfiltración activa o se trató de una exposición accidental. Tampoco se ha confirmado si Revolut notificó a las autoridades de protección de datos correspondientes, obligación exigible bajo la normativa europea (GDPR, artículo 33) en un plazo de 72 horas desde el conocimiento del incidente.

    En América Latina, la exposición de pasaportes activa obligaciones similares bajo marcos como la Ley 25.326 de Argentina, la LGPD brasileña (artículo 48, notificación a la ANPD y a los titulares en plazo razonable) y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares de México. Si clientes de estas jurisdicciones están entre los afectados, las autoridades de control —AAIP en Argentina, ANPD en Brasil, INAI en México— tendrían competencia para requerir información y, en su caso, iniciar actuaciones.

    El próximo hito crítico es la confirmación —o desmentida— oficial de Revolut sobre el alcance geográfico del incidente y el estado de las notificaciones regulatorias, dato que determinará qué autoridades de protección de datos en LATAM pueden activar sus facultades de investigación.

  • Silent Ransom Group atacó a Greenberg Traurig: 126.000 afectados sin notificador claro

    Silent Ransom Group atacó a Greenberg Traurig: 126.000 afectados sin notificador claro

    El grupo de ransomware Silent Ransom Group (SRG) comprometió los sistemas de Greenberg Traurig, uno de los estudios jurídicos más grandes del mundo, y publicó los datos en su sitio de filtraciones. Según informó DataBreaches.net, el incidente afecta a unas 126.000 personas y plantea una pregunta sin respuesta clara: quién tiene la obligación de notificarlas.

    Greenberg Traurig figura en la lista de firmas atacadas por SRG, un grupo que al 21 de agosto ya acumulaba 64 estudios jurídicos en su sitio de filtraciones, entre ellos Troutman Pepper Locke, cuya brecha fue reportada ese mismo día. La incorporación de Greenberg Traurig al listado fue confirmada el 14 de septiembre de 2026, según se informó, con detalles exclusivos proporcionados por DataBreaches.net. El estudio tiene presencia en múltiples jurisdicciones de América y Europa, lo que agrega capas de complejidad regulatoria al análisis de notificación.

    Datos confirmados del incidente

    • Actor de amenaza: Silent Ransom Group (SRG)
    • Firma afectada: Greenberg Traurig
    • Personas potencialmente afectadas: 126.000
    • Publicación en sitio de filtraciones: confirmada al 14 de septiembre de 2026
    • SRG acumulaba al menos 64 firmas legales en su leak site al 21 de agosto de 2026
    • Incidente previo vinculado al mismo grupo: Troutman Pepper Locke (reportado el 21 de agosto de 2026)

    Qué se sabe y qué falta confirmar sobre la notificación a los 126.000 afectados

    El nudo central de este incidente no es técnico sino regulatorio: los datos comprometidos corresponden presumiblemente a clientes, contrapartes y empleados cuyos registros fueron procesados por el estudio en nombre de terceros. Eso abre el debate sobre si Greenberg Traurig actúa como responsable del tratamiento o como encargado —distinción crítica bajo el GDPR europeo, la LGPD brasileña (Lei 13.709/2018) y la Ley 25.326 argentina. En jurisdicciones como Brasil, el encargado puede tener obligación directa de notificar a la Autoridade Nacional de Proteção de Dados (ANPD) si el incidente afecta a titulares brasileños; en Argentina, la notificación a la AAIP depende de quién figure como responsable registrado. En México, la LFPDPPP impone al responsable —no al encargado— la carga de la notificación, aunque sin un plazo fijo expresamente establecido para brechas. Esta ambigüedad no es menor: con 126.000 personas involucradas y un estudio con clientes en varias jurisdicciones latinoamericanas, la cadena de notificación podría involucrar a múltiples empresas clientes sin que ninguna haya activado aún el proceso, según se informó.

    Lo que falta confirmar incluye: el tipo de datos exfiltrados (si son datos sensibles, la urgencia regulatoria se incrementa en todas las jurisdicciones mencionadas), qué clientes corporativos de Greenberg Traurig están entre los afectados y si el estudio ha emitido alguna comunicación formal a las partes interesadas. Al cierre de esta nota, no había declaración pública de la firma.

    El plazo de notificación bajo la LGPD es de hasta 72 horas para comunicar a la ANPD los incidentes de alto riesgo; si hay titulares brasileños entre los 126.000 afectados, ese reloj ya está corriendo.

  • Colombia: 6 de cada 10 ciberataques apuntan al sector salud

    Colombia: 6 de cada 10 ciberataques apuntan al sector salud

    Seis de cada diez ciberataques registrados en Colombia tienen como blanco instituciones del sector salud, según un reporte de Biofile que toma como base mediciones del IBM X-Force Index. La cifra posiciona a hospitales y clínicas colombianas como el principal objetivo de amenazas digitales en el país, y dispara preguntas urgentes sobre el estado de la gobernanza de datos en el sistema sanitario.

    El dato fue reportado el 13 de septiembre de 2026 por Joseph Freixes en DataBreaches.net, citando el informe de Biofile. La concentración del 60% de los ataques en un solo sector no es casualidad: la información médica combina datos sensibles de alta demanda en mercados ilegales — diagnósticos, historiales clínicos, números de identificación, datos de cobertura — con entornos tecnológicos históricamente subfinanciados en materia de seguridad y gobernanza. No se ha confirmado públicamente el número total de incidentes sobre el que se calcula ese porcentaje, ni si todos los casos involucraron exfiltración confirmada de datos.

    Qué falló: clasificación, ownership y controles de acceso en hospitales colombianos

    Cuando el sector salud concentra la mayoría de los ataques exitosos, el problema raramente es solo técnico. Desde la perspectiva del DAMA-DMBOK, los hospitales colombianos enfrentan déficits estructurales en tres capabilities críticas: clasificación de datos (data classification), definición de propietarios del dato (data ownership) y control de acceso basado en roles. Sin un catálogo activo que distinga qué registros son críticos y quién responde por ellos, cualquier vector de entrada —ransomware, credenciales comprometidas, acceso indebido— puede moverse lateralmente sin fricción. El marco CDMC del EDM Council establece que los controles de seguridad de datos deben estar alineados con la clasificación formal; en entornos hospitalarios públicos de Colombia, ese alineamiento es, en la mayoría de los casos, inexistente o informal.

    Colombia cuenta con la Ley 1581 de 2012 de Protección de Datos Personales y su decreto reglamentario 1377 de 2013, que obligan a los responsables del tratamiento a implementar medidas de seguridad adecuadas para proteger datos sensibles — categoría en la que cae explícitamente la información de salud. La Superintendencia de Industria y Comercio (SIC) es la autoridad de control con facultades sancionatorias. Sin embargo, la brecha entre el marco legal vigente y la capacidad operativa real de los hospitales públicos para implementar gobernanza efectiva sigue siendo amplia. La SIC no ha publicado, hasta la fecha de este reporte, sanciones consolidadas específicas contra instituciones de salud por fallas de seguridad.

    Señal para CDOs y data stewards del sector salud en la región

    El patrón colombiano no es aislado. En Brasil, la ANPD ha señalado al sector salud como uno de los más expuestos bajo la LGPD, y en Argentina la AAIP ha recibido notificaciones de incidentes en clínicas privadas bajo la Ley 25.326. Lo que diferencia a las organizaciones que contienen el daño de las que no es la existencia de un programa activo de gobernanza: inventario de activos de datos, data stewards designados por dominio clínico, y procedimientos de notificación ensayados. Un CDO o responsable de datos en un hospital colombiano debería, como primer paso, mapear qué sistemas contienen datos de pacientes, quién tiene acceso hoy y si ese acceso está documentado y justificado. Esa auditoría de acceso — ejecutable en días con herramientas básicas — es el insumo mínimo para una conversación real con la dirección sobre riesgo.

    • Confirmar si existe un inventario formal de bases de datos con información de pacientes y su nivel de clasificación.
    • Identificar al data steward responsable por cada dominio clínico (historiales, facturación, laboratorio).
    • Revisar si los procedimientos de notificación a la SIC ante incidentes están documentados y tienen un responsable asignado.
    • Evaluar si los controles de acceso están alineados con la clasificación de datos sensibles exigida por la Ley 1581.

    Mientras el 60% de los ataques digitales en Colombia sigan concentrándose en un sector que gestiona la información más sensible de las personas, la pregunta no es si las instituciones de salud serán el próximo blanco — sino si sabrán qué datos tenían cuando ya sea tarde.

  • Agencia Digital de Japón: 246.000 registros de empleados posiblemente comprometidos

    Agencia Digital de Japón: 246.000 registros de empleados posiblemente comprometidos

    La Agencia Digital de Japón informó que aproximadamente 246.000 conjuntos de datos personales —incluyendo nombres y direcciones de correo electrónico de empleados gubernamentales— podrían haber sido comprometidos tras un acceso no autorizado a uno de sus sistemas de red. Hasta el momento, según se informó, no se registraron daños secundarios como uso indebido de la información.

    El incidente fue comunicado públicamente por la propia agencia el viernes 11 de septiembre. El organismo, creado en 2021 para impulsar la digitalización del Estado japonés, opera infraestructura crítica de gobierno electrónico y gestiona datos de funcionarios de múltiples reparticiones. La notificación fue reportada originalmente por Jiji Press. No se precisaron en la información disponible la fecha exacta del acceso no autorizado ni el vector de ataque utilizado.

    Datos confirmados al cierre de esta nota

    • Registros potencialmente comprometidos: aproximadamente 246.000 conjuntos de datos personales.
    • Tipo de datos expuestos: nombres y direcciones de correo electrónico de empleados gubernamentales.
    • Sistema afectado: red operada por la propia Agencia Digital de Japón.
    • Daños secundarios confirmados: ninguno hasta la fecha del anuncio.
    • Fecha de divulgación pública: 11 de septiembre de 2026.

    Qué se sabe y qué falta confirmar

    La agencia utilizó el término “posiblemente comprometidos” en su comunicación, lo que indica que la investigación forense no ha concluido y que la exfiltración efectiva de datos no está aún confirmada. Permanecen sin precisar el vector de intrusión, la duración del acceso no autorizado, si los registros corresponden exclusivamente a empleados activos o también a ex funcionarios, y si se activaron protocolos de notificación individual a los afectados. Tampoco se informó si el incidente fue reportado a la Comisión de Protección de Información Personal de Japón (PPC), la autoridad de control equivalente a las APDs de la región.

    El caso tiene relevancia más allá de Japón: una agencia cuya función central es la gobernanza digital del Estado sufrió un incidente en su propia infraestructura, lo que pone en cuestión los controles de acceso sobre sistemas que concentran datos de empleados públicos a escala nacional. En América Latina, organismos equivalentes como la Secretaría de Gobierno Digital de Argentina o la Secretaría de Transformación Digital de Brasil gestionan volúmenes similares de datos de empleados del Estado, sin que existan en todos los casos marcos de notificación de brechas con plazos obligatorios comparables. La Ley 25.326 de Argentina y la LGPD brasileña establecen el deber de notificación a la autoridad de control, pero los plazos y criterios de significatividad varían, y la aplicación a organismos públicos sigue siendo dispar en la práctica.

    El próximo hito a seguir es la confirmación o descarte de exfiltración efectiva por parte de la Agencia Digital de Japón, y la eventual comunicación a la PPC, que determinará si corresponde notificación individual a los 246.000 empleados potencialmente afectados.

  • Veradigm: banda criminal reclama 3,5 millones de registros de salud

    Veradigm: banda criminal reclama 3,5 millones de registros de salud

    Un grupo criminal afirma haber exfiltrado 3,5 millones de registros de Veradigm, empresa estadounidense de tecnología para el sector salud, en un incidente reportado el 10 de septiembre de 2026. La compañía aún no ha confirmado oficialmente la magnitud ni el origen del compromiso.

    Veradigm —antes conocida como Allscripts Healthcare Solutions— provee plataformas de datos clínicos, registros médicos electrónicos y servicios de analítica para hospitales, consultorios y aseguradoras en Estados Unidos y mercados internacionales. Según se informó, un grupo de ciberdelincuentes publicó la reivindicación del ataque y asegura tener en su poder 3,5 millones de registros con información de pacientes y proveedores de salud. La divulgación fue detectada por investigadores de seguridad que monitorearon foros de filtración en la dark web.

    Datos confirmados al momento del reporte

    • Volumen reclamado por el grupo criminal: 3,5 millones de registros
    • Empresa afectada: Veradigm (ex-Allscripts), sector healthtech, EE.UU.
    • Fecha de la divulgación pública: 10 de septiembre de 2026
    • Confirmación oficial de Veradigm: pendiente al cierre de esta nota
    • Tipo de datos potencialmente comprometidos: no especificado con precisión en la reivindicación

    Qué se sabe y qué falta confirmar

    Lo que está confirmado es la existencia de la reivindicación pública del grupo criminal y el número de registros que alegan haber obtenido. Lo que permanece sin verificar es si la exfiltración efectivamente ocurrió, qué campos específicos contienen los registros —nombres, diagnósticos, números de seguro, datos de facturación— y si el incidente corresponde a un ataque reciente o a datos acumulados de brechas anteriores. Veradigm ya protagonizó incidentes de seguridad en años previos, incluyendo un ataque de ransomware en 2023 que afectó la operación de farmacias en EE.UU., lo que añade contexto pero no confirma la vinculación con este nuevo reclamo.

    Para los equipos de privacidad y gobernanza de datos en América Latina que operen con proveedores de tecnología sanitaria de origen estadounidense, el incidente es una señal de alerta directa. Bajo la LGPD brasileña (Lei 13.709/2018), los datos de salud son clasificados como datos sensibles y su tratamiento exige salvaguardas reforzadas; lo mismo ocurre bajo el artículo 9 del GDPR europeo y, en el plano local, bajo las leyes de protección de datos de Argentina (Ley 25.326), México (LFPDPPP) y Colombia (Ley 1581/2012). Cualquier organización latinoamericana que haya compartido registros clínicos con Veradigm o sus plataformas integradas debe activar ya una revisión de los contratos de encargado de tratamiento y verificar si existe obligación de notificación ante la autoridad de control local.

    El próximo hito crítico es la notificación regulatoria que Veradigm deberá realizar ante el Departamento de Salud de EE.UU. (HHS/OCR) bajo la HIPAA Breach Notification Rule, cuyo plazo estándar es de 60 días desde que la organización toma conocimiento del incidente.

  • ShinyHunters expone 6,4 millones de registros de McKesson

    ShinyHunters expone 6,4 millones de registros de McKesson

    El grupo de extorsionistas seriales ShinyHunters expuso datos de aproximadamente 6,4 millones de personas en un ataque contra McKesson, uno de los mayores proveedores de insumos médicos y farmacéuticos del mundo. La escala del incidente se conoció recién el 10 de septiembre de 2026, cuando el servicio Have I Been Pwned (HIBP) incorporó los datos filtrados a su base de consulta pública.

    El ataque ocurrió el mes anterior a la divulgación, aunque McKesson no había informado públicamente la magnitud del compromiso hasta que HIBP lo reveló de forma indirecta al indexar los registros. Según se informó, ShinyHunters habría reclamado la extracción de 284 millones de documentos de los sistemas de la compañía — una cifra que excede en varios órdenes de magnitud el número de individuos afectados confirmado hasta ahora, lo que sugiere duplicación de registros o extracción masiva de transacciones y documentos internos.

    Datos confirmados al cierre de esta edición

    • 6,4 millones de individuos afectados, según HIBP.
    • 284 millones de documentos reclamados por ShinyHunters como volumen total extraído.
    • McKesson identificada como empresa del sector médico-farmacéutico.
    • Fecha del ataque: agosto de 2026, según se informó.
    • La incorporación a HIBP el 10 de septiembre fue la primera confirmación pública de escala.

    Qué se sabe y qué falta confirmar

    HIBP confirmó el número de individuos afectados al añadir los datos a su sistema de notificación. No obstante, la naturaleza exacta de los datos expuestos — si incluye información clínica, financiera o únicamente datos de contacto — no había sido detallada de forma oficial por McKesson al momento de esta publicación. Tampoco se había confirmado si la compañía cumplió con los plazos de notificación obligatoria exigidos por las regulaciones aplicables en Estados Unidos (HIPAA) ni si se notificó a autoridades de otros países donde opera. ShinyHunters es un grupo con antecedentes documentados de ataques de alto perfil, incluyendo el caso Snowflake en 2024, lo que le otorga credibilidad técnica a la magnitud del reclamo, aunque los 284 millones de documentos no han sido verificados de forma independiente.

    Para los equipos de cumplimiento en América Latina, la nota de alerta es doble. McKesson opera en mercados de la región a través de subsidiarias y redes de distribución farmacéutica. Si datos de pacientes o clientes latinoamericanos fueron comprometidos, las empresas locales que mantienen relaciones comerciales con el proveedor quedan expuestas a obligaciones de notificación propias: en Brasil bajo la LGPD (artículo 48, plazo de dos días hábiles al titular y a la ANPD en casos de riesgo relevante), en México bajo la LFPDPPP, y en Argentina bajo la Ley 25.326 y las disposiciones de la AAIP. La cadena de responsabilidad no termina en el proveedor extranjero si hay transferencia internacional de datos involucrada.

    El próximo hito clave es la notificación formal de McKesson a los reguladores de salud en Estados Unidos, cuyo plazo bajo HIPAA es de 60 días desde la detección del incidente: si el ataque ocurrió en agosto, ese plazo vence en octubre de 2026.