Column 1
Column 2
Skip to content

Gemini CLI CVE-2026-13745: CI Security Update Checklist

September 10, 2026

Teams using Gemini CLI in unattended development or deployment workflows should review CVE-2026-13745 and the vendor’s workspace-trust update. Check the CLI and its GitHub Action separately: a version number for one component is not the update target for the other.

Scope: Fix I.T. Phill has not assessed your CI environment. This guide concerns Gemini CLI and the run-gemini-cli GitHub Action in automated workflows, not a general vulnerability claim about Google’s consumer services. We have not independently confirmed active exploitation.

What the source says

The GoogleCloud CVE record points to a vendor advisory published on April 24, 2026. The September 10 CVE and NVD arrivals are not the original advisory or release date. The advisory describes remote-code-execution risk when vulnerable automated workflows process untrusted inputs, and changes to workspace trust and tool authorization. Its page still displays no assigned CVE, so this guide makes the link through the current GoogleCloud CNA reference rather than treating that page label as updated.

The vendor lists these first patched versions:

  • Gemini CLI stable: 0.39.1.
  • Gemini CLI preview: 0.40.0-preview.3.
  • run-gemini-cli GitHub Action: 0.1.22.

These are advisory boundaries, not a claim that they remain the latest supported releases. Review the official trust-model advisory and your release channel before selecting a supported update.

Review compatibility before maintenance

The vendor warns that updated unattended workflows may no longer load settings as before, and previously accepted automation may need review. A pipeline failure after the update is not a reason to make untrusted inputs trusted or broaden tool access.

  1. Inventory both components. Record the CLI version actually used by each affected workflow and any selected GitHub Action release. Check explicit version choices as well as defaults.
  2. Identify the workflow’s trust boundary. Ask the workflow owner which inputs are controlled by approved collaborators and which can come from other sources. Do not assume that everything arriving in a repository is safe to execute.
  3. Select supported patched releases. Keep stable and preview channels distinct. Review release notes and the vendor’s recommended workflow configuration for the specific job.
  4. Preserve restrictive controls. Keep access limited to the tools and credentials necessary for the job. Do not disable review or authorization controls to restore a former convenience.
  5. Plan the change and recovery. Agree on a maintenance owner, a normal test job, and a rollback decision. An older vulnerable version is not a long-term workaround for a compatibility problem.

Verify with normal work, not attack demonstrations

Use a controlled, authorized test workflow with ordinary inputs. Confirm the expected version, intended settings, permitted tasks and normal output. Check that the workflow does not silently skip a required step. Keep test credentials and job output private.

If a workflow cannot be restored without relaxing the intended trust boundary, pause that affected automation and have its owner review the vendor guidance. This checklist does not provide a blanket trust-setting recipe.

Installing a patched version alone does not establish that prior misuse is absent. Unexpected workflow behavior or credential use warrants your normal incident-response process and private evidence handling.

Separate CI updates from website updates

A CI-tool update does not update WordPress or its plugins. For teams deploying WordPress through these workflows, coordinate the pipeline maintenance with separate WordPress support and maintenance. Verify the site change through its normal approval and recovery process rather than combining unrelated updates in one step.

Image note: this is a generic server security-maintenance illustration, not a Gemini CLI screenshot or evidence of a customer incident.

Sources