The entry landed at 15:12 UTC
CISA published version 2026.07.21 of its Known Exploited Vulnerabilities catalogue at 15:12:01 UTC on 21 July 2026, and CVE-2026-0770 was in it. The agency describes the flaw in its own words: "Langflow contains an inclusion of functionality from untrusted control sphere vulnerability that allows remote attackers to execute arbitrary code on affected installations." The due date for US federal agencies is 24 July 2026, three days after listing, under Binding Operational Directive BOD 26-04, "Prioritizing Security Updates Based on Risk".
The technical shape explains the deadline. Vulnerability databases put the score at CVSS 9.8, the defect sits in validate_code(), which passes exec_globals into an unsandboxed exec() call, the affected process runs as root, and the endpoint requires no authentication. Versions 1.4.2 through 1.7.3 are affected and the Langflow project shipped the fix in 1.9.0. CISA files the weakness as CWE-829 and records known ransomware campaign use as unknown.
Four weeks of reachable instances
The exposure predates the listing by almost a month. Vulnerability trackers recorded exploitation attempts against this flaw from 27 June 2026, and across a thirty-day window they counted 201 attempts from 61 unique IP addresses. The catalogue entry followed on 21 July.
Read those numbers for what they are. They are scanning and exploitation telemetry, and they are not a confirmed count of breached companies, and CISA still records ransomware campaign use as unknown. What they do establish is that the address space was being swept for weeks while most owners had never heard the product name.
That changes what discovery means. If someone in your company finds a Langflow instance this week, the safe assumption is that it was reachable during those four weeks, so the work includes process logs, outbound connections and every credential the instance held. Upgrading to 1.9.0 closes the door. It tells you nothing about who already walked through it.
An inventory problem wearing a patch problem's clothes
The patch is the easy part. This class of software does not arrive through IT. Low-code AI builders get stood up by marketing, operations and analytics teams, because that is the entire point of low-code, and they get stood up on a cloud instance with a corporate credential attached to it.
No asset register entry, no CMDB row, no agent on the host. The vulnerability scanner that would have caught CVE-2026-0770 never saw the machine, so the patch cycle everyone trusts had nothing to work with. Ask a different question this week: who in this company has permission to spin up a server, and what did they spin up.
The tooling layer around agents is the new attack surface
This is the second AI-agent-building platform to reach the exploited-in-the-wild catalogue this month. The tooling layer that assembles agents is younger and less audited than the applications it orchestrates, and it runs with more privilege than either.
That privilege is the point. An agent builder holds the credentials for every system its agents touch, so root on the builder reaches the CRM, the mailbox, the data warehouse and the payment system that someone in another department wired into a workflow. The blast radius is the integration list, and nobody outside that department has read it.
Two limits are worth stating plainly. The 24 July date is a US federal deadline and carries no legal force in Europe, and the telemetry above describes attack traffic and stops short of confirmed compromise. NIS2 duties across the EU, and UK guidance in the same spirit, already put asset inventory on the same desk, which is where this story ends up anyway.
Read next: This ColdFusion Flaw Was Attacked Within Minutes | A Shared Certificate Is What Lets Qilin In
