Langflow flaw: 4,619 honeypot attempts by 25 Oct, and Langflow says 1.9.0 was only the first of two fixes

4,619 attempts on one sensor, and a fix that came in two steps

Previdian's page for CVE-2026-105740 counted 4,619 exploitation attempts against a Langflow flaw, from 33 source addresses, recorded by one sensor, when it was read at about 17:46 GMT on Sunday 25 October 2026. The Hacker News had reported 1,423 on 15 October. That is not growth between two different counts. The page's own daily bars add up to 4,619, and to exactly 1,423 at the moment The Hacker News wrote (derived). It is one series, read twice. Previdian defines an attempt as an attempt to exploit "whether or not the target was actually vulnerable or the attempt succeeded", so the figure measures how often something knocked, not how often anything opened.

What the number does not establish: a single compromise, how many Langflow servers are online, which version or login the sensor presented, or who is sending the traffic. It also does not decide what the headline's two adjectives mean. "Authenticated" sounds like a locked door, but Langflow's own advisory says that with the default auto login setting an exposed server hands out a token without credentials. "Fixed in 1.9.0" sounds like a finished repair, but Langflow's own later advisory says the issue "was fixed in two steps" and that 1.10.3 is the full fix. Ten releases, 1.9.0 to 1.10.2, carried only the first step (derived from Langflow's table and the GitHub releases list).

This briefing reads the sources behind the headline rather than the headline. Between 17:46 and 18:13 GMT on 25 October 2026 it read Previdian's CVE page and methodology page, Langflow's two GitHub advisories and their API records, the CVE records and NVD entries, the CISA catalogue file, Langflow's release notes, four pull requests and four documentation pages, VulnCheck's blog and Previdian's July post, and four UK government pages. The Hacker News report of 15 October and a later article are used only for what they report and for what Previdian's founder told The Hacker News. Nothing was filled in or submitted, no account was needed, and the advisories' proof of concept is neither reproduced nor saved.

Stated and not stated: the record, line by line

The table sets what each source states against what it does not. "Does not say" means the source is silent on it, not that it is false.

Two things follow. Every figure in the headline is a sensor count and every severity word is a label from the vendor or its CNA; neither measures harm. And the CVE record that says "fixed in 1.9.0" lists, in its own references, the Langflow advisory that says 1.10.3 is the full fix. The record points at its own correction.

What the count shows: a switch on 11 October, then a steady rate

Previdian's page draws one bar per day, 18 September to 25 October. Adding the bars gives 4,619, the page's headline figure (derived). Adding every day to 14 October (1,357) and the 66 attempts The Hacker News said had been seen so far on 15 October gives 1,423, its first figure. The later totals fit the same series: 1,706 is all of 15 October (316) plus 33 attempts from 16 October, and a later article's 2,023 is all of 16 October (303) plus 47 from 17 October (both part day amounts are inferred, not read). The series is the record. The totals are readings of it.

The step from 43 on 10 October to 333 on 11 October is 7.7 times (derived). After it the daily figure barely moves: in the last seven full days it runs 280, 330, 323, 323, 323, 323 and 322. At 323 a day that is one attempt about every 4.5 minutes (derived), and a re read at 18:13 GMT showed 4,625, six more in 27 minutes, where 323 a day gives 6.1 (derived). A rate that flat looks like a schedule more than a crowd. That is inference: the page withholds the split by address, so 33 addresses could share the work in any proportion, and The Hacker News says a "significant chunk" came from one address. What can be said is that an automated process has been hitting one sensor at a near constant rate for two weeks. A honeypot is built to be found. The figure says nothing about how many real servers were tried or how many gave way.

Two comparisons put the number in proportion. In July, Previdian (then trading as KEVIntel) reported 137 attempts from 46 addresses on seven sensors for a different Langflow flaw, CVE-2026-0770, before CISA added it to its catalogue on 21 July. This flaw has 33.7 times as many attempts (derived), from fewer addresses, on one sensor, and is not listed. That does not explain CISA's choices. It shows that volume and listing do not move together. And the EPSS model, which Previdian prints on its page, puts the chance of exploitation in the next 30 days at 0.6 per cent, beside 4,619 observed attempts. Previdian says its warning "comes from evidence, not this score". They measure different things.

Fixed in 1.9.0, or fixed in two steps?

The CVE record for CVE-2026-105740 describes the flaw as present "Prior to 1.9.0" and says it "is fixed in 1.9.0". Previdian's page says "affected before 1.9.0" and The Hacker News says "prior to 1.9.0". Langflow's second advisory, published on 28 September and listed in that CVE record's references, tells a longer story. It says the issue "was fixed in two steps and is fully fixed in Langflow 1.10.3". The table follows Langflow's own account, release range by release range.

The first step is visible in the public record. Pull request 12290, merged on 27 March 2026, is titled "prevent MCP command injection via allowlist validation (CWE-78)", and the 1.9.0 release notes of 14 April list it by that title, with no severity word. The second step, pull request 14036 ("harden MCP stdio configuration"), merged on 14 July and shipped in 1.10.3 on 23 July, again with no severity word in the release notes. The severity, the CVE numbers and the advisories all came later, in September and October.

The Hacker News describes CVE-2026-105697 as "another" flaw patched in 1.10.3. Langflow's advisory presents it as the second step of the same issue. The two CVE records share one CVSS vector, one weakness (CWE-78) and each other's advisory in their references, and CISA's coordinator entries differ only in exploitation: "none" for CVE-2026-105697 and "poc" for CVE-2026-105740, both dated 6 October, before the jump in attempts. Whether that is one flaw or two is a labelling choice. For a defender the useful fact is the version: below 1.10.3 some route is open.

The honeypot traffic, as The Hacker News describes it, uses the MCP server configuration endpoint, which is the REST route the first fix closed. A server on 1.9.0 to 1.10.2 should therefore turn that request away, on Langflow's own description. It should not be read as safe on that evidence: quiet logs on the REST route say nothing about the flow route, and no source read says attackers have tried the flow route or have not. (Inference from Langflow's table and The Hacker News's description.)

"Fixed" also means an allowlist, not the removal of a feature. The message a fixed build returns lists the commands still allowed, and Langflow's advisory adds that the list "still lets npx / uvx run any package by default". That is how MCP servers are normally distributed, so the fix stops arbitrary commands, not arbitrary packages. Langflow's advisory names settings for multi tenant servers; they are printed in the Technical details section below.

The gap between a fix and its advisory is a pattern this site has met twice. The PoeLLM and LiteLLM briefing found a fixed release 177 days before the report that named the flaw, and the MCP Python SDK briefing found a fix 21 days before its advisory. Here the first fix was released 149 days before the first advisory page (derived: 14 April to 10 September). A team that waits for an advisory to start patching is waiting for the wrong signal.

The order of events

Zoom

Read as dates. The first fix was merged on 27 March and released on 14 April. The advisory page appeared on 10 September, 149 days after the release. The sensor logged its first attempt on 19 September, 9 days after the advisory and 158 days after the release (all derived). The CVE numbers were published on 5 October, 16 days after that first attempt. A sensor cannot record a CVE number that does not exist yet, so the label was applied after 5 October (inference). Previdian's page does not show what the single attempt on 19 September was.

The jump to 333 a day came on 11 October: 6 days after the CVE numbers and 31 days after the first advisory (derived). That ordering fits attackers acting on the public CVE. It does not show it. The sensor sees timing, not motive.

"Authenticated": who can log in to a Langflow server

The advisory's wording is any authenticated Langflow user, including accounts that are not administrators. On a server where signing in means a person chose a password, that is a real barrier. Langflow's own pages describe other cases.

Langflow's own pull request 13699, merged on 18 June, said that "AUTO_LOGIN defaults to True" and that the default configuration handed a year long superuser token to anyone who could reach the auto login route. It shortened the token (release 1.10.1, 23 June) and left the default alone, calling a change of default a breaking change "staged for v2.0". The default was changed for official release artefacts by pull request 14993, merged on 29 September, and shipped in 1.13.0 on 22 October: 23 days later, and three days before this reading (derived).

Upgrading does not clear it. The 1.13.x documentation says "Official release packages, tagged source archives, and Docker images disable automatic login by default", and also that an explicit setting in an existing environment or .env file takes precedence over the new default, and that turning auto login off stops new anonymous sessions but does not revoke sessions or API keys already issued. An operator who patches and does nothing else may keep auto login on, and keep every token it issued.

There is a further layer. Langflow's security page says the interface "is an IDE and code execution platform", inherently capable of executing arbitrary code that developers write, and that user access controls are "designed for usability, not security enforcement". The documentation lists custom components as allowed by default, so a user who can build flows can probably already run code by design (inference from the documentation). The MCP flaw matters most where an operator has blocked custom code, and for what the advisory calls its stealth: unlike component code, "MCP server configs are stored in project settings and are not visible during normal flow review". A reviewer who reads every flow will not see it.

The scoring tells the same story. The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, and PR:L is "privileges required: low", meaning an account. With privileges required set to none and everything else unchanged the vector scores 10.0, so the login is worth 0.1 of a point (derived). Scope "changed" is what holds the score near the top: with scope unchanged the same vector would score 8.8 (derived). The label 9.9 already prices an account at almost nothing.

A pattern, and the catalogue shows only part of it

Langflow is a repeat target. CISA's catalogue lists six Langflow entries, five of them added in 2026, and none of them is either of the MCP command flaws.

VulnCheck, a vendor that sells exploit intelligence, counted twelve Langflow vulnerabilities reported as exploited in the wild in a post of 28 August: one before 2026 and eleven in 2026. Its own deliberately vulnerable canary servers saw what follows code execution on a Langflow host. One attacker dropped a credential harvester, proxy agents and a remote access tool, and installed a scheduled job for persistence. Another installed a cryptocurrency miner and switched off the audit daemon. Those were other flaws, not this one. The point carries over (inference): once an attacker has commands on a Langflow host, what happens next does not depend on which CVE opened the door.

It matters here because of what a Langflow process holds. The documentation says LANGFLOW_SECRET_KEY encrypts stored credentials such as API keys and, with the HS256 algorithm, signs session tokens. The Hacker News reports that captured payloads tried to read LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD from the environment and send them to an address outside the honeypot. Whether or not any of that worked on a real server, those are the two values to treat as lost if a server was exposed.

Friendly names, and whose interest they serve

A label is not a measurement. Six appear in this story.

Whose interest? Previdian sells early warning data on paid plans and a free trial, and its page is the product's shop window. A high count helps sell it. That is no reason to doubt the count, which reconciles with the daily bars. It is a reason to note who prints it and what is withheld. VulnCheck sells exploit intelligence and has the same incentive. Langflow's maintainers wrote both advisories, and the second corrects the first, so the vendor is on record against its own CVE text. This briefing follows the vendor's later account over the CVE record where they differ, and says so.

Technical details

This section prints what the sources publish: the two requests, the configuration model, the launch code before and after, the version strings, the settings, and what Previdian's page shows. Every block names its source and the day it was read, 25 October 2026. Text is copied from saved pages and not retyped. Anything this site worked out is marked derived. The attacker side items come from The Hacker News, a secondary source, because Previdian's public page withholds request targets, User Agents, callback hosts and payloads (it counts 4,595, 28 and 1) behind paid plans. No exploit or proof of concept is reproduced. Langflow's advisories print one, and this briefing leaves it out.

First, the two requests. The first stores a server definition for the signed in account. The second lists the servers, and with the action count option Langflow connects to each stored stdio server, which starts the stored command. The advisory says this happens when someone opens the MCP settings page, and that it repeats every time the list is loaded, including for other users and administrators. A defender watches both requests in access logs.

POST /api/v2/mcp/servers/{server_name}
GET /api/v2/mcp/servers?action_count=true

Next, the body of that first request. The advisory's own comments call three of the fields attacker controlled: command, args and env. A defender reviewing stored MCP servers looks at exactly those three on every stdio entry, because the advisory says such entries are not visible in normal flow review.

class MCPServerConfig(BaseModel):
    command: str | None = None       # Attacker-controlled OS command
    args: list[str] | None = None    # Attacker-controlled arguments
    env: dict[str, str] | None = None  # Attacker-controlled environment variables
    url: str | None = None
    headers: dict[str, str] | None = None

Then the launch itself, before and after. Before 1.10.3 the stored command was placed inside a shell. From 1.10.3 it is split into an executable and arguments, checked against one policy, and started without a shell. On a vulnerable build the process the Langflow server starts is therefore a shell whose command line begins bash -c exec (derived from the code). Stored servers that are legitimate, such as npx or uvx launchers, will start the same way, so baseline them first.

server_params = StdioServerParameters(
    command="bash",
    args=["-c", f"exec {command_str} || echo 'Command failed with exit code $?' >&2"],
    env=env_data,
)

command_parts = shlex.split(command_str)
command, args = command_parts[0], command_parts[1:]
validate_mcp_stdio_config(command, args, env)   # final pre-spawn enforcement
server_params = StdioServerParameters(command=command, args=final_args, env=env_data)

A fixed build refuses a command outside its allowlist with a message that names the allowed commands. That message is also a check an administrator can look for in logs on a patched server: it shows the policy is live. Langflow says wrappers such as shell and interpreter one liners are also rejected.

Command 'touch' is not allowed for security reasons. Allowed commands: bash, cmd, docker, node, npx, python, python3, uvx

What each fix step checks, in Langflow's words. The first step validates the request model. The second moves the policy to the point of launch and drops the shell. The env var blocklist in the first step is the useful hint for defenders: variables that change how a launched process loads code are on it.

1.9.0 (pull request 12290): `MCPServerConfig` validators: command allowlist (`node`, `python`, `python3`, `npx`, `uvx`, `docker`, and `cmd`/`sh`/`bash` only to wrap one of those), shell-metacharacter and dangerous-keyword checks on arguments, env var blocklist (`LD_PRELOAD`, `NODE_OPTIONS`, `PYTHONPATH`, `BASH_ENV`, ...), and Docker isolation checks
1.10.3 (pull request 14036): moves the policy into `lfx.base.mcp.security.validate_mcp_stdio_config` and enforces it at every entry point (API, embedded flow / tweak configs, the deprecated MCP Stdio component and just before spawn); it also launches the process without a shell

The affected and fixed versions as the CVE.org records print them, followed by the scores and CISA's coordinator entries. The first record says before 1.9.0. The second gives three PyPI packages and a threshold of 1.10.3. Both packages langflow and lfx matter: the launch code lives in the lfx package.

{
  "CVE-2026-105740 (record published 2026-10-05T20:46:18.854Z, CNA GitHub_M), containers.cna.affected": [
    {
      "vendor": "langflow-ai",
      "product": "langflow",
      "versions": [
        {
          "version": "< 1.9.0",
          "status": "affected"
        }
      ]
    }
  ],
  "CVE-2026-105697 (record published 2026-10-05T20:16:58.291Z, CNA GitHub_M), containers.cna.affected": [
    {
      "vendor": "langflow-ai",
      "product": "langflow",
      "versions": [
        {
          "version": ">= 1.1.2, < 1.10.3",
          "status": "affected"
        }
      ]
    },
    {
      "vendor": "langflow-ai",
      "product": "langflow-base",
      "versions": [
        {
          "version": ">= 0.1.2, < 0.10.3",
          "status": "affected"
        }
      ]
    },
    {
      "vendor": "langflow-ai",
      "product": "lfx",
      "versions": [
        {
          "version": "< 1.10.3",
          "status": "affected"
        }
      ]
    }
  ]
}

{
  "CVE-2026-105740 containers.cna.metrics": [
    {
      "cvssV3_1": {
        "attackComplexity": "LOW",
        "attackVector": "NETWORK",
        "availabilityImpact": "HIGH",
        "baseScore": 9.9,
        "baseSeverity": "CRITICAL",
        "confidentialityImpact": "HIGH",
        "integrityImpact": "HIGH",
        "privilegesRequired": "LOW",
        "scope": "CHANGED",
        "userInteraction": "NONE",
        "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
        "version": "3.1"
      }
    }
  ],
  "CVE-2026-105740 containers.adp (CISA ADP Vulnrichment) metrics": [
    {
      "other": {
        "type": "ssvc",
        "content": {
          "timestamp": "2026-10-06T18:20:20.481095Z",
          "id": "CVE-2026-105740",
          "options": [
            {
              "Exploitation": "poc"
            },
            {
              "Automatable": "no"
            },
            {
              "Technical Impact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    }
  ],
  "CVE-2026-105697 containers.adp (CISA ADP Vulnrichment) metrics": [
    {
      "other": {
        "type": "ssvc",
        "content": {
          "timestamp": "2026-10-06T14:36:02.678305Z",
          "id": "CVE-2026-105697",
          "options": [
            {
              "Exploitation": "none"
            },
            {
              "Automatable": "no"
            },
            {
              "Technical Impact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    }
  ]
}

Langflow's account of which release does what, as printed in the later advisory's table (the markdown table rows are shown as the advisory prints them).

| `1.1.2` to `1.4.x` | MCP Stdio component (added in #5148) runs `StdioServerParameters(command=..., args=...)` from the component's `command` field with no validation. |
| `1.5.0` to `1.8.x` | "Add MCP Server" settings page and `/api/v2/mcp/servers` API added (#8388). Stored stdio configs are launched via `bash -c "exec {command_str} ..."` with no validation. |
| `1.9.0` to `1.10.2` | #12290: `POST`/`PATCH /api/v2/mcp/servers` reject commands outside the allowlist. The execution sink still has no validation and still uses `bash -c`, so configs that do not go through `MCPServerConfig` (for example an MCP Tools component value embedded in a flow or passed as a tweak) can still execute arbitrary commands. |
| `1.10.3`+ | #14036: one shared policy (`lfx.base.mcp.security.validate_mcp_stdio_config`) is enforced at the API, at flow execution and right before the process is spawned; no shell is used. **Fixed.** |

Settings. The advisory's workaround for servers that cannot upgrade immediately is to turn auto login off and keep the server off untrusted networks. The documentation prints the pair of lines below for a new install. The superuser password shown is a placeholder, not a credential.

LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER_PASSWORD=REPLACE_WITH_A_STRONG_PASSWORD

For servers where several people build flows, the advisory names these settings for 1.10.3 and later. They are listed here by name and value as the advisory prints them; the first has no value in the advisory, because the operator supplies the list of packages that npx and uvx may run. The custom code settings are from 1.11.1 and later on the advisory's account.

LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES
LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true
LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true
LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false
LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true
LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true

The documentation also lists defaults that decide who can reach the flaw. Names and defaults below are copied from its tables; the descriptions are left out. Note that custom components and public registration are on by default, new accounts are inactive by default, and the superuser command line is on by default.

LANGFLOW_ALLOW_CUSTOM_COMPONENTS  default True
LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS  default False
LANGFLOW_RESTRICT_LOCAL_FILE_ACCESS  default True
LANGFLOW_MCP_SERVER_DOCKER_HARDENING  default False
LANGFLOW_TWEAKS_POLICY  default permissive
LANGFLOW_ENABLE_SIGNUP  default True
LANGFLOW_NEW_USER_IS_ACTIVE  default False
LANGFLOW_ENABLE_SUPERUSER_CLI  default true
LANGFLOW_SKIP_AUTH_AUTO_LOGIN  default false

Previdian's public page prints one response shape, a sample of its paid API, and three counts for what it keeps. The counts are the most the page gives on the traffic itself: 4,595 request targets, 28 User Agents and one callback host, against 4,619 attempts. That is almost one different target per attempt (derived, 99.5 per cent), which fits a path that changes every time, such as a randomly named server in the request path. That reading is inference.

{
  "cve_id": "CVE-2026-105740",
  "confidence": "Confirmed",
  "cvss_score": 9.9,
  "cvss_estimated": false,
  "epss_score": 0.00589,
  "exploit_status": {
    "exploited_in_the_wild": true,
    "active_exploitation_observed": true
  },
  "sensor_telemetry": { "attempts": 4619, "sensors": 1 }
}

Request targets: 4,595
User-Agents: 28
Callback hosts: 1

The attacker side, from The Hacker News report of 15 October, which quotes Previdian's founder. These are the indicators and names it prints, defanged as it printed them, with labels added by this site. The sequence, in the founder's account, was a version check, a request to the auto login route that returned 403 because auto login was disabled on the honeypot, a login with a common username and password, and then use of the bearer token on the MCP server configuration endpoint. The captured payload families were: attempts to read the two environment values and send them to the callback below; Docker commands that try to reach the host file system and read the password file; and simple command probes.

callback host and port: 146.70.211[.]112:18764
source address named: 192.255.229[.]92
environment values targeted: LANGFLOW_SECRET_KEY, LANGFLOW_SUPERUSER_PASSWORD
file named: /etc/passwd
commands named: id, whoami
paths named: /api/v1/auto_login, /api/v2/mcp/servers/

Finally, where to look. These lines are derived by this site from the requests above. Neither Langflow nor Previdian publishes them. They search access logs kept by a reverse proxy or by Langflow for the two requests and for auto login token requests. On a build before 1.10.3, also look for shell children of the Langflow process, and for stored MCP server entries with a command other than a known launcher. A hit is a reason to look, not proof of compromise.

# writes to the MCP server configuration endpoint
grep -E '(POST|PATCH|PUT) /api/v2/mcp/servers/' access.log
# the list call that starts every stored stdio server
grep -E 'GET /api/v2/mcp/servers\?action_count=true' access.log
# auto login token requests (none expected when auto login is off)
grep -E 'GET /api/v1/auto_login' access.log
# installed versions of the three packages the advisories name
pip show langflow langflow-base lfx

The UK: what the guidance says and where it stops

None of the four UK pages read mentions Langflow or MCP (a search of each saved page found no match), and the DSIT code does not mention agents, workflows or orchestration either. The NCSC blog is about AI agents but not about the platforms that build or host them. What follows applies general controls, and says where each one runs out.

The Cyber Essentials arithmetic is worth doing. The scheme's text asks for updates within 14 days of release in three cases, and the third is that the vendor gives no details of severity. Fourteen days after the 1.9.0 release of 14 April is 28 April, and after the 1.10.3 release of 23 July is 6 August (derived). On that reading, a Langflow server inside a certification boundary that still ran a release before 1.9.0 on 29 April was already outside the rule, more than four months before any advisory existed (inference). The CVSS 9.9 from October puts the same updates in the first two cases as well, but the scheme's clock does not wait for the label.

The NCSC blog is the closest UK text to the checklist below. Its maturity levels for compute isolation call a properly configured container "level 2" and virtualisation "level 3", and it says a residual risk of kernel breakout remains at level 2. For a Langflow server holding model provider keys and a secret key, the credentials in its environment are its blast radius. Those are the NCSC's own terms, applied here to a different threat.

ICO guidance applies only to personal data. Flows often retrieve from document stores and keep conversation logs, so a compromised server may have reached personal data, and the 72 hour clock starts on awareness, not on the end of the investigation. The ICO's guide says organisations should "prioritise the investigation" and may report in phases. Whether the NIS Regulations 2018 apply depends on who runs the server and was not examined here.

What to do, in the order worth doing

Every item below follows a Langflow instruction, a Previdian recommendation, or a UK control read above, and is ordered so that the fastest cuts to exposure come first.

What could not be verified

• Payloads and per address counts. Previdian's page withholds request targets, User Agents, callback hosts and payloads. The attacker side items in Technical details come from The Hacker News and are unverified.
• The sensor. Which Langflow version and settings it ran is not stated. The founder's account says auto login was disabled on it.
• Which route is used. The Hacker News describes the MCP server configuration endpoint. No source read says the flow route has been tried, or has not.
• The 19 September attempt. Previdian's page does not show what the single first event was, or when it was mapped to this CVE.
• GitHub's advisory database. Its API returned no record for GHSA-7w94-79vh-5mr2 when queried, though it returned one for GHSA-w794-rj3p-xv45. The repository advisory page and API are readable. The reason for the gap is unknown, and a scanner keyed to that database may see only the second advisory.
• The news report's 15 countries and 27 addresses. The Hacker News's figures were not checked against Previdian's raw events, which are public for 30 days only. The page now shows 17 countries and 33 addresses.
• NSA guidance on MCP. A May 2026 NSA document on MCP security returned an access denied response to an automated fetch, and was not read. Nothing from it is used.
• CISA's thinking. No source read says why CVE-2026-105740 is not listed or when it will be reassessed. The listing status is time stamped to the 23 October file, and the file was still that version when re read at 18:13 GMT on 25 October.

The question that exposes the gap

A fix released in April, an advisory in September, a second fix that made the first complete, and a default that changed three days ago: each one reached a Langflow server only if someone was watching for it. For every Langflow server you run, can you state its version, whether auto login is on, and how many accounts it has, without logging in to it?

Key facts