Eight CVE records against Langflow OSS, the visual builder for LLM workflows, were published between 22:16:46 and 22:16:47 UTC on 28 August. All eight name versions 1.0.0 through 1.11.1. Two are critical: 9.8 and 9.9.
What they describe
Remote code execution, server-side request forgery, authenticated code execution, arbitrary file read, and information disclosure. For a tool whose function is to let users assemble and run model pipelines, the boundary between intended capability and code execution is genuinely hard to draw — which makes the specific version ranges and the scoring authority the things worth checking.
Vendor and scorer are the same party
Every one of the eight lists IBM's product security team as the source identifier, and IBM is the numbering authority for its own products. The 9.8 and the 9.9 were therefore assigned by the vendor to itself. That is normal in the CVE system and not evidence of anything improper. It does mean these figures have had no external calibration, unlike records scored by a third-party authority.
What the common framing gets wrong
"Eight new critical vulnerabilities" implies eight new exposures. The fixes shipped weeks earlier, in a maintenance release published as ordinary bug fixes — anyone on a current version was never at risk from this batch. What is new is the paperwork. And the paperwork has a defect of its own: the advisories carry no affected package entries. A record with an empty package list will not match anything in a dependency graph, so automated scanners do not raise it, and the users least likely to read a changelog are exactly the ones the CVEs were supposed to reach.
The practical position
Upgrading past 1.11.1 resolves all eight. Waiting for a scanner to tell you to will not work, because on current metadata no scanner will.