Lo que RingCentral ha confirmado realmente

El propio boletín de seguridad de RingCentral en su Trust Center, fechado el 28 de julio de 2026 y calificado de gravedad ALTA, afirma que la empresa "descubrió recientemente que era objetivo de una sofisticada campaña de ingeniería social" y que "tomó medidas de inmediato para detener la actividad no autorizada" con ayuda de una firma forense externa. El boletín añade: "este incidente ha afectado a los datos de una parte limitada de los clientes de RingCentral, y estamos comunicándonos directamente con los clientes afectados. Si RingCentral no le ha contactado, usted no está afectado."

El grupo extorsionador ShinyHunters reivindicó el ataque un día antes, el 27 de julio de 2026, afirmando haber sustraído 623 GB de datos, y después publicó un archivo de 280 GB al no recibir el pago de RingCentral. Have I Been Pwned procesó ese archivo y lo incorporó a su base de datos el 13 de agosto de 2026: cerca de 1,6 millones de direcciones de correo únicas, junto con nombres, teléfonos y direcciones físicas. RingCentral ha sido explícita en que la brecha no alcanzó RingEX, RingCentral Contact Center, RingCX ni ningún otro servicio central, que según la empresa "siguen funcionando sin interrupción."

Un patrón de proveedores, no de víctimas

ShinyHunters ha repetido en 2026 el mismo guion contra un proveedor SaaS tras otro: instancias de clientes de Salesforce, datos de clientes alojados en Snowflake e implementaciones de Oracle PeopleSoft, con el propio grupo cifrando el botín conjunto de todas sus campañas en más de 1.500 millones de registros. RingCentral es el nombre más reciente de esa lista, y el método que la propia empresa describe, una persona convencida para ceder acceso, en lugar de un fallo que el atacante tuviera que encontrar, encaja con una tendencia más amplia de 2026: campañas de vishing e ingeniería social que triunfan contra empleados con acceso privilegiado en el proveedor, no en el cliente.

Esa distinción importa para cualquiera que evalúe a RingCentral como proveedor. Un cliente puede parchear su propio software y rotar sus propias credenciales, pero no tiene forma de comprobar, ni siquiera de ver, cuán bien resiste el personal de soporte y administración de un proveedor una llamada convincente. Aquí el objetivo fue la plantilla de RingCentral, no su código.

El vacío en el registro de riesgo de proveedores

Las entidades financieras sujetas al Reglamento de Resiliencia Operativa Digital de la UE deben mantener, según los artículos 28 a 30 del DORA, un registro de información sobre cada proveedor de TIC y evaluar el riesgo que cada uno representa para su propia resiliencia. Las entidades esenciales e importantes bajo la Directiva NIS2 cargan con una obligación paralela en el artículo 21 para gestionar el riesgo de ciberseguridad de la cadena de suministro, incluidas las prácticas de seguridad de sus proveedores directos. Ambos marcos dan por hecho que la entidad regulada puede obtener de un proveedor el detalle suficiente para evaluar de verdad su riesgo.

El boletín de RingCentral no nombra el puesto del empleado afectado, el sistema interno al que accedió el atacante, ni qué control, autenticación multifactor, verificación por llamada de retorno, comprobación de identidad en soporte, falló para que una llamada telefónica acabara en una brecha. Un banco alemán, un grupo hospitalario neerlandés o una aseguradora británica que incluya a RingCentral en su registro de proveedores de TIC no tiene nada concreto que añadir a esa entrada más allá de que ocurrió un incidente. El cuestionario habitual de seguridad de proveedores, un certificado SOC 2, un certificado de cifrado en reposo, un resumen de pentest, evalúa precisamente los controles técnicos que nunca entraron en juego en un incidente que empezó y terminó con una conversación.

Lo que un operador debería cambiar de verdad

La solución práctica no es otro papeleo de cifrado. Los operadores que dependen de RingCentral, o de cualquier proveedor de UCaaS o CCaaS que sirva a clientes regulados, deberían preguntar directamente al proveedor si realiza sus propias pruebas simuladas de ingeniería social contra el personal de soporte y administración, y tratar la respuesta, o la negativa a responder, como una entrada en su propio registro de riesgo.

Las renovaciones de contrato posteriores a esta divulgación son el momento de añadir una cláusula concreta: el derecho a un análisis técnico posterior al incidente, no una declaración de marketing, dentro de un plazo fijo tras cualquier incidente confirmado. Sin esa cláusula, el próximo aviso de brecha de un proveedor sonará exactamente como este, completo y conforme sobre el papel, pero inútil para el único documento, el registro de riesgo, que la regulación realmente exige mantener actualizado a un operador.

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