Langflow

[thirumalreddyadupally]

Langflow was acquired by IBM in the feb 2025. In the IBM security advisory, only IBM Langflow Desktop is explicitly listed as affected. However, it does not clarify whether the open-source Langflow Git package is also impacted.

Given this ambiguity, should detection be written to cover all installation types when addressing the IBM advisory CVEs?

https://www.langflow.org/blog/big-news-for-langflow

IBM Advisory CVE :
https://www.ibm.com/support/pages/node/7271092

[musaabhasan]

For detection engineering, I would split this into two layers rather than writing one broad rule.

1. Product/package exposure: detect IBM Langflow Desktop explicitly because the advisory names it. This should use desktop-specific evidence where possible: installed application name, vendor metadata, bundle path, signed package metadata, desktop version, or installer inventory.

2. Vulnerable code exposure: separately detect open-source Langflow deployments only when you can prove the affected vulnerable component or code path is present. That could use package version, container image tag, Python package metadata, dependency lockfile, or the exact vulnerable file/function if the advisory gives enough detail.

If the advisory does not confirm the open-source Git package is affected, I would label that second detection as "potential exposure" or "requires triage" rather than "confirmed vulnerable." That prevents false positives while still giving security teams a way to inventory Langflow servers that may need vendor clarification.

The detection output should preserve the evidence fields: product name, install type, version, path/image/package, advisory id, confidence, and reason. That makes it easier to update the rule once IBM or the Langflow maintainers clarify the affected distribution boundary.