Three FlowiseAI advisories published on August 28 with no CVE assigned got CVE IDs on Friday — six weeks after the release that fixed them, and from a third-party CNA rather than the vendor.
What happened
On September 12, 2026, at 1:16 p.m. UTC, VulnCheck published CVE-2026-90533, CVE-2026-90534, and CVE-2026-90535 against Flowise, the low-code builder that a very large number of organizations self-host to assemble LLM applications and agents. All three are fixed in version 3.1.4.
Flowise 3.1.4 was published to npm on July 29, 2026, at 10:15 a.m. UTC. It is still the latest tag; 3.1.3, the last affected release, went out on June 25, 2026. The fix, in other words, has been sitting on the registry for forty-five days, and the version numbers involved have not moved since.
FlowiseAI published its own advisories for all three on August 28, 2026, fifteen days before the CVE IDs existed. Each is rated Moderate by the vendor. Each states that no CVE was assigned.
CVE-2026-90533, the vendor’s GHSA-fhxm-xxcx-g6x3, is titled “Broken access control in GET /api/v1/organizationuser leaks the organization owner’s password hash to any member (privilege escalation/account takeover).” Any authenticated organization member, including one holding the lowest-privilege member role with empty permissions, can retrieve the organization owner’s complete User entity — bcrypt password hash and tempToken/tokenExpiry fields included. The vendor names two causes: the GET handler lacks the authorization checks its POST, PUT, and DELETE counterparts enforce, and the backing service returns the record without scrubbing sensitive fields. Vendor CVSS v4.0 score 6.0. Credited to Shirshakhtml. The advisory notes the issue is distinct from CVE-2025-58434, affecting a different code path and exposing credential hashes rather than only temporary tokens.
CVE-2026-90534, GHSA-hqvm-7539-v83j, is the one to read twice. NVD’s description, supplied by the CNA, says the POST /api/v1/node-load-method/:name endpoint “is mounted without any route-level permission check and invokes component loadMethods with an attacker-controlled nodeName, loadMethod, inputs, and credential value. The selected credential is resolved by raw Credential.id via getCredentialData() and decrypted without verifying Credential.workspaceId against the caller’s active or shared workspace, unlike other credential read paths which are workspace-scoped.” The result is what the record calls a confused deputy: a low-privilege user, or a workspace API key, in one workspace supplies a credential ID belonging to another workspace, and Flowise makes the third-party provider call with the victim’s credential. The statically identified load methods are Google Drive listFiles, Google Sheets listSpreadsheets, and AWS DynamoDB KV Storage listTables. The record is explicit that “the raw credential secret itself is not returned to the attacker.” CWE-639, vendor and CNA CVSS v4.0 score 6.1. Credited to c4tzzz.
CVE-2026-90535, GHSA-xhxx-56g3-mx2r, covers the /api/v1/text-to-speech/abort endpoint, which has no authentication or authorization. An unauthenticated attacker with a known chatflowId and chatId can terminate another user’s in-progress chatflow prediction — and the vendor notes the abort reaches the main chatflow controller, not only the text-to-speech one, “causing a targeted denial of service.” CWE-862, CVSS v4.0 score 6.3. Credited to offset.
One detail in the NVD records is worth noting on its own. All three carry a CVSS v4.0 score from [email protected] marked as a secondary metric, and no primary score at all. There is no CVSS v3.1 vector on any of them. None of the three appears in CISA’s Known Exploited Vulnerabilities catalog, published version 2026.09.11, and no exploitation has been reported.
Why it matters
Take the credential IDOR first, because the 6.1 will get it triaged wrong in both directions. On a single-workspace Flowise — one team, one tenant, everyone already trusted with the credentials — 6.1 is generous, and the honest answer is that it barely matters. On a Flowise serving multiple customers or multiple business units out of one deployment, 6.1 badly understates it. The whole function of the product is to hold other people’s API credentials so that a chatflow can act on their behalf. An authorization bug in the thing that resolves those credentials is not a bug in Flowise; it is a bug in every provider Flowise holds a key for.
The record’s caveat is real and should be kept: the attacker does not get the secret. What the attacker gets is the ability to make Flowise use it, and to read back what came out. Listing the files in someone else’s Google Drive, the spreadsheets in their Sheets account, and the tables in their DynamoDB is not a credential dump. It is an inventory of another tenant’s data estate, produced by your own server, with that tenant’s authorization, and the only thing standing between that and heavier use of the same credential is which load methods happened to be enumerated. The report says “statically identified,” which is the researcher telling you the list is what code reading found, not what the endpoint can reach.
Then the record gap, which is the more general lesson. There were two populations of Flowise operators over the last six weeks. One watched GitHub advisories, Dependabot, or npm audit, and found out on August 28 that they should be on 3.1.4. The other runs a scanner or an SBOM pipeline keyed on CVE identifiers against the NVD feed — which describes most enterprise vulnerability management — and found out on Friday. Same flaw, same fix, same registry, forty-five days of difference in when the ticket got created.
This is not a one-off. Nodemailer’s maintainers published GHSA-prgh-xp8r-p3m5 on September 11 for a remote denial of service reachable through mailparser, with the advisory stating no known CVE; VulnCheck published CVE-2026-90776 for it on September 13. Same shape, two days instead of fifteen. A third-party CNA is doing the work of closing the gap between the vendor advisory ecosystem and the CVE ecosystem, and doing it on its own schedule, after the fact. That is better than the gap staying open. It is not the same thing as the gap not existing.
The missing primary CVSS compounds it. A scanner that sorts on CVSS v3.1 base score — still the default in a lot of tooling — has nothing to sort these on. A policy that escalates only above a v3.1 threshold will not fire. The v4.0 scores are present, they are the vendor’s own numbers, and they are secondary metrics from a CNA rather than NVD analyst scores. Anyone whose triage assumes a v3.1 number is always there should check what their pipeline does with a record that has none.
What to do
Upgrade to Flowise 3.1.4. It has been on npm since July 29, 2026, it is still the latest release, and it closes all three. If you are on 3.1.3 or below, nothing about this is complicated.
If an upgrade has to wait, three endpoints can be blocked at the reverse proxy in front of Flowise: GET /api/v1/organizationuser, POST /api/v1/node-load-method/:name, and /api/v1/text-to-speech/abort. Blocking the second will break the credential picker in the builder UI, so treat it as a short-term measure rather than a configuration.
If you ran a multi-member Flowise below 3.1.4 and not everyone with an account was trusted with the owner account, force a password change on the organization owner and invalidate outstanding tempToken values. A bcrypt hash that was readable by any member is a hash that may have been taken away for offline work.
If you ran a multi-workspace Flowise, the credentials themselves were not disclosed, so a full rotation is not indicated by this record alone. What may have been disclosed is the list of resources those credentials can see, in other workspaces. Whether that is worth telling a tenant about is a judgment call, and it is easier to make now than after someone else makes it for you.
Last, use this one to measure your own pipeline. The vendor advisory is dated August 28 and the CVE IDs are dated September 12. Whichever of those dates your tooling reacted to tells you which feed you are actually running on.
Sourcing note
Checked: FlowiseAI’s three GitHub Security Advisories — GHSA-fhxm-xxcx-g6x3, GHSA-hqvm-7539-v83j, and GHSA-xhxx-56g3-mx2r — for the titles, publication date of August 28, 2026, vendor severity and CVSS v4.0 vectors, affected and patched versions, credits, and the statements that no CVE was assigned; the NVD records for CVE-2026-90533, CVE-2026-90534, and CVE-2026-90535 for descriptions, CWEs, scoring source and metric type, and publication timestamps; and the npm registry directly for Flowise release dates and the current latest tag. The nodemailer comparison rests on GHSA-prgh-xp8r-p3m5 and the NVD record for CVE-2026-90776, both read for this piece. The KEV catalog was read from the cisagov/kev-data mirror on GitHub, because cisa.gov returns 403 to automated fetching; the version read was 2026.09.11.
Unresolved: why the CVE assignments came from VulnCheck rather than through GitHub, which is itself a CNA and published the advisories. Nothing in the advisories explains it, and we did not reach anyone at either organization. Also unresolved: whether the three advisories have since been updated to carry the new CVE IDs — at the time of reading, they had not.