If your business runs Langflow to build a support assistant, a chatbot or an automation that touches customer or order data, this update applies to you. IBM’s bulletin recommends moving to 1.13.0, and for an instance on an affected version that can be reached from outside, that belongs at the front of the queue rather than in the backlog. It covers only Langflow. Other AI tools you expose on the internet are not addressed by these advisories and need checking on their own terms.

What was published, and when

IBM published a security bulletin for Langflow OSS on 28 October 2026 and updated it on 29 October 2026 (IBM bulletin). We read it in full on 3 November 2026. It lists Langflow OSS 1.0.0 through 1.12.8 as affected and recommends 1.13.0, which the project released on 22 October 2026 (release notes).

The bulletin also covers separate issues in the Hono dependency. This checklist focuses on the four Langflow-specific identifiers, which differ in what an attacker needs:

  • CVE-2026-93680 is an improper-authentication flaw that lets someone bypass security restrictions without an account.
  • CVE-2026-110186 is a code-generation flaw that can lead to arbitrary code execution, also without an account.
  • CVE-2026-110193 lets a low-privilege signed-in user run operating-system commands through the Agentic Assistant code-generation feature.
  • CVE-2026-110192 lets a signed-in user obtain sensitive credentials.

The bulletin does not map each identifier to a specific endpoint or feature beyond what is listed above, and we do not guess.

Why an SME should care

What a Langflow instance can reach depends on what you have connected to it: model-provider API keys, database connections, uploaded documents, conversation history. The two issues that need no account mean a restriction bypass or code execution could be attempted by anyone who can reach the instance. What that attacker could then do to your data and the host depends on the privileges the Langflow process runs with. The two authenticated issues require a valid signed-in account, even a low-privilege one, so how accounts on that instance are issued and shared matters as well.

The Hacker News reported on these flaws on 2 November 2026 (report). As of 3 November 2026, the sources we checked did not establish exploitation in the wild. That is not evidence of absence. Treat an internet-reachable instance on an affected version as exposed until it is upgraded.

Owner checklist

1. Confirm what is actually running. Check the version of the package installed in the environment that really serves Langflow, or the identity of the image the container is actually running from. A requirements file or an image tag on its own is not proof. A file can pin one version while the server runs another, and a tag can be moved. If a provider operates the instance, ask them to confirm the running package or image identity rather than the tag.

2. Back up before touching anything. Take copies of the database, the secret key and uploaded files, and confirm you can read them back. Our backup guide covers restore testing in more depth.

3. Prepare for the auto-login change. In 1.13.0 auto-login is off by default, but an existing environment setting can still override that. If you rely on auto-login today, make sure the account has a password you know before you upgrade. If you still get locked out, follow the project’s official recovery guidance. Do not delete the install and start over, because that is a common way to lose your flows.

Turning auto-login off on an older version is sound configuration. It is not a verified substitute for the upgrade, and nothing we read shows it closes all four issues.

4. Upgrade using the official path. For a Python install, IBM’s recommended command is:

pip install --upgrade "langflow==1.13.0"

For Docker, move to the langflowai/langflow:1.13.0 image while keeping your persistent volumes. The project’s installation and Docker pages, which we opened on 3 November 2026, describe both routes.

5. Verify after the upgrade. Check the running version again, sign in, and run the one workflow your business cannot do without. A patch that was applied but never tested is a problem waiting for a busy day.

6. If a provider hosts it for you. Ask them to confirm in writing the version now running, when the backup was taken and how they validated the result. How they get there is their call. What you need is the record.

7. Look back before you move on. Review the logs from before the upgrade. If anything suggests unexpected access, preserve the evidence first, then assess which keys and connections were reachable from that instance and rotate what you need to. The upgrade fixes the named issues. It is not evidence that the host was clean beforehand, and it does not undo anything that may already have happened. Our note on monitoring beyond uptime explains what to watch day to day.