Para: personas que usaron el chat de NEAR AI (Private Chat), NEAR AI Cloud o los agentes, y operadores que gestionan servidores de inferencia de IA o plataformas de agentes propios. Este artículo se basa en la entrada oficial del blog de NEAR AI y no trata pasos de ataque.
En desarrollo: este artículo se actualizará a medida que la organización publique más información
- A quién afecta
personas que usaron el chat de NEAR AI (Private Chat), NEAR AI Cloud o los agentes, y operadores que gestionan servidores de inferencia de IA o plataformas de agentes propios.
- Confirmado hasta ahoraVer la tabla ↓
- Punto de entrada
- Datos de cuenta (correo, nombre)
- Información de plan y saldo
2 más
- Agentes heredados
- Claves de API de NEAR AI Cloud
Señalado como posiblemente afectado
- Solicitudes en procesamiento (incluido el modo confidencial)
- Aún sin confirmar
- Cuándo se detectó la intrusión y cuándo entró por primera vez el atacante (el informe no lo indica)
- Si realmente se observaron las solicitudes en modo confidencial (la empresa dice que pudieron observarse)
- Si hacen falta notificaciones a los reguladores y cuáles (la empresa dice que hará las exigidas)
2 más
- El número exacto de usuarios afectados (la empresa dice que aproximadamente 100)
- Un identificador del fallo de SGLang (el informe no lo indica)
- Qué hacer ahoraVer los pasos ↓
- Compruebe si la empresa se puso en contacto con usted
- Desconfíe de los mensajes sobre su cuenta o su saldo
- Si escribió secretos en agentes o chats, rótelos (nuestra opinión)
2 más
- Si usa claves de API de NEAR AI Cloud, revise cómo las maneja
- Operadores de infraestructura de IA: revisen su propia configuración
- Dónde verificarlo (fuente)Todas las fuentes ↓
- NEAR AI, «Security Incident Report» (blog oficial, 9 de noviembre de 2026; consultado el 11 de noviembre; en inglés)
- Última comprobación
- A 11 de noviembre de 2026
Próximos avisos y qué comprobamos
El informe de la empresa tiene fecha del 9 de noviembre de 2026 y describe lo que la investigación ha confirmado «hasta la fecha». No da un calendario de nuevas actualizaciones. Cuando lo comprobamos el 11 de noviembre de 2026, no encontramos ninguna actualización del informe.
Qué deben hacer hoy los usuarios y los operadores de infraestructura de IA
Compruebe si la empresa se puso en contacto con usted
Según el informe de la empresa, los usuarios cuyos datos de cuenta confirmó que se habían consultado, y los propietarios de los 18 agentes, recibieron un aviso directo desde security@near.ai con los pasos que les corresponden. Revise también la carpeta de spam. Si recibió un mensaje, siga primero sus indicaciones.
Si no está seguro de que un mensaje sea auténtico, no abra sus enlaces; abra usted mismo el sitio oficial de la empresa. El contacto de la empresa es security@near.ai.
Desconfíe de los mensajes sobre su cuenta o su saldo
La empresa aconseja tratar con cautela los mensajes no solicitados que hagan referencia a su cuenta o a su saldo. Lo que se llevaron es una dirección de correo y un nombre, además de información de plan y saldo en algunas cuentas. Juntos permiten redactar mensajes falsos convincentes (un punto general). No abra los enlaces; compruebe su cuenta desde un marcador. Más en Qué es el phishing.
Si escribió secretos en agentes o chats, rótelos (nuestra opinión)
Lo que la empresa confirmó es que se obtuvieron el historial de chat, los ajustes y los registros de 18 agentes heredados y que, por separado, las claves de API de dos clientes de Cloud quedaron expuestas en registros (no se dice que se las llevaran). También dice que las solicitudes de usuarios en el servidor comprometido el 8 de noviembre pudieron observarse.
Si alguna vez puso una clave de API, una contraseña o una cadena de conexión en los ajustes de un agente o en un chat, rótela con quien la emitió, por precaución. No necesita esperar a saber si se vio. Sobre el manejo de claves, véase Variables de entorno y claves de API: lo básico.
Si usa claves de API de NEAR AI Cloud, revise cómo las maneja
La empresa dice que las claves expuestas en registros pertenecían a dos clientes de Cloud y se han revocado. El informe no da indicaciones sobre las claves de otros clientes. Revise dónde usa sus claves, elimine las que ya no use y compruebe que no las haya escrito en registros ni en historiales (nuestra opinión).
Operadores de infraestructura de IA: revisen su propia configuración
Lo que conviene comprobar en su propia infraestructura de inferencia y de agentes a la luz de este incidente se resume más abajo en «Qué deben revisar los operadores de infraestructura de IA».
Qué ocurrió (según el anuncio de NEAR AI)
Esta sección se basa en la entrada oficial del blog de NEAR AI «Security Incident Report» (9 de noviembre de 2026). Es el relato de la propia empresa y no ha sido verificado por un tercero. El informe no da horas del día.
Fecha no indicada
El atacante explota un fallo de ejecución remota de código en SGLang para ejecutar código en un servidor de inferencia y desde allí llega a la infraestructura de la empresa. La empresa no dice cuándo notó la intrusión.Dentro de lo que confirmó la investigación
El atacante llega a un sistema interno situado detrás del servicio Private Chat, ya retirado, y descarga datos de cuenta de unos 100 usuarios. También accede a 18 agentes heredados.8 de noviembre
El atacante pudo observar las solicitudes de los usuarios que se procesaban en el servidor comprometido, incluidas las del modo confidencial (la empresa).Tras la detección
La empresa revoca todas las sesiones activas y las credenciales administrativas, sustituye todos los tokens de agentes, deja Private Chat sin conexión y despliega una corrección en todos los servidores de inferencia. También completa la rotación del resto de credenciales y una revisión forense completa.9 de noviembre
La empresa publica su informe. El acceso se ha cerrado y se ha restablecido el acceso a NEAR AI Cloud. Se ha avisado directamente a los usuarios afectados.
Un servidor de inferencia
Código ejecutado por un fallo de SGLang
↓→
Otra infraestructura
Sistema interno, agentes heredados
↓→
9 de noviembre
Corregido, rotado, comunicado
- Punto de entrada
- Un fallo de ejecución remota de código en SGLang, el motor de inferencia de código abierto que funciona en los servidores de la empresa. Se ejecutó código en un servidor de inferencia y desde allí el atacante llegó a otra infraestructura
- Se llevaron (1)
- De un sistema interno situado detrás del servicio Private Chat, ya retirado: direcciones de correo y nombres de unos 100 usuarios y, en algunas cuentas, información de plan y saldo
- Se llevaron (2)
- El historial de chat, los ajustes y los registros de 18 agentes de un despliegue heredado de NEAR AI Agents que no se ejecutaban en el entorno de computación confidencial
- Expuestas en registros (revocadas)
- Las claves de API de NEAR AI Cloud de dos clientes de Cloud quedaron expuestas en registros (no se dice que se las llevaran). Las claves están revocadas
- Pudo verse
- El 8 de noviembre, las solicitudes de los usuarios que se procesaban en el servidor comprometido, incluidas las que se ejecutaban en modo confidencial
- Sin indicios de
- Acceso a las conversaciones almacenadas de Private Chat ni a los archivos subidos
- Respuesta de la empresa
- Revocó sesiones y credenciales administrativas, sustituyó los tokens de agentes, dejó Private Chat sin conexión, desplegó la corrección en todos los servidores de inferencia, rotó credenciales, completó una revisión forense completa, avisó a los usuarios afectados y comunicó el fallo al proyecto SGLang. Dice que hará las notificaciones a los reguladores que sean exigibles
- Contacto
- security@near.ai
Qué se sabe y qué no
El estado a 11 de noviembre de 2026. Actualizaremos la columna de estado cuando se publique más.
| Elemento | Contenido | Estado |
|---|---|---|
| Punto de entrada | Un fallo de ejecución remota de código en SGLang | Confirmado (la empresa) |
| Datos de cuenta (correo, nombre) | Se llevaron los datos de unos 100 usuarios | Confirmado (la empresa) |
| Información de plan y saldo | Se llevó en algunas cuentas | Confirmado (la empresa) |
| Agentes heredados | 18 accedidos; se obtuvieron historial de chat, ajustes y registros | Confirmado (la empresa) |
| Claves de API de NEAR AI Cloud | Claves de dos clientes de Cloud expuestas en registros; revocadas (no se dice que se las llevaran) | Confirmado (la empresa) |
| Solicitudes en procesamiento (incluido el modo confidencial) | Pudieron observarse el 8 de noviembre en el servidor comprometido | Posible (la empresa) |
| Conversaciones almacenadas de Private Chat | Sin indicios de acceso | No confirmado (la empresa) |
| Archivos subidos | Sin indicios de acceso | No confirmado (la empresa) |
| Contraseñas | No figuran en la lista de lo que se llevaron | No se indica |
| Números de tarjeta de pago | No figuran en la lista de lo que se llevaron | No se indica |
| Cuándo se notó la intrusión | No se indica | No se indica |
| Identificador (CVE) del fallo de SGLang | No se indica | No se indica |
| Notificaciones a los reguladores | La empresa dice que hará las exigidas | La empresa dice que hará las notificaciones exigidas |
Cómo leer esto: el relato de la empresa no ha sido verificado por un tercero
Las cifras de unos 100 usuarios, 18 agentes y dos clientes de Cloud son lo que la propia investigación de la empresa ha confirmado «hasta la fecha». La empresa dice que completó una revisión forense completa, pero el informe no dice si participó una firma externa ni qué halló. «Contraseñas» y «números de tarjeta de pago» simplemente no figuran en la lista de lo que se llevaron; la empresa no dijo que estuvieran excluidos.
Qué puede ocurrir cuando un servidor de inferencia tiene un fallo
Lo siguiente es general y no significa que haya ocurrido aquí. Lo que la empresa ha publicado como ocurrido se limita a «Qué ocurrió» más arriba.
Un servidor de inferencia recibe la entrada de los usuarios (prompts), la procesa con un modelo y devuelve la respuesta. Si se puede ejecutar código arbitrario en él, ese código puede alcanzar la entrada y la salida que el servidor está procesando. Si además el servidor tiene permisos o conexiones con otros sistemas internos, estos se convierten en la siguiente puerta de entrada.
La empresa explica que la computación confidencial protege frente al operador y el anfitrión, no frente a una vulnerabilidad en el software que se ejecuta dentro del entorno. La protección de la entrada depende por tanto de algo más que del límite exterior: de actualizar el software que se ejecuta dentro y de los permisos de los servicios circundantes.
Qué deben revisar los operadores de infraestructura de IA
Esta sección no evalúa la respuesta de la empresa ni adivina el contenido técnico del fallo. A partir del relato publicado, se limita a puntos que comprobar en su propia configuración, y son nuestra opinión.
Reduzca al mínimo lo que un servidor de inferencia puede alcanzar
En este relato, la ejecución de código en un servidor de inferencia llevó a otra infraestructura. No dar a un servidor de inferencia credenciales ni conexiones con sistemas de gestión internos y otros servidores, y limitar su tráfico a los destinos que necesita, puede reducir hasta dónde se extiende una máquina comprometida (nuestra opinión).
No deje atrás los sistemas internos de servicios retirados
Los datos de cuenta que se llevaron estaban en un sistema interno situado detrás del servicio Private Chat, ya retirado. En un servicio que deja de usar, no basta con apagarlo: borre los datos, revoque las credenciales y quítelo de la red. Lo que conserva es lo que queda expuesto cuando ocurre una brecha (nuestra opinión).
Lleve los entornos heredados al lado más fuerte de su aislamiento
Los 18 agentes estaban en un despliegue heredado que no se ejecutaba en el entorno de computación confidencial. Reforzar un entorno nuevo deja el heredado como el lado débil. Migre o fije una fecha para retirarlo, y aplique mientras tanto los mismos límites de permisos (nuestra opinión).
Mantenga los secretos fuera de los registros
La empresa dice que las claves de API de dos clientes de Cloud quedaron expuestas en registros. No escriba en los registros las cabeceras de las solicitudes ni los ajustes tal cual, enmascare claves y tokens y limite el acceso al lugar donde se guardan los registros. Prepare de antemano los pasos para revocar una clave con rapidez si llega a aparecer en un registro (nuestra opinión). Otro caso centrado en el manejo de claves es El incidente de seguridad de Northflank.
Tenga un camino para desplegar rápido en todos los servidores las actualizaciones del motor de inferencia
La empresa desplegó la corrección en todos los servidores de inferencia y comunicó el fallo al proyecto SGLang. Si usa un motor de inferencia de código abierto, mantener una vía de despliegue que pueda llevar rápido a todos los servidores una corrección publicada, y un inventario de las versiones que ejecuta, acorta el tiempo entre darse cuenta y corregir (nuestra opinión). Otra intrusión en infraestructura de IA se trata en La intrusión en Hugging Face (en inglés).
Fuentes (registros públicos)
Los hechos de este artículo proceden de la siguiente información pública. No se tratan detalles de pasos de ataque.
- NEAR AI, «Security Incident Report» (blog oficial, 9 de noviembre de 2026; consultado el 11 de noviembre; en inglés) — near.ai
Historial de actualizaciones
2026-11-11: Primera versión. Basada en la entrada oficial del blog de NEAR AI (9 de noviembre de 2026). Actualizaremos cuando se publique más información.
Lectura recomendada
- Un caso centrado en el manejo de claves en infraestructura de IA: El incidente de seguridad de Northflank (octubre de 2026)
- Se explotó un fallo en un servidor de conexión de IA: El fallo del servidor MCP de mittwald
- IA actuando de forma autónoma en un ataque: La intrusión en Hugging Face (2026) (en inglés)
- Manejo de claves: Variables de entorno y claves de API: lo básico / Qué es el phishing
- Otros incidentes de 2026: Filtraciones de datos y ciberataques de 2026 (en inglés)