# Langflow Privilege Escalation via Superuser CLI Invocation

- **Severity:** High
- **Signature ID:** `3f2b8c1e-7d4a-4e6b-9c05-8a1d2f6b4e93`

## Summary

Langflow is an AI workflow builder with a normal sign-up page that only ever creates regular, non-admin users. It also ships a hidden command-line option, 'langflow superuser', that writes a full administrator account straight into the database, skipping that restriction entirely.

## How the attack works

An attacker first gets some form of code execution on the Langflow host — for example through an existing account plus a separate remote-code-execution flaw. They then run the 'langflow superuser' subcommand, which can be invoked directly, through the Python module form, via a container exec, or wrapped in tools like 'uv run'. This command mints a brand-new administrator account regardless of how it is invoked. The attacker logs back in through the normal login page using that new admin account and now has full administrative control of the Langflow instance.

## Why it matters

An attacker with only limited access can turn it into full administrative control of the Langflow deployment, gaining the ability to view, modify, or exfiltrate all flows, credentials, and data the platform manages.

## What you can do

- Restrict who can execute shell commands or reach a shell inside Langflow hosts and containers; treat any post-deployment code-execution path as high-risk.
- Audit all admin accounts periodically and flag any created outside your known provisioning process (e.g. not through the documented LANGFLOW_SUPERUSER environment-variable bootstrap at first run).
- Alert on any use of the 'langflow superuser' command after initial deployment — it should only ever appear once, during install, in your entrypoint/Helm/Ansible provisioning step.
- Limit who has shell or container-exec access to Langflow hosts, and separate deployment/provisioning credentials from day-to-day operational access.

## Known benign look-alikes

- Legitimate first-run administrator provisioning by the platform operator - an entrypoint, Dockerfile RUN step, Ansible task or Helm post-install hook executing 'langflow superuser --username admin --password $PW'. Expected once at install time; the same command appearing on a long-running host after deployment is the actual signal. Action is report precisely so this bootstrap case is auditable rather than disruptive.
- Platform engineers performing an authorised admin-account reset or recovery after an admin lockout.
- Local development environments where the developer intentionally promotes their own account while building flows.
- Engineers inspecting CLI usage with 'langflow superuser --help' - suppressed by filter_help.
- Documentation greps, git commits and CI doc builds that merely mention the command string - suppressed by filter_readonly_inspection and filter_test_harness.

## References

- https://owasp.org/Top10/A01_2021-Broken_Access_Control/
- https://owasp.org/Top10/A04_2021-Insecure_Design/
- https://attack.mitre.org/techniques/T1136/001/
- https://attack.mitre.org/techniques/T1078/003/

---
Source: https://www.netzilo.com/threats/langflow-superuser-cli-escalation