When a feature flag is a control plane: LaunchDarkly token abuse

A feature flag decides what your application does at runtime, and some flags gate security controls. A stolen LaunchDarkly API token can flip them without ever touching the code.

How the attack works

The token authenticates from a new host and enumerates projects, environments, and flags. It then toggles off a flag that gates a server-side authorization check, disabling that control for every user in production. Next it enables a flag guarding an internal admin panel for an attacker-controlled targeting rule, exposing hidden functionality. To blend into normal flag churn, the attacker toggles back and forth, but each change is recorded in the audit log. In ATT&CK terms this is T1562, Impair Defenses, reached through T1078, Valid Accounts, since the principal is the token rather than a user.

Why it works

The flag service is a live control plane, and a production-write token can change application behavior with no approval gate on security-relevant flags. A flag flip is a real change to which controls are on, but it looks like routine delivery.

How to fix it

The non-obvious move is that you do not redeploy the application, because the code was never the problem. Revoke the token to stop further flips, then restore the affected flags to their known-good state from source or IaC, which re-enables the control for everyone. A password reset does not invalidate the token, and deleting flags can break the logic that reads them. For the class fix, scope tokens by environment and role, require approval and change-detection on security-relevant flags, and manage flag defaults as code so drift is caught. Use the audit log filtered to the token and window to compute exactly how long the control was off.

Practice it

We built this as a GraphLattice Range scenario so teams can rehearse the flag flip, the revoke-and-restore containment, and the executive call that a disabled-control window is a bypass window.