Key Highlights

• Cyera Research Labs identified two security vulnerabilities  - command injection and prompt injection - in Google’s Gemini CLI tool.
  
• Both vulnerabilities  allowed attackers to execute arbitrary commands with the same privileges as the CLI process.
  
• Google acknowledged the findings and issued fixes through its Vulnerability Rewards Program (VRP).
  
• The discovery was made using Cyera’s AI-augmented vulnerability research methodology, demonstrating how large language models (LLMs) can accelerate real-world security discovery.
  

What We Found - and Why It Matters

Cyera Research Labs uncovered two exploitable vulnerabilities  in Google’s Gemini CLI, a command-line interface that allows developers to interact directly with the Gemini family of large language models.

These issues, tracked as Issue 433939935 and Issue 433939640, enabled attackers to execute arbitrary commands - either by exploiting VS Code extension installation logic or through prompt injection techniques.

If exploited, these vulnerabilities  could give attackers access to sensitive development environments, credentials, and AI model data. Google’s rapid response and remediation through its VRP reflect the severity of these issues and the growing importance of securing AI development tools.

About GEMINI CLI

Gemini CLI is a command-line interface tool developed by Google that allows developers to interact with the Gemini family of large language models directly from the terminal. It provides functionality for tasks such as generating text, analyzing code, and integrating Gemini’s capabilities into local workflows or applications. The tool is designed to streamline experimentation and development with Gemini models without requiring a web-based interface.

Why AI-Powered Tools Need Extra Protection

AI development environments are uniquely exposed because they often bridge user input, model inference, and system-level actions. Vulnerabilities in such tools can have cascading impacts - potentially leading to unauthorized access to intellectual property, misconfigured deployments, or compromised training data.

Cyera’s findings emphasize that prompt injection isn’t just a model-level concern - it can directly lead to system compromise when natural language interfaces interact with code execution mechanisms.

The AI-Augmented Approach Behind the Discovery

Cyera’s research team used an LLM-augmented methodology to accelerate vulnerability discovery:

• Automated Static Analysis: A Semgrep scan identified 6,115 potential issues across Gemini CLI’s TypeScript codebase.
  
• LLM-Powered Triage: A specialized auditing prompt analyzed each finding for exploitability, narrowing results to 12 leads in hours instead of weeks.
  
• Manual Validation: Using Cursor IDE and Claude 4 Sonnet, researchers validated and confirmed two exploitable vulnerabilities  within 48 hours.
  
• Efficiency Gains: This process achieved a 99.8% reduction in false positives and cut analysis time from an estimated 300–500 hours to just 16.

Background

Cyera’s security research focuses on AI infrastructure vulnerabilities due to their strategic position in modern technology stacks. AI command-line interfaces represent critical trust boundaries where natural language processing meets system execution. Vulnerabilities in these components directly impact data security postures across cloud, AI, and on-premises environments.

When AI tools like Gemini CLI are compromised, the technical impact extends beyond the immediate process. These tools typically access development environments, configuration files, credentials, and model artifacts. A successful exploitation provides attackers with privileged access to intellectual property, deployment configurations, and potentially customer data processed through AI workflows.

Research Methodology

The research employed a systematic approach combining static analysis with LLM-powered vulnerability validation:

Phase 1: Automated Static Analysis

SEMGREP scanning identified 6,115 potential security issues across the Gemini CLI TypeScript codebase. The scan configuration included:

• Generic security rules for common vulnerability patterns
• TypeScript-specific security checks
• Logic vulnerability detection rules targeting control flow issues

Phase 2: LLM-Powered Triage

A specialized security auditing prompt processed SEMGREP findings to determine exploitability. The prompt analyzed each finding against specific criteria:

• Reachability from input vectors (CLI arguments, API inputs, configuration files, plugins)
• Presence and effectiveness of input sanitization
• Actual exploitability in production configurations

The triage process reduced 6,115 findings to 12 relevant leads through systematic code flow analysis.

The prompt that was used:

You are a professional AI security auditing agent. You are analyzing a large codebase located in the folder "gemini-cli". You have full access to all the source files in this folder.

You are given a Semgrep scan output file: "gemini_semgrep_output.json", which contains few thousands findings. Your job is to triage each finding and determine whether it leads to a real, exploitable vulnerability.

Furthere more after going over the semgrep output You MUST analyze the actual code flow in the "gemini-cli" source tree when making decisions.

---

PER-FINDING ANALYSIS - FOLLOW THESE STEPS:

1. Check Reachability

   Determine whether the finding is reachable from any of these input vectors:

   - CLI arguments (argv, argc, other Environment arguments)

   - REST API inputs (if applicable)

   - Parsed model files: GGUF, slot files, tokenizer, or vocabulary files

   - Configuration files (e.g., JSON, YAML, TOML)

   - Remote interfaces (ports, files, rpcs, different protocols)

   - Authentication processes 

   - plugins/dlls/bin loading mechanisms 

   If the issue is not reachable via any of the above, mark it as "unreachable": true.

2. Check Sanitization or Validation

   If the issue is reachable, analyze the full control and data flow to check if the input is sanitized or validated before reaching the vulnerable sink.

   - Look for input validation logic, bounds checks, schema validation, magic byte checks, input length constraints, etc.

   - Determine whether validation is missing, weak, or bypassable.

3. Recheck the Flow for Confidence

   If you suspect a vulnerability:

   - Re-walk the full flow from input to sink

   - Confirm there are no missed validation branches

   - Ensure your reasoning is sound and rooted in the actual source code

---

USE TERMINAL FOR SMART FILE ANALYSIS (macOS/Linux)

To efficiently read and analyze large files without consuming too much memory, use native shell tools that process data in a streaming fashion rather than loading everything into memory:

- Use `grep -R "pattern" .` or `grep -E "regex" file.txt` to locate relevant function calls or data patterns (equivalent to PowerShell’s `Select-String`).

- Use `tail -n 50 file.txt` or `head -n 100 file.txt` to read partial sections of a file.

- Combine filters with `awk`, `sed`, and `grep` to extract or transform data - for example:

  grep "function" script.sh | awk '{print $2}'

- Use `awk` or `sed` for inline parsing of function bodies or configuration structures:

  awk '/start_pattern/,/end_pattern/' file.txt

- Use `wc -c file.txt` or `du -h file.txt` to check file sizes.

- Avoid using `cat file.txt` on very large files unless you’re streaming or piping the output.

Apply these techniques during code traversal and file parsing to scale more effectively when handling large source or log files.

---

IF THE FINDING IS A VALID VULNERABILITY:

Append a JSON object to a file named security_report_{current_date}.json with this format:

{

  "exact_location": {

    "file": "<filename>",

    "function": "<function name if applicable>",

    "line": <line number>

  },

  "vulnerability_explanation": "<Short explanation of the vulnerability and relevant CWE (e.g., CWE-125: Out-of-Bounds Read)>",

  "validation_sanitization": "<Why input validation is insufficient or missing>",

  "input_exploit_example": {

    "vector": "<'argv' | 'rest api' | 'config file' | 'model file' | 'slot file'>",

    "example_input": "<Concrete example of input that would trigger the vulnerability>"

  }

}

---

IF THE FINDING IS NOT A REAL VULNERABILITY:

Append a JSON object to a file named unrelevant_leads_{current_date}.json in the format below:

{

  "issue_description": {

    "title": "<Semgrep rule title>",

    "explanation": "<Semgrep rule explanation or message>"

  },

  "unreachable": <true|false>,

  "sanitized_checked": <true|false>,

  "not_a_vulnerability": <true|false>

}

---

ANALYSIS GUIDANCE:

- You have full access to the entire "gemini-cli/" folder - use this to read function implementations, type definitions, helper utilities, and custom parsers.

- Think like a human vulnerability researcher: trace inputs, analyze call chains, look for conditions, and determine bypassability.

- Use PowerShell commands and shell-based filtering to navigate the code efficiently.

- Do not rely solely on Semgrep messages. Base decisions on actual code flow.

---

TIMING:

This task includes 6115 findings and may take a full day or two. Accuracy and depth of analysis matter more than speed. Do not rush.

Begin reviewing the findings in: gemini_semgrep_output.json

‍

Phase 3: Manual Validation

Cursor IDE Security Validation Summary

Using Cursor IDE with Claude-4-Sonnet assistance, we validated the 12 identified leads through the following steps:

• Control flow verification (from input to sink)
• Bypass technique analysis
• Basic proof-of-concept (PoC) development
• Review of operating system mechanisms and mitigations

After completing the initial validation of the 12 leads, we manually reviewed each one. Several leads were deemed not relevant due to the following reasons:

1. The proof-of-concept did not account for certain constraints.
2. The vulnerability had a very low likelihood of being exploited.
3. The attack vector required an unrealistically high level of initial access (e.g., the ability to execute code through GitHub Actions scripts).

Following this review, three potential issues remained. One of these- a command injection vector on macOS- was ruled out as non-relevant because the API used to spawn processes mitigated the risk.

This left two valid vectors for further analysis.

Phase 4: Exploitation Confirmation

Two proof-of-concept exploits were developed and tested. Cyera researches confirmed command injection and prompt injection are exploitable in production environments.

Total research time: 2 days from initial scanning to confirmed vulnerabilities .

Issues Details

Issue 1: VS Code Extension Installation Command Injection (Issue 433939935)

Location: /packages/cli/src/ui/commands/ideCommand.ts:136

The vulnerability exists in the VS Code extension installation handler:

const command = `${VSCODE_COMMAND} --install-extension ${vsixPath} --force`;execSync(command);

The vsixPath variable, obtained from glob.sync() results, is directly interpolated into a shell command without sanitization.

Attack Vector: An attacker with file system access can create a malicious .vsix file with shell metacharacters in the filename. When the user executes /ide install, the malicious filename triggers command injection.

Example: A file named extension.vsix"; malicious_command; echo " would execute malicious_command when processed.

Platform Impact: Linux and macOS systems are vulnerable. Windows systems are coincidentally protected due to a glob library bug preventing file discovery with absolute paths.

Issue 2: Shell Command Validation Bypass via Prompt Injection (Issue 433939640)

Location: /packages/core/src/tools/shell.ts:112

The shell command validation function implements incomplete command substitution filtering:

if (command.includes('$(')) {

  return { allowed: false, reason: 'Command substitution using $() is not allowed' };}

The validation blocks $() syntax but fails to block backtick (```) command substitution, providing an equivalent bypass mechanism.

Attack Vector:

An attacker capable of influencing prompts processed by Gemini CLI can inject commands using backtick substitution. The AI model, following user instructions or malicious prompts in analyzed files, may execute commands containing backticks.

Example: The command echo "data\\malicious_command"bypasses validation, while echo "data$(malicious_command)" is correctly blocked.

Recent research has highlighted various methods of prompt injection across different AI models:

• Perplexity Comet AI Browser: Researchers from Brave identified a critical flaw where attackers can inject malicious prompts into screenshots or hidden web content. When users interact with such content, the AI inadvertently processes these hidden commands, potentially leading to unauthorized actions like data exfiltration. Cyber Security News
• LLMail-Inject Challenge: A study titled LLMail-Inject presents a dataset derived from a challenge simulating realistic scenarios where attackers inject malicious instructions into emails. The challenge involved participants attempting to exploit Large Language Models (LLMs) to trigger unauthorized actions through email interactions. arXiv

These studies demonstrate the diverse methods through which prompt injection attacks can be executed, emphasizing the need for robust security measures in AI systems to mitigate such risks.

PoC Clips

<aside> ♻️

ADD POC CLIPS HERE

</aside>

Technical Impact

The identified vulnerabilities  allow command execution with the same privileges as the Gemini CLI process. Exploitation could lead to:

• Access to development environment variables and credentials
• Modification of source code and configuration files
• Installation of persistent backdoors
• Exfiltration of model artifacts and training data

Such risks have real-world precedents. For example, publicly accessible AI development data or misconfigured cloud storage has previously led to exposure of sensitive information:

• Scale AI exposed client data through public Google Docs (Business Insider, 2025: https://www.businessinsider.com/scale-ai-public-google-docs-security-2025-6?utm_source=chatgpt.com)
• Zero-click prompt injection attacks on LLM systems allowed remote data exfiltration (ArXiv, 2025: https://arxiv.org/abs/2509.10540?utm_source=chatgpt.com)
• Los modelos de IA malintencionados pueden comprometer las cadenas de suministro de software (ACM CACM): https://cacm.acm.org/research/malicious-ai-models-undermine-software-supply-chain-security/?utm_source=chatgpt.com)

Estas vulnerabilidades de inyección de comandos son particularmente preocupentes en entornos de desarrollo de IA porque:

• Con frecuencia se puede acceder a los datos de entrenamiento del modelo y a los algoritmos patentados
• Las claves de API y las credenciales de la nube a menudo se almacenan en entornos de desarrollo.
• Las canalizaciones de CI/CD pueden verse comprometidas a través de código inyectado o modificado

Mayor Eficiencia en el Descubrimiento de Vulnerabilidades con Enfoque de LLM Aumentado

Al aprovechar una metodología aumentada de Modelo de Lenguaje Grande (LLM), Cyera observó mejoras sustanciales en la eficiencia del descubrimiento de vulnerabilidades:

• Hallazgos iniciales: Se identificaron 6,115 problemas potenciales utilizando SEMGREP.
• Reducción de triaje: Logró una reducción del 99.8% en falsos positivos a través del análisis LLM.
• Tiempo de descubrimiento: Se redujo el tiempo desde el análisis inicial hasta las vulnerabilidades confirmadas a 48 horas.
• Requisitos de revisión manual: Limitado a 12 leads que requieren validación humana, lo que representa 0.2% de los hallazgos iniciales.

La revisión manual tradicional de 6,115 hallazgos requeriría aproximadamente de 300 a 500 horas, suponiendo de 3 a 5 minutos por hallazgo. El enfoque impulsado por LLM condensó esto a 16 horas de trabajo de validación enfocado.

Herramientas de IA en la investigación de seguridad

La integración de las herramientas de IA en la investigación de seguridad ha dado el comienzo de una nueva era de automatización y eficiencia. Por ejemplo, la introducción de agentes de IA por parte de Microsoft en su plataforma Security Copilot tiene como objetivo automatizar las tareas repetitivas de ciberseguridad, aliviando así el agotamiento de los analistas y mejorando la eficiencia operativa (https://www.axios.com/2025/03/24/microsoft-ai-agents-cybersecurity?utm_source=chatgpt.com).

De manera similar, la herramienta HexStrike impulsada por IA se ha utilizado para atacar rápidamente las vulnerabilidades en los sistemas Citrix, lo que demuestra el potencial de la IA para acelerar la explotación de las vulnerabilidades de seguridad (https://www.techradar.com/pro/security/new-ai-powered-hexstrike-tool-is-being-used-to-target-multiple-citrix-security-vulnerabilities? utm_source=chatgpt.com).

Además, investigaciones como “PentestGPT: An LLM Automatic Penetration Testing Tool” exploran la aplicación de los LLM en las pruebas de penetración, destacando su capacidad para automatizar evaluaciones de seguridad complejas (https://arxiv.org/abs/2308.06782?utm_source=chatgpt.com).

Lectura adicional sobre la investigación de seguridad asistida por IA

Para aquellos interesados en profundizar en el papel de la IA en la investigación de seguridad, los siguientes recursos proporcionan información valiosa:

• Auditorías de seguridad asistidas por IA: una guía práctica con aplicaciones del mundo real (https://medium.com/oak-security/ai-assisted-security-audits-0bd76608e3be) — Una exploración de entornos de IA que combina el análisis estático tradicional con la generación de reglas impulsada por LLM.
• PentestGPT: Una herramienta de prueba de penetración automática habilitada por LLM (https://arxiv.org/abs/2308.06782) — Un estudio sobre la aplicación de los LLM en la automatización de los procesos de pruebas de penetración.
• Hackeo, el camino perezoso: LLM Aumentado Pentesting (https://arxiv.org/abs/2409.09493) — Investigación sobre la integración de LLM en los flujos de trabajo de pruebas de penetración para mejorar la eficiencia.

Mitigación

Las organizaciones que utilizan Gemini CLI deben actualizarse a la versión más reciente de inmediato.
Google ha lanzado parches que abordan ambas vulnerabilidades.

Para la defensa en profundidad:

• Restringir el acceso del file system a los directorios de instalación de Gemini CLI
• Implementar políticas de ejecución que limitan las capacidades de comandos del shell
• Supervisar patrones de ejecución de comandos sospechosos

Agradecimientos

Cyera agradece al equipo del Programa de Recompensas por Vulnerabilidad de Google por su rápida respuesta y manejo profesional de estos problemas de seguridad. El equipo de VRP validó, trificó y coordinó la remediación dentro de los plazos de divulgación estándar.

Conclusión

Esta investigación demuestra la eficacia de las pruebas de seguridad aumentadas con LLM para identificar vulnerabilidades complejas en la infraestructura moderna de IA. La combinación de escaneo automatizado, triaje inteligente y validación dirigida redujo un esfuerzo manual de dos semanas a dos días mientras mantenía una alta precisión.

A medida que las herramientas de IA se integran cada vez más en los flujos de trabajo de desarrollo, asegurar estas interfaces se vuelve fundamental para proteger la propiedad intelectual, los datos de los clientes y la integridad de la infraestructura. Las vulnerabilidades descubiertas subrayan la importancia de la validación integral de entradas y los riesgos inherentes a la construcción de comandos de shell a partir de entradas controladas por el usuario.

Las organizaciones que desarrollan o implementan herramientas de línea de comandos de IA deben implementar una validación estricta de entrada, evitar la interpolación de comandos del shell y auditar regularmente sus posturas de seguridad utilizando técnicas automatizadas y manuales.

‍