Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-12766

  • IBM’s seventeen Langflow CVEs landed in three waves today, naming two different fix versions, and two of its identifiers still have no record

    IBM’s seventeen Langflow CVEs landed in three waves today, naming two different fix versions, and two of its identifiers still have no record

    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.

  • IBM’s nine Langflow CVEs landed seven days after the bulletins that fixed them, and a tenth still has no record

    IBM’s nine Langflow CVEs landed seven days after the bulletins that fixed them, and a tenth still has no record

    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.