Una auditoría de Cursor halla cuatro vulnerabilidades en las defensas del editor de código, pero no logra romper la autorización

La auditoría de seguridad de Cursor arroja un resultado poco habitual entre las herramientas de IA: el investigador no consiguió eludir la autorización del servidor ni acceder a modelos premium mediante una vulnerabilidad del cliente, pero por el camino encontró cuatro problemas relevantes en su perímetro de seguridad. El análisis resulta interesante precisamente porque no es una historia de «todo está roto», sino una revisión detallada de cómo funciona un editor con IA por cuyos servidores pasan grandes volúmenes de código y peticiones de desarrolladores. La investigación empezó con la descompilación del cliente Electron de Cursor, construido sobre VS Code.

En un único archivo JavaScript minificado de más de 1,1 millones de líneas, el autor reconstruyó las definiciones protobuf, el mapa de la API, la lógica OAuth y la lista de feature gates. También demostró que el token JWT del usuario no contiene claims sobre la suscripción ni el plan: los permisos de acceso a los modelos no se comprueban en el cliente ni a través del contenido del token, sino en el servidor, con datos de la base de datos. Para un producto SaaS con LLM caros, esta es una decisión de arquitectura clave, porque es justo este esquema el que impide que un usuario «gratuito» simplemente modifique parámetros locales y se habilite Claude 4 Opus u otro modelo premium.

Tras la ingeniería inversa, el investigador pasó a atacar la API. El primer hallazgo fue un prototype pollution en los endpoints JSON vinculados a la suscripción y las promociones. Si se añaden al cuerpo de la petición campos como __proto__ o constructor.

prototype, el servidor devuelve un 500 Internal Server Error en lugar del rechazo esperado. Esto no otorga una mejora automática de plan, pero demuestra que la contaminación de la prototype chain se produce antes de las comprobaciones de negocio y puede alterar el flujo de validación. El segundo problema es el campo oculto devRawModelSlug en AgentRunRequest.

No figura en el esquema del cliente, pero los servidores de producción lo aceptan, reconocen su nombre y responden con un error específico que revela la existencia de un mecanismo dev para indicar directamente el modelo de backend saltándose el routing estándar. Ahora mismo esa vía está desactivada, pero su mera presencia en el entorno de producción aumenta el riesgo de errores de configuración. Las otras dos vulnerabilidades no tienen que ver con eludir la suscripción, sino con una exposición innecesaria de la arquitectura interna y una validación incompleta.

Uno de los métodos internos responde con el mensaje Invalid internal service header, que permite deducir que el endpoint existe, está protegido por una autorización service-to-service propia y espera una cabecera especial. Un cliente externo no necesita ese nivel de detalle: sería más seguro responder con un 404 o un 401 genérico, sin pistas internas. Además, la auditoría mostró que algunos campos protobuf de los escenarios con subagentes aceptan referencias a modelos premium sin una comprobación de plan específica.

En la práctica, esto no cambia el modelo que realmente responde ni abre un bypass, porque el routing ignora esos campos de todos modos, pero esa lógica amplía la attack surface y podría convertirse en un problema tras futuros cambios en el producto. Una parte importante del análisis es la lista de vectores que no funcionaron. El autor probó fuerza bruta sobre nombres de modelos, suplantación de claims del JWT, inyecciones en el callback de OAuth, replay de webhooks de Stripe, confusión entre requested_model y model_details, conflictos de wire types en protobuf y condiciones de carrera en torno a la suscripción.

En ningún caso logró una elusión significativa. El servidor rechaza las etiquetas protobuf incorrectas, no confía en los datos del JWT, valida las firmas de Stripe y mantiene centralizada la comprobación del plan. Eso refuerza la conclusión: los problemas existen, pero el modelo de seguridad básico de Cursor parece maduro y bien pensado en comparación con muchos servicios de IA que confían demasiado en el cliente.

La lección práctica va más allá de Cursor. Para quienes desarrollan SaaS de IA, sirve como una buena lista de verificación: no guardar privilegios en el token, comprobar el plan en el servidor en cada petición, validar protobuf de forma estricta y no dejar campos dev en los esquemas de producción. Para los usuarios, es una señal de que incluso los IDE con IA más avanzados mantienen una superficie vulnerable en torno a la facturación, los servicios internos y los mecanismos internos de enrutamiento de modelos.

Y, sobre todo: hoy la seguridad de un producto de IA no depende de cuántos modelos admite, sino de la disciplina con la que separa el cliente de los permisos de acceso reales en el servidor.