Eight more IBM Langflow CVE records published this afternoon after the nine this site covered at midday, in a third wave pointing at a different fix version — and a second bulletin identifier turns out to have no record either.
What happened
This morning Severity Daily reported that nine IBM Langflow OSS CVE records reached NVD at 4:17 p.m. UTC on Friday, September 4, 2026, seven days after the IBM security bulletins that described the fixes. That was accurate about the nine. It was not the whole day. Seventeen Langflow records were published to NVD between 3:17 and 5:17 p.m. UTC, in three distinct waves, and eight of them were not in that story.
An NVD keyword query for Langflow bounded to today returns totalResults of 17:
- 3:17 p.m. UTC — three records. CVE-2026-8447 (6.1, stored cross-site scripting in the Playground chat interface), CVE-2026-9138 (6.5), and CVE-2026-9186 (6.5, IP spoofing through untrusted proxy headers). Affected range 1.0.0 through 1.11.2. These landed an hour before the nine and were missed; a correction has been appended to the earlier story.
- 4:17 p.m. UTC — nine records. CVE-2026-19298 through CVE-2026-19306, the batch already covered. Affected range 1.0.0 through 1.11.2.
- 5:16 p.m. UTC — five records. CVE-2026-14470 (6.5), CVE-2026-17621 (5.4), CVE-2026-17622 (6.5), CVE-2026-17627 (4.9), and CVE-2026-17631 (5.0). Affected range 1.0.0 through 1.10.2 — a different upper bound from the other twelve.
That different bound is not an error in the records. It points at a second line of bulletins. IBM bulletin 7285644, “Langflow OSS is affected by server-side request forgery due to missing URL validation in flow components,” gives affected versions “1.0.0-1.10.2” and this remediation: “IBM strongly recommends addressing the vulnerability now by upgrading Langflow OSS to version 1.10.3.” Its change history reads “28 Aug 2026: Initial Publication” — the same date as the bulletins telling operators to go to 1.11.3.
So on August 28, IBM published Langflow bulletins naming two different fix versions, and on September 4 it flushed the CVE records for both into NVD inside two hours.
The third wave also includes a bulletin that is not from August 28 at all. Bulletin 7286293, “Langflow OSS is affected by arbitrary file read due to path traversal vulnerabilities in file and knowledge base components,” carries the change history “03 Sep 2026: Initial Publication.” It covers CVE-2026-14470, CVE-2026-17621, and CVE-2026-17622, and its records were published to NVD the following day. Affected versions “1.0.0-1.10.2,” fix “version 1.10.3,” workarounds and mitigations “None.”
The lag, in other words, is not seven days. It is seven days for one set and one day for another, both arriving in the same batch. What synchronized them was the flush, not the bulletin.
Finally, the orphan count has gone up. This morning’s story noted that bulletin 7285639 prints CVE-2026-12766 with a CVSS score of 5.4, and that NVD returns totalResults: 0 for it. Bulletin 7285644 prints CVE-2026-12765 at CVSS 6.5, described as an SSRF that “may allow an unauthenticated attacker to send unauthorized requests from the system.” NVD returns totalResults: 0 for that identifier too. Both remain absent as of this writing, a week after the bulletins that print them.
None of the seventeen records published today names a fixed version. The affected range stops, and the record is silent about where to go.
Why it matters
The two-fix-version split is the part that will cost somebody an afternoon, and it is worth being precise about why, because the obvious reading is wrong.
Nothing here asks anyone to downgrade. The 1.10.3 bulletins describe bugs fixed earlier in the 1.10 line; an operator running 1.11.2 already has those fixes, and 1.11.3 is still the version to be on. The problem is that nothing in the record system says so. A CVE record for CVE-2026-17631 states an affected range ending at 1.10.2 and names no fix at all. The bulletin behind it says 1.10.3. A remediation ticket generated from either artifact, against a fleet running 1.11.x, produces a version number lower than what is already installed. Somebody has to work out by hand that the two bulletin families are stacked rather than parallel, and there is no field anywhere in the chain that encodes that relationship.
This compounds the arithmetic problem this publication described this morning. An operator who read IBM’s earlier August 28 bulletins upgraded to 1.11.2 and was, for a week, one version short of the vendor’s own line. An operator who now reads the 1.10.3 bulletins without noticing they belong to a superseded branch may conclude that 1.10.3 is the target and that 1.11.2 is more than sufficient. Both errors come from the same missing piece: the CVE record does not name a fixed version, so every remediation decision has to be reconstructed from vendor prose.
The three-wave structure matters for a different reason. It is evidence about how this queue actually behaves, and it undercuts a tempting generalization. “IBM PSIRT runs about a week behind its bulletins” is a usable heuristic if it is true; today it is true of twelve records and false of three, with a September 3 bulletin’s records arriving faster than an August 28 bulletin’s. The observable pattern is a queue that drains on its own schedule and carries whatever is in it. Anyone building alerting on top of vendor bulletin dates should assume records arrive in unrelated clumps, and should not read a batch boundary as a meaningful grouping. The three waves today separate by publication mechanics, not by severity, product line, or bug class.
Two orphan identifiers is a materially different fact from one. A single CVE ID printed on a bulletin with no record behind it reads as a clerical slip. Two, from the same vendor, in the same week, on the same product, printed with CVSS scores and full descriptions, looks like a step in the process that does not always complete. Both of these are also, notably, the unauthenticated ones in their respective bulletins — CVE-2026-12765 is described as exploitable without credentials, and it is the identifier with no record. That is almost certainly coincidence, and it is stated here as coincidence, but it is the pair a defender would least want missing from a scanner feed.
The practical consequence is unchanged from this morning and worth restating once: for anything keyed on CVE identifiers — scanners, SBOM tooling, vendor feeds, risk dashboards — a Langflow inventory was incomplete until this afternoon and is still incomplete by two identifiers. The vendor bulletin remains the authoritative document, and reading ibm.com by hand remains the only way to see the whole picture.
What to do
- Upgrade Langflow OSS to 1.11.3. That remains the target for anything on the 1.11 line, and it supersedes the 1.10.3 guidance in the second bulletin family. Do not act on a ticket that names 1.10.3 as a target for a 1.11.x install.
- Re-scan after your feed refreshes. None of these seventeen identifiers existed in NVD this morning, and five of them were published within the last five hours. A scan run earlier today is stale.
- Track CVE-2026-12765 and CVE-2026-12766 by hand. Both are printed on IBM bulletins with scores; neither exists in NVD. They will not appear in any CVE-keyed tooling until the records are created, and the 6.5 SSRF is the unauthenticated one.
- Read the bulletin, not the record, for the fix version. None of the seventeen records names one.
- IBM lists no workarounds or mitigations on any of these bulletins. The entire remediation is the upgrade.
- There is no claimed exploitation of any of the seventeen. The separately tracked CVE-2026-0768, the unauthenticated code execution flaw with observed exploitation against VulnCheck canaries, is still not among IBM’s records and remains scoped to version 1.4.2 alone.
Sourcing note
The seventeen records and their publication timestamps come from an NVD keyword query for Langflow bounded to September 4, 2026, which returned totalResults of 17. CVE-2026-17631 and CVE-2026-8447 were retrieved individually to confirm their timestamps, affected ranges, and source identifier of [email protected]. The absence of CVE-2026-12765 and CVE-2026-12766 was checked by direct cveId query; both returned totalResults: 0. An absence reported by a single retrieval is not proof of absence, and these will be re-checked; CVE-2026-12766 has now returned zero on two separate days.
Bulletin titles, change-history dates, affected version tables, remediation sentences, and the “None” mitigation entries are quoted from IBM support pages 7285644, 7285646, and 7286293 as read today. Node 7286293 is dated “03 Sep 2026: Initial Publication”; nodes 7285644 and 7285646 are dated “28 Aug 2026.” IBM has not published anything explaining the relationship between the 1.10.3 and 1.11.3 bulletin families, and the reading offered here — that the 1.10 fixes are contained in the 1.11 line — is inference from the version numbering, not a vendor statement. It should be confirmed against IBM before it is relied on for a large upgrade. Whether the two missing identifiers are withheld, delayed, or abandoned is not stated anywhere and is unresolved.
Sources: NVD, Langflow records; IBM bulletin 7286293; IBM bulletin 7285644; IBM bulletin 7285646.