5 short insights this week: A record $409M privacy fine, and not a hacker in sight · A 9.8 zero-day in PeopleSoft, no login required · npm is finally turning off the feature that kept getting you hacked…
En esta edición
- 01Una multa récord de 409 M$ en privacidad, y ni un hacker a la vista
- 02Una zero-day 9,8 en PeopleSoft, sin login necesario
- 03npm por fin apaga la función que no paraba de hackearte
- 04Primeros números de DORA: el 90% de los incidentes graves no fueron ciber
- 0510,9 millones de registros salieron de un armario sin cerrar
Recibe el próximo GRC Brief en tu correo.
Suscribirse a The GRC BriefUna multa récord de 409 M$ en privacidad, y ni un hacker a la vista
El regulador surcoreano de privacidad impuso a Coupang, el mayor minorista en línea del país, una multa de 624.700 millones de wones (unos 409 millones de dólares). Es la mayor sanción de protección de datos de la historia del país, casi cinco veces el récord anterior. La brecha expuso a unos 34 millones de clientes más 4,3 millones de no miembros, alrededor de dos tercios de la población. La causa no fue un hackeo sofisticado. Una cuenta de un antiguo contratista que nunca se desactivó se usó para exfiltrar la base de datos.
Fuente: The Record · reporting also by BleepingComputer
Mi análisis
Vuelve a leer la causa. No un Estado-nación. No un exploit ingenioso. Un tipo que se fue, y a quien nadie le revocó la llave. Esto es gestión de derechos 101. Es la parte más aburrida de un programa de seguridad, y es lo que le costó a Coupang la mayor multa de privacidad en la historia de su país.
Esto es lo que los presupuestos de seguridad siguen haciendo mal. Puedes gastar millones en detección y aun así perder una revisión de accesos trimestral. El ROI real para la mayoría de organizaciones no es otro EDR. Es el proceso de revisión de accesos que realmente funciona.
Y fíjate en qué convirtió una mala brecha en una multa récord: los básicos, otra vez. No cumplir el plazo de notificación, subestimar el alcance, no tener una respuesta clara a "por qué seguía activo este acceso". El regulador no multa por el hackeo. Multa por la mala gobernanza.
Una zero-day 9,8 en PeopleSoft, sin login necesario
Un fallo crítico en PeopleSoft de Oracle (CVE-2026-35273), valorado 9,8 sobre 10, permite a un atacante tomar el control del servidor con sólo acceso de red. Sin login, sin interacción de usuario. Mandiant de Google dice que un grupo que rastrea como UNC6240 lo estaba explotando entre el 27 de mayo y el 9 de junio. Oracle no publicó su aviso hasta el 10 de junio, lo que significa que fue una zero-day en vivo todo ese tiempo. Si ejecutas PeopleSoft, comprueba tu exposición hoy.
Fuente: The Hacker News · attribution by Google Mandiant
Mi análisis
PeopleSoft gestiona RR. HH. y nómina en una porción enorme de grandes organizaciones. Eso significa que se sienta sobre una mina de oro de identidad personal, y a menudo queda fuera de los inventarios de ataque porque es "sólo" interno. Excepto que éste está expuesto a internet mucho más a menudo de lo que la gente cree.
La parte incómoda es la cronología. Los atacantes estuvieron dentro desde el 27 de mayo. El parche llegó el 10 de junio. Para los equipos que parchean dos semanas después del aviso, eso son tres semanas de pre-explotación ciega. Esa es la brecha que tu programa de gestión de vulnerabilidades debería estar diseñado para cerrar, y la mayoría no lo están.
Ve a comprobar si tus endpoints de administración de PeopleSoft están expuestos. Hoy, no en el próximo sprint.
npm por fin apaga la función que no paraba de hackearte
GitHub anunció que npm versión 12, prevista para julio, dejará de ejecutar los scripts de instalación de dependencias por defecto. Durante años, un solo "npm install" podía ejecutar código desde cualquier paquete en cualquier parte de tu árbol de dependencias, en el momento en que lo traías, en portátiles de desarrolladores y runners de CI llenos de credenciales. Ése ha sido el apoyo detrás de una larga racha de ataques a la cadena de suministro. Desde v12, esos scripts (junto con otros patrones de hook de riesgo) están desactivados salvo override explícito.
Fuente: The Hacker News · GitHub announcement, 9 Jun 2026
Mi análisis
Esto es genuinamente una buena noticia, y también es una fecha límite. Buena, porque los scripts de instalación automáticos han sido uno de los caminos de ataque más tontos de la década. Fecha límite, porque "breaking changes" significa exactamente eso. Si tu pipeline de CI depende silenciosamente del script de instalación de un paquete para preconstruir algo, se va a romper en julio.
Aprovecha las próximas semanas para hacer un barrido. Detecta los paquetes que usan hooks de instalación (postinstall, preinstall) en tus dependencias directas. Pregúntate si los necesitas, o si era sólo cómodo. La mayoría era sólo cómodo.
Y ésta es una cuestión de gobernanza, no sólo de desarrollo. Quién en tu organización decide qué scripts de terceros se ejecutan en tus runners. Si la respuesta es "nadie", tienes un agujero de gobernanza, no un agujero técnico.
Primeros números de DORA: el 90% de los incidentes graves no fueron ciber
Las autoridades europeas de supervisión publicaron el primer informe de incidentes de DORA, la imagen más clara hasta la fecha de lo que realmente se rompe en las finanzas europeas. Las entidades financieras reportaron 3.383 incidentes TIC graves en 2025, unos 282 al mes. El hallazgo principal: sólo el 10% estaban relacionados con ciberseguridad. El resto fueron fallos de sistemas, caídas tecnológicas y eventos externos. Casi un tercio se rastreaban hasta problemas de terceros proveedores.
Fuente: European Banking Authority · ESAs first DORA incident report, 3 Jun 2026
Mi análisis
Siéntate con ese 10%. Con todos los titulares de ransomware, nueve de cada diez incidentes graves en las finanzas europeas en 2025 no fueron un atacante. Fue una actualización que salió mal, un proveedor que se cayó, un sistema que se quedó sin aire. Si todo tu mapa de riesgos está centrado en atacantes, estás mirando el 10% de la foto.
Éste es el caso de la resiliencia operativa en una sola estadística. Si todo tu programa de resiliencia es un plan de respuesta a incidentes cibernéticos, no estás preparado para lo más probable que te va a pasar. Estás preparado para lo que llena titulares.
El número que debería preocuparte más que el 10%: casi un tercio de los incidentes vinieron de terceros. Esto es exactamente lo que NIS 2 y DORA dicen sobre el riesgo de terceros. No son casillas contractuales. Es de donde vienen los cortes reales.
10,9 millones de registros salieron de un armario sin cerrar
Kyushu Electric, una de las mayores utilities regionales de Japón, reveló que un disco duro externo con datos de hasta 10,9 millones de clientes desapareció de su sala de servidores. La trastienda es dolorosamente ordinaria: sin almacenamiento, el personal de TI copió los datos a un disco externo el 27 de abril y lo guardó con llave en un armario seguro. El 26 de mayo volvieron para encontrar el armario sin cerrar y el disco se había ido.
Fuente: BleepingComputer · 11 Jun 2026
Mi análisis
Dos puntos en este brief ya, y ni un solo hacker detrás de ninguna de las mayores pérdidas de datos. Coupang perdió 34 millones de registros por una cuenta olvidada. Kyushu perdió 10,9 millones por un armario sin cerrar. La seguridad física y la gestión de activos no son "el otro departamento" para los equipos de GRC. Son los controles fundamentales que aparecen en cada catástrofe.
Fíjate en lo que falta en la divulgación: cualquier mención al cifrado. Un disco con 10,9 millones de registros de clientes que no estaba cifrado en 2026 cuenta su propia historia sobre la madurez del programa. Y éste es exactamente el tipo de control básico que ISO 27001 Anexo A 8.24 (criptografía) espera por defecto para medios extraíbles.