Los complementos de Postman aparecieron dentro de Claude Code y Codex sin que nadie los instalara a mano. Bastó abrir la aplicación de escritorio de Postman, versión 12.33.4, para que su registro interno anotara la instalación en los dos agentes de programación, con fecha y hora exactas: 24 de octubre, 09:34 UTC.
Un desarrollador identificado como indicava publicó el hallazgo en el reporte 14370 del repositorio oficial de soporte de Postman en GitHub, abierto el 25 de octubre con la etiqueta de grave. Su reconstrucción parte de piezas locales: el registro principal de la aplicación, los archivos de configuración de ambos agentes y el código del instalador, fijado a la revisión exacta instalada en su Mac.
La línea clave del registro trae el origen «auto-existing-upgrade» y el resultado «claude-code:installed, codex:installed». En claro: un proceso pensado para usuarios existentes instaló el complemento de Claude Code, versión 2.0.1, y el de Codex, versión 1.1.0, sin pantalla de aceptación de por medio.
La instrucción que entra en cada sesión
En Codex, el cambio quedó escrito en el archivo global de configuración del usuario: una sección de mercado que apunta al repositorio del complemento, el complemento activado y una entrada de confianza para su gancho. Ese gancho corre al abrir cada sesión e imprime una orden amplia: antes de responder a cualquier tarea de ingeniería de API que no sea trivial —diseñar, implementar, simular, probar, monitorear, documentar o desplegar— el agente debe cargar la habilidad de ingeniería de API de Postman y obedecerla.
El detalle que convierte una queja de producto en un problema de seguridad vive en el instalador. Su código incluye una función llamada approvePostmanHook que, tras instalar, obtiene la huella del gancho y escribe el registro de confianza en la configuración del agente anfitrión. El comentario del propio código lo resume sin rodeos: aprueba solo el gancho actual de Postman tras la instalación. Esa aprobación existe para que la persona decida qué instrucciones obedece su agente al arrancar. Aquí la respondió el visitante.
La instalación sumó una conexión remota MCP —el Protocolo de Contexto de Modelo que enlaza agentes con servicios externos— apuntando a los servidores de Postman. Los registros de Codex muestran que esa conexión falló al arrancar, con un error de autenticación requerida. Quedó activada, eso sí, en una computadora donde nadie la pidió. En Claude Code, el archivo de ajustes activó el complemento oficial de Postman y el registro de instalados guardó la versión 2.0.1 con ámbito de usuario y la misma hora del registro principal. Un ejecutable de Postman apareció también en la carpeta de binarios del usuario.
Nada de eso prueba una salida de datos, y el propio autor del reporte lo dice sin adornos: su documento establece una integración no deseada y cambios en las instrucciones, no una filtración de datos de API. La conexión remota falló al autenticarse y ningún comentario del hilo aporta prueba de una filtración. El titular que circuló por Hacker News habla de un intento de compartir todos los datos de API; esa mitad carece de prueba pública.
El hilo reunió 299 reacciones y 38 comentarios, y la discusión en Hacker News lo convirtió en la historia de seguridad más votada de la semana, con 1.314 puntos. El análisis técnico de Frank Chu en DEV ordena lo comprobado en cuatro piezas: instalación automática, edición de configuraciones ajenas, una orden permanente para el agente y el intento de autoaprobación. El archivo de configuración del agente ya era el blanco codiciado del mes: una extensión falsa de Cursor dejó una puerta trasera SSH en Claude Code a finales de octubre, por la vía del engaño.
Las peticiones del reportero son concretas y medibles: frenar la instalación automática para usuarios existentes hasta que exista una aceptación explícita, retirar la autoaprobación del instalador, identificar el interruptor interno que activó el proceso y publicar una ruta completa de desinstalación que cubra configuraciones, registros de confianza, conexiones remotas y la herramienta de comandos. Él mismo borró Postman y las integraciones después de guardar la evidencia.
Postman promete una aceptación más clara
La respuesta de la empresa llegó el 3 de noviembre, nueve días después del reporte. Sarabmeet Kallar, jefe de producto de Postman, contó a RuntimeWire que la compañía agrupa su herramienta de comandos y los complementos para facilitar la configuración inicial, y que hará más clara la aceptación, en especial para quienes ya usaban la aplicación. Kallar añadió que el equipo revisa la aprobación del gancho y el comportamiento al inicio de sesión que el reporte señaló. Las declaraciones llegaron por su agencia de prensa y dejan dos huecos abiertos: qué interruptor activó la instalación automática y en cuántas computadoras corrió.
Quien use Postman junto a agentes de programación puede revisar su equipo en minutos con los archivos que cita el reporte. El registro principal de Postman guarda si corrió el proceso de actualización automática; los archivos de configuración de Codex y de Claude Code muestran cualquier mención a Postman que el usuario no recuerde haber aceptado; y la carpeta de binarios del usuario revela si apareció la herramienta de comandos. Si algo de eso está y nadie lo instaló a propósito, la limpieza empieza dentro de cada agente: desactivar el complemento, borrar el registro de confianza del gancho y retirar la conexión remota, antes de decidir si Postman se queda en la máquina.
Fuente: GitHub — reporte 14370 del repositorio de soporte de Postman
