IBM told Langflow operators on August 28 to upgrade to 1.11.3 and offered no workaround; the CVE identifiers that would have put that upgrade into a scanner queue arrived this morning, and a tenth still has no record at all.
What happened
At 11:17 a.m. Central today, September 4, 2026, NVD received nine vulnerability records from IBM’s product security incident response team, published under the product name IBM Langflow OSS. They arrived between 4:17:21 and 4:17:24 p.m. UTC, three seconds apart end to end, and every one of them gives the same affected range: 1.0.0 through 1.11.2.
Correction, September 4, 2026, 5:05 p.m. Central: This story described nine records as the day’s batch. It was one of three. Three further Langflow records — CVE-2026-8447, CVE-2026-9138, and CVE-2026-9186 — were published to NVD at 3:17 p.m. UTC, an hour before the nine described here, and five more — CVE-2026-14470, CVE-2026-17621, CVE-2026-17622, CVE-2026-17627, and CVE-2026-17631, carrying an affected range of 1.0.0 through 1.10.2 — were published at 5:16 p.m. UTC. Seventeen Langflow records were published today, not nine. The count and the characterization of the batch were wrong; the facts stated about the nine were not. The full picture, including a second bulletin family naming 1.10.3 as the fix and a second orphan identifier, is in the follow-up story.
- CVE-2026-19298, 8.8, CWE-94 — a remote authenticated attacker can execute arbitrary code “due to an authorization bypass in the flow build process.”
- CVE-2026-19305, 8.6, CWE-918 — server-side request forgery. The vector is
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N: no credentials required, scope changed. - CVE-2026-19303, 8.1, CWE-22 — an authenticated attacker can “delete arbitrary local files or directories.”
- CVE-2026-19304, 7.7, CWE-918 — SSRF reaching internal services “due to a URL parser discrepancy.”
- CVE-2026-19306, 7.7, CWE-22 — arbitrary file read, described below.
- CVE-2026-19300, 7.5, CWE-200 — sensitive information disclosure “due to incomplete scrubbing of sensitive credential fields.” Also
PR:N. - CVE-2026-19299 and CVE-2026-19302, both 6.5, CWE-22 — path traversal, and improper validation of symbolic links.
- CVE-2026-19301, 5.0, CWE-918 — a third SSRF.
Eight of the nine descriptions run to a single clause. One does not. CVE-2026-19306 reads in full: an authenticated attacker can “read arbitrary files from the server filesystem — including server secret material (secret_key, JWT signing keys, the application database, /proc/self/environ, and other tenants’ upload directories) — by supplying absolute paths or traversal sequences in the files parameter of an authenticated build request.” That is the most specific statement of impact in the batch, and it is worth reading before deciding these are file-disclosure bugs of the routine kind.
The nine records point at five IBM security bulletins, grouped by bug class rather than by fix: node 7285639 for the SSRF findings, 7285641 for the path-traversal and file-read findings, and 7285640, 7285642, and 7285643 for the remaining three. Each bulletin carries the same remediation sentence — “IBM strongly recommends addressing the vulnerability now by upgrading Langflow OSS to version 1.11.3” — and the same entry under Workarounds and Mitigations: “None.”
Each bulletin also carries the same change history: “28 Aug 2026: Initial Publication.” The bulletins are seven days old. The CVE records are seven hours old.
None of the nine records names a fixed version. The affected range stops at 1.11.2 and nothing in the record says what to move to. The bulletin says 1.11.3; the identifier that a scanner matches on does not.
One more gap. Bulletin 7285639 lists four CVEs, not three: alongside CVE-2026-19301, CVE-2026-19304, and CVE-2026-19305, it names CVE-2026-12766 at CVSS 5.4. That identifier returns totalResults: 0 from NVD and a 404 from the CVE Program API at cveawg.mitre.org. It is assigned, it is printed with a score on a public vendor bulletin, and no record exists for it in either authoritative database.
Why it matters
For seven days, the only way to know that Langflow OSS 1.11.2 was the top of an affected range was to read ibm.com. There was no workaround to apply in the meantime — IBM said so in every bulletin — so the entire remediation was an upgrade, and the upgrade was invisible to every tool that keys on CVE identifiers: scanners, SBOM tooling, ticket queues, vendor feeds, risk dashboards.
This publication is a worked example of what that costs. On September 1 we reported that CVE-2026-0768 was being exploited against VulnCheck’s Langflow canaries, and we noted that IBM’s bulletin machinery for this product existed, because we had covered an earlier set of Langflow bulletins on August 28 with the affected range given as 1.0.0 through 1.11.1 and the fix as 1.11.2. What we did not know — and could not have learned from any CVE-keyed source, because we checked them — was that a second and larger set of bulletins had published the same day, moving 1.11.2 from the fix to the top of the affected range.
The arithmetic is the point. A Langflow operator who acted on the earlier records and upgraded to 1.11.2 did the right thing with the information the record system held, and landed exactly one version short of where the vendor’s own guidance had already put the line. That is not a hypothetical harm from a publication lag. It is a specific version number in a specific inventory, wrong for a week, for a reason nobody in the chain did anything careless to cause.
The grouping deserves a note of its own. Five bulletin pages carrying nine findings, organized by weakness class, is a defensible way for a vendor to write — it puts the SSRFs together where an engineer can see them as one problem. It reads badly from the other end. One page holds findings scored from 5.0 to 8.6, and its title names a single class, so a reader triaging by bulletin title rather than by record sees one SSRF story rather than an unauthenticated 8.6 sitting next to two lower-severity siblings. Severity Daily has written about the same shape in Cisco’s grouped hardening advisories this week.
Then there is what is not in this batch. CVE-2026-0768 — the unauthenticated root code execution flaw whose exploitation VulnCheck logged 360 times in two days at the end of August — is still the Zero Day Initiative’s record, still scoped to version 1.4.2 alone, and has not been modified since June 17, 2026. It carries no cisaExploitAdd, cisaActionDue, or cisaVulnerabilityName. IBM’s product security team published seventeen Langflow records today (see the correction above; this story originally said nine), under an IBM product name, with an IBM fix version, and the one that attackers are actually using is not among them. The machinery works. It has still not been pointed at that flaw.
On severity: none of these nine is claimed to be exploited, and most require credentials. That last qualifier travels badly in this product category. Langflow is a workflow builder that teams share internally, and an account on it is not a scarce or closely held thing — which is why an authenticated arbitrary-file-read that returns secret_key and JWT signing keys is worth more attention than its 7.7 suggests. The two that need nothing at all, CVE-2026-19305 at 8.6 and CVE-2026-19300 at 7.5, are the ones to sort first if the instance is reachable from an untrusted network.
What to do
Upgrade Langflow OSS to 1.11.3. That is IBM’s instruction, identical across all five bulletins, and there is no alternative on offer: every one of them records its workarounds and mitigations as “None.”
If your inventory shows 1.11.2 because you acted on the earlier IBM Langflow bulletins, you are one version short. Check that specifically — 1.11.2 is the top of the affected range in this batch, not the fix.
Sort by reachability first. CVE-2026-19305 (8.6, SSRF) and CVE-2026-19300 (7.5, credential field scrubbing) both carry PR:N and need no account. If the instance answers from anywhere untrusted, those two are the queue.
Assume secret material is in scope on any affected instance that was exposed. CVE-2026-19306 names secret_key, JWT signing keys, the application database, /proc/self/environ, and other tenants’ upload directories as readable. Rotating credentials after upgrading is the conservative call, and the cheap one.
Do not use the CVE records as your remediation source for this batch, because none of them names a version to move to. Reconcile against the five bulletins instead, and note when you do that CVE-2026-12766 appears on one of them with a score and has no record in NVD or the CVE Program — three of that bulletin’s four identifiers resolve, and the fourth does not.
Sourcing note
Checked: the NVD records for CVE-2026-19298 through CVE-2026-19306, retrieved directly from the NVD API; IBM security bulletins at support pages 7285639, 7285640, and 7285641, read in full for the remediation, mitigation, and change-history language quoted above; the NVD and CVE Program lookups for CVE-2026-12766, which return zero results and a 404 respectively; and the NVD record for CVE-2026-0768 for its CISA fields and last-modified date. Bulletins 7285642 and 7285643 are cited by their records but were not opened individually; the remediation language quoted is from the three that were, and all three match. The affected-range and fix-version facts come from IBM, the vendor and the assigning CNA, with no second source — there is no independent confirmation that 1.11.3 remediates all nine. The project’s public release list appears to show a later 1.11.4, but the tag page did not resolve when we checked, so we have not relied on it and readers should follow IBM’s stated version. No exploitation is claimed for any of the nine, and none was found. cisa.gov refuses automated fetching, so KEV status here is inferred from the absence of CISA fields in the NVD records rather than read from the catalog. Prior Severity Daily coverage of CVE-2026-0768 and of grouped vendor advisories is linked inline.