Ejecuta esta lista de verificación de plugins antes de que un swap tipo Plugin4Shell ejecute código con tus credenciales

Un SHA fijado aún puede apuntar al código equivocado. Plugin4Shell es una vulnerabilidad de ejecución remota de código de cero clics en Claude Code, Codex, Copilot y Gemini. El agente no confirma que el árbol de trabajo contenga el commit que se le indicó fijar./p>

La cadena de suministro de plugins es el riesgo, no solo el archivo del plugin. La lista de verificación siguiente es el conjunto mínimo de controles. Cada elemento es una verificación que puedes ejecutar antes de que un plugin se ejecute. Úsala para cada plugin nuevo y cada actualización de plugin antes de que el agente ejecute el plugin./p>

La fijación de SHA dejó de ser un límite

Una fijación le indica al agente qué commit obtener. No demuestra que el árbol de trabajo contenga ese commit./p>

• Verifica el commit resuelto. Compara el hash del commit del árbol de trabajo con el hash fijado antes de la ejecución y falla en caso de discrepancia./li>
• Confirma versiones parcheadas del agente. Compara la versión del agente instalada con la corrección publicada por el proveedor antes de habilitar el plugin./li>
• Audita la fuente del marketplace. Confirma el host del repositorio del plugin, el propietario y la ruta de actualización, y rechaza marketplaces de terceros no revisados./li>
• Desactiva la autoactualización. Desactiva las actualizaciones automáticas de plugins y exige que un operador con nombre apruebe cada nueva versión./li>
• Trata los plugins como código autoactualizable. Confirma que el control de parada es independiente del plugin antes de la primera ejecución./li>

Las verificaciones cierran rutas diferentes: swap, agente sin parche, canal no confiable, deriva silenciosa y radio de impacto. Ejecútalas siempre en el mismo orden. Una verificación fallida detiene la implementación. Una verificación superada solo cierra la ruta de swap conocida./p>

El commit resuelto es el control real

La verificación debe ocurrir después del checkout, no antes de que el agente inicie. Una discrepancia es una condición de parada. El agente no debe ejecutar código de plugin hasta que la verificación pase./p>

Registra el hash esperado, el hash resuelto y la hora de la verificación. El registro debe ser legible por un operador que no instaló el plugin. Si el registro falta, trata el plugin como no verificado./p>

Ejecuta la verificación en el mismo entorno donde el agente ejecuta el plugin. Un hash verificado en una máquina de compilación puede ser incorrecto en el runner. El árbol de trabajo es lo único que importa en el momento de la ejecución./p>

La elección del host cambia la superficie de ataque. GitHub rechaza nombres de rama que parecen identificadores de commit de 40 caracteres hexadecimales, mientras que Bitbucket y servidores git autoalojados los permiten. La mitigación de GitHub no es suficiente, porque los marketplaces pueden estar en hosts como Bitbucket. Un host más estricto no hace segura toda la cadena de suministro. El marketplace puede estar en un host permisivo y aun así alimentar al agente./p>

No asumas que la URL del marketplace es la URL del repositorio. El marketplace puede apuntar a un remoto diferente. El agente puede obtener desde el remoto mientras el marketplace aún muestra la fijación original. Si el host permite nombres de rama similares a commits, exige un host que bloquee ese patrón o añade una verificación explícita que lo rechace./p>

El estado del parche no es una única respuesta

Tras el informe de junio, Anthropic lanzó Claude Code 2.1.179 como corrección y OpenAI lanzó Codex 0.146.0 como corrección. Google le dijo a Air que no parchearía Gemini CLI, deprecó el producto y dirigió a los usuarios a Antigravity. Copilot es utilizado por casi el 90 por ciento de las empresas Fortune 500 y no se había lanzado ningún parche./p>

Las verificaciones de versión necesitan automatización. Registra la versión del agente, la versión del plugin y la aprobación de la actualización en el mismo registro. Una nota manual no es suficiente. La flota debe saber qué agentes están parcheados, cuáles no lo están y cuáles están deprecados. Los productos deprecados requieren una respuesta diferente. Si un proveedor no va a parchear un producto, retíralo de la ruta de plugins o aíslalo de las credenciales de producción. Las flotas grandes empeoran el caso sin parche. Un solo agente sin parche puede exponer toda la flota. El estado del parche debe estar en el mismo panel que muestra las versiones de plugins, donde un operador pueda ver la brecha antes de una actualización de plugin./p>

El pipeline debe rechazar swaps

Un marketplace es un canal de distribución y la fijación es solo una sugerencia si el canal puede dirigir al agente a un repositorio diferente. Los roles del marketplace importan. Verifica quién puede añadir un plugin, quién puede cambiar su fuente y quién puede aprobar una nueva versión. Si esos roles son demasiado amplios, restríngelos./p>

La autoactualización elimina el punto de decisión humana. Una nueva versión puede llegar mientras el agente está inactivo y ejecutarse antes de la revisión. Las actualizaciones frecuentes son un problema de diseño. El operador debe ver la solicitud de actualización, revisar el cambio y aprobarlo con una identidad con nombre./p>

Las credenciales con alcance limitado restringen el radio de impacto. Los plugins no deben mantener secretos permanentes. Un formateador no necesita tokens de despliegue y un plugin de repositorio de solo lectura no necesita acceso de escritura a sistemas de producción. El operador debe poder detener al agente y revocar las credenciales de sesión desde la consola del operador./p>