Langflow 1.12.3 fixes cross-user knowledge base isolation; legacy data migration requires manual review

Langflow released version 1.12.3 on September 22, separating storage for OpenSearch and Chroma Cloud knowledge bases by owner. The same version is also available on PyPI. This fix directly affects shared RAG deployments and whether existing documents remain retrievable after an upgrade. [Release notes](https://github.com/langflow-ai/langflow/releases/tag/v1.12.3), [PyPI release record](https://pypi.org/project/langflow/1.12.3/)

The problem stems from inconsistent naming rules across two layers: the application allows different users to create knowledge bases with identical names, while remote storage may use only the knowledge base name. If two users both create “docs” and connect to the same OpenSearch cluster, or the same Chroma Cloud tenant and database, queries may return document fragments belonging to the other user, and deletions may affect the other user's data. The maintainers provided a two-user reproduction, but this does not establish that data was exposed in every deployment. [Fix details](https://github.com/langflow-ai/langflow/pull/15148)

The new version generates hashed storage names from the owner ID and knowledge base name, and restricts regular users' ability to specify physical indexes or collections. During migration, legacy names attributable to a single owner retain their existing bindings. Names shared by multiple users trigger warnings, and the affected knowledge bases are redirected to separate, empty storage areas for each owner; the original data is not deleted. Because the migration does not verify remote accounts, knowledge bases with identical names may require manual restoration even if their data was never actually mixed. [Migration rules](https://github.com/langflow-ai/langflow/pull/15148)

The release notes also list fixes including SSRF validation for knowledge base connection targets and isolation of cached frozen-node results by executing user. These changes address outbound connection and cache boundaries, respectively. Confirming that storage names are distinct is still insufficient to verify permission behavior across the entire workflow. [Full changelog](https://github.com/langflow-ai/langflow/releases/tag/v1.12.3)

In the official documentation, “Test Connection” checks whether the backend is reachable. This issue suggests that, beyond confirming a successful connection, administrators should also trace the physical collection a knowledge base ultimately uses and the scope of its credentials. Resources displayed separately in the interface are not necessarily stored separately underneath. [Knowledge base documentation](https://docs.langflow.org/knowledge)

Engineering teams' upgrade acceptance testing should cover queries, counts, and deletions after two accounts create knowledge bases with identical names. Teams should also retain a record of legacy index mappings and the original documents. If old content is no longer visible after the upgrade, first check migration warnings and data ownership, then decide whether to reimport the documents or have an administrator restore the bindings. The practical priority is to validate the installation and historical data migration separately; a public reproduction cannot replace acceptance testing in each team's own environment.