// hackerlogs
login+ register
LLM AppSecAgentic AISupply ChainThreat BriefCriticalCVE-2026-12944CVE-2026-17628

IBM's Langflow Scanner Said Validated. The CVE Is 9.6 Anyway.

CVE-2026-12944 is a 9.6 authenticated scanner miss in Langflow OSS 1.0.0 through 1.10.0. IBM's fix is 1.10.1. Take 1.10.3 for the password-reset row.

The short answer

IBM assigned CVE-2026-12944 a 9.6 for Langflow OSS 1.0.0 through 1.10.0. An authenticated user could submit a flow component the scanner marked validated while still running network code as root. IBM's fix for that row is 1.10.1. Take 1.10.3 for CVE-2026-17628, the password-reset miss on 1.0.0 through 1.10.2. No confirmed exploitation yet.

Key takeaways

  • CVE-2026-12944 is authenticated, CVSS 9.6, CWE-918. IBM: Langflow OSS 1.0.0 through 1.10.0. The scanner returned validated while network standard-library imports still ran as UID 0.
  • IBM's own bulletin for 12944 says upgrade to 1.10.1. The companion password-reset row, CVE-2026-17628, needs 1.10.3. Take the later build.
  • SecurityOnline wrote it up on 16 September. That is the Google-searchable ticket. IBM has not called either CVE exploited.
  • This is not CVE-2026-0768, the unauthenticated Langflow RCE VulnCheck and CSA watched being used to steal OpenAI and AWS keys in late August.
  • A green validated badge on an agent-built component is not a sandbox. Treat the scanner as a blocklist, then assume it is incomplete.

US Google Trends on 16 September were still Steinem, football, and ChatGPT. The searchable operator ticket is CVE-2026-12944. SecurityOnline wrote it up this morning. IBM's score is 9.6. The scanner on Langflow OSS told the operator the component was validated.

GitLab's KEV clock ran out yesterday. This is a different product and a different class: an authenticated miss inside an agent builder, not an unauthenticated file read.

Critical Authenticated component submission, scanner false-pass, code as UID 0. Critical because the box holds the keys the flows use, not because IBM has seen it in the wild.

Three panels for Langflow CVE-2026-12944: a scanner that returned validated on network imports, IBM's 9.6 authenticated miss on 1.0.0 through 1.10.0, and the 1.10.3 upgrade that also closes the password-reset row.

What IBM actually patched.#

IBM's bulletin, first dated 2 July and assigned CVE-2026-12944 later, is a blocklist gap in the Langflow component scanner. The scanner already refused subprocess. It did not refuse the network standard library. An authenticated user could submit a component that still ran on the server during validation. The process returned a validated flag anyway.

IBM's description is SSRF and more. The CVSS vector is 9.6 with changed scope: confidentiality and integrity high, availability none, privileges low. The process runs as UID 0. IBM lists cloud-metadata credential theft, file read from the container, and a path to services on the same Docker network. Reporter: KIM MINJUN.

We are not reprinting the component that proves it. The operator fact is enough: if an authenticated user can add a component, a green validated badge is not a sandbox.

Affected builds are Langflow OSS 1.0.0 through 1.10.0. IBM's remediation on that bulletin is 1.10.1. Take it, then keep going.

The same week's second IBM row is CVE-2026-17628, CVSS 5.4, published 8 September. Authenticated callers could change their own password without proving the current one, including to a one-character secret. Affected through 1.10.2. IBM's fix is 1.10.3. SecurityOnline is right to treat 1.10.3 as the build that closes both.

Why the 16th is the news.#

IBM sat on the scanner miss since July. The CVE number and the morning write-ups are what people are searching. There is no KEV row and no IBM statement of in-the-wild use for 12944 or 17628.

That is the difference from CVE-2026-0768, the unauthenticated Langflow RCE CSA and VulnCheck watched being used from 29 August to harvest Langflow tokens, OpenAI keys, and AWS keys. Twelfth exploited Langflow CVE of 2026, CSA said. Do not file 12944 under that campaign. Do file both as reasons the same host should already be off 1.10.x minus the last patch.

  1. ZDI discloses CVE-2026-0768, unauthenticated Langflow RCE. Later exploited in August.
  2. IBM publishes the scanner-blocklist bulletin that becomes CVE-2026-12944. Fix listed as 1.10.1.
  3. IBM publishes CVE-2026-17628 on the password-reset path. Fix listed as 1.10.3.
  4. NVD and aggregators attach CVE-2026-12944 to the July bulletin.
  5. SecurityOnline and operator blogs make 12944 the searchable ticket. No confirmed exploitation on this CVE.

What this is not.#

It is not unauthenticated. Privileges are low, not none. It is not a stated in-the-wild campaign. It is not every visual agent builder. It is not the GitLab commits-API file read and not the Hugging Face eval swarm.

It is also not a reason to keep 1.10.1 and call the month done. 17628 lives on 1.10.2.

What to do.#

If you run self-hosted Langflow, or you own the cloud keys it holds:

  1. Upgrade to 1.10.3. Confirm the about page. IBM's 12944 note stops at 1.10.1. The password-reset note does not.
  2. Pull internet-facing Langflow off the public net until that build is live. Authenticated is not the same as safe when signup, SSO, or a shared service user exists.
  3. Inventory flow components added or edited before the upgrade. Delete anything nobody can explain. The hole was the submit-and-validate path, not a new admin panel.
  4. Rotate Langflow secrets, model-provider keys, and any IAM role the process could reach, including metadata-service credentials. CSA already documented that pattern on the older CVE.
  5. Stop treating the component scanner as the control. If an agent can author a component, the control is identity, egress, and a non-root runtime, the same stack Amodei and Kurtz spent the weekend arguing about from the other end.

The X debate this week is a Spanish DPA filing and a CEO forecast. The Google-searchable ticket is an agent builder whose own scanner lied. Patch the builder. Then assume the keys on that host were in scope.

Frequently asked

Do we have to be on the public internet for this to matter?

You need an authenticated Langflow user who can submit or edit a component. Internet exposure still matters because that user is often a shared service account, an SSO session, or an agent identity. If Langflow holds cloud keys, a root process on the box is a credential harvest even on an internal VLAN.

Is this the Langflow bug that was already being exploited?

No. CVE-2026-0768 is the unauthenticated RCE ZDI disclosed in January and that VulnCheck and the Cloud Security Alliance watched being used in late August to pull Langflow tokens, OpenAI keys, and AWS keys. CVE-2026-12944 is a later, authenticated scanner miss. IBM has not called it exploited. Patch both.

IBM says 1.10.1. Why take 1.10.3?

1.10.1 is the remediation IBM wrote on the 12944 bulletin. CVE-2026-17628, published 8 September, affects 1.0.0 through 1.10.2: the password-reset path did not check the current password. IBM's fix for that row is 1.10.3. One upgrade covers both.

What should we hunt after the upgrade?

New or edited flow components you did not approve. Unexpected egress from the Langflow process to cloud metadata or to hosts you do not operate. Password changes that did not go through your IdP. Rotate any API keys, IAM roles, and database credentials that lived on that host, the same way you would after any root-equivalent miss.

Sources

  1. Harvest AI and Cloud Credentials Cloud Security Alliance · 2026-09-04

Related