Auditoría de Seguridad de Cursor Descubre Cuatro Vulnerabilidades en el Editor de Código, pero la Autorización Permanece Segura

Una auditoría de seguridad de Cursor reveló un resultado raro para herramientas de IA: el investigador no pudo eludir la autorización del servidor y obtener acceso a modelos premium a través de una vulnerabilidad del cliente, pero encontró cuatro problemas notables en el perímetro de seguridad en el camino. La revisión es interesante precisamente porque no es una historia sobre "todo se rompió", sino más bien un examen detallado de cómo se estructura un editor de código con IA—uno que canaliza grandes volúmenes de código y solicitudes de desarrolladores a través de sus servidores. La investigación comenzó con la descompilación del cliente Electron de Cursor, construido sobre VS Code.

En un único archivo JavaScript minificado que excede 1,1 millones de líneas, el autor recuperó descripciones protobuf, un mapa de API, lógica OAuth y una lista de feature gates. Por separado, demostró que el token JWT del usuario no contiene claims sobre suscripción o plan: los derechos de acceso a los modelos no se verifican en el lado del cliente ni a través del contenido del token, sino en el servidor, basándose en datos de la base de datos. Para un producto SaaS con LLMs costosos, esta es una decisión arquitectónica clave, precisamente porque tal esquema impide que un usuario "gratuito" simplemente falsifique parámetros locales y desbloquee Claude 4 Opus u otro modelo premium.

Después de la ingeniería inversa del API, el investigador pasó a los ataques en el API. El primer hallazgo—contaminación de prototipos en endpoints JSON relacionados con suscripción y promociones. Si se añaden campos como __proto__ o constructor.

prototype al cuerpo de la solicitud, el servidor devuelve un error 500 Internal Server Error en lugar del rechazo esperado. Esto no otorga actualizaciones automáticas de plan, pero muestra que la contaminación de la cadena de prototipos ocurre antes de las verificaciones de lógica empresarial y puede alterar la ruta de validación. El segundo problema—un campo oculto devRawModelSlug en AgentRunRequest.

No existe en el esquema del cliente, pero los servidores de producción aceptan este campo, reconocen su nombre y responden con un error separado que revela que el sistema tiene un mecanismo dev para especificar directamente el modelo backend, eludiendo el enrutamiento estándar. Actualmente esta ruta está deshabilitada, pero su mera presencia en el perímetro de producción aumenta el riesgo de errores de configuración. Dos vulnerabilidades más no provienen del evasión de suscripción, sino de la exposición innecesaria de la arquitectura interna y la validación incompleta.

Un método interno responde con "Invalid internal service header", del cual se puede deducir que el endpoint existe, está protegido por autorización separada entre servicios y espera un encabezado especial. Para un cliente externo, tal detalle es innecesario: sería más seguro responder con un 404 o 401 universal sin pistas internas. Además, la auditoría reveló que algunos campos protobuf para escenarios de subagente aceptan enlaces a modelos premium sin una verificación de plan separada.

En la práctica, esto no cambia el modelo de respuesta real y no abre una evasión, porque el enrutamiento ignora estos campos de todas formas, pero tal lógica expande la superficie de ataque y podría convertirse en un problema después de futuros cambios de producto. Una parte importante de la revisión—una lista de vectores que no funcionaron. El autor probó fuerza bruta de nombres de modelos, suplantación de claims JWT, inyección de callback OAuth, reproducción de webhook Stripe, confusión entre requested_model y model_details, conflictos de tipos de wire protobuf y condiciones de carrera alrededor de suscripción.

Ninguna evasión significativa tuvo éxito en ningún lado. El servidor rechaza etiquetas protobuf incorrectas, no confía en datos JWT, valida firmas de Stripe y mantiene verificaciones de plan centralizadas. Esto fortalece la conclusión: los problemas realmente existen, pero el modelo de seguridad básico de Cursor parece maduro y reflexivo en comparación con muchos servicios de IA que confían demasiado en el cliente.

El significado práctico de esta historia se extiende más allá del propio Cursor. Para desarrolladores de IA SaaS, esta es una buena lista de verificación: no almacene privilegios en tokens, verifique el plan en el servidor con cada solicitud, valide protobuf estrictamente y no deje campos dev en esquemas de producción. Para los usuarios, es una señal de que incluso los IDEs avanzados de IA tienen una superficie vulnerable alrededor de facturación, servicios internos y mecanismos de enrutamiento de modelos.

Y lo más importante: hoy en día, la seguridad de un producto de IA se define no por cuántos modelos soporta, sino por qué tan disciplinado es en separar el cliente de los derechos de acceso reales en el servidor.