Feature Toggle Service Exposes Internal Admin Endpoints to the Public Internet
The Risk
An internal control panel that the company uses to manage product features and toggles was exposed directly to the public internet with no login. Anyone could read every feature setting, the list of API tokens used by the platform, the country list used for compliance checks, and the internal IDs of privileged staff and enterprise users. Worse, by sending one of those leaked staff IDs back to the system, an outsider could turn on hidden features and even flip the platform's payment routing from the real network to a test network, all without any account.
The Vulnerability
The business portal relied on a feature toggle service for delivering toggle state to the front end. Internal "admin" endpoints on that service, intended for debugging and monitoring, were bound to the public-facing network interface without authentication, IP restriction, or network segmentation.
All admin endpoints returned HTTP 200 with no API key, session, or token required. A separate token validation endpoint was similarly unrestricted and unrate-limited.
The Attack
Configuration and Token Inventory
A single unauthenticated request to the features endpoint returned 116 feature flags spanning 5 projects, complete with strategies, constraints, and segments. This bypassed the project-scoped token model the feature flag platform normally enforces. The token inventory endpoint returned partial values, types, environments, and project scopes for production tokens, including a wildcard production client token covering every project.
Privileged User Identity Leakage
Segment definitions inside the features dump revealed 23 privileged user ID hashes in one segment, 3 enterprise SSO user IDs in another, and organization IDs in three more. These are the identities the platform uses for internal access gating.
Hidden Feature Unlocking
A baseline call to the public flag-evaluation endpoint, with no user ID, returned an empty list when grepped for SSO toggles. Repeating the same call with one of the leaked enterprise user IDs as the userId parameter turned the SSO feature on, along with related staff documentation features, all visible to an unauthenticated attacker.
Payment Network Manipulation
The same primitive flipped the payment-network variant. With no user ID, the variant resolved to the production network. With a privileged segment user ID supplied, the variant resolved to a public testnet, indicating downstream payment routing logic could be steered onto a different chain entirely depending on perceived identity.
Compliance Logic Disclosure
The exposed segments also leaked the exact country list used to trigger KYC and KYB verification flows, a set of values that should never be visible outside the compliance team.
Token Validation Oracle
A separate validation endpoint accepted candidate tokens and returned 1 for valid, 0 for invalid, with no authentication and no rate limiting. Combined with the partial token inventory, this oracle dramatically lowered the cost of confirming any guessed or leaked token.
The Impact
- Cross-project access to 116 production feature flags, bypassing the platform's project-scoped token model.
- Production token inventory disclosed, including a wildcard client token covering all projects.
- 23 privileged staff IDs and 3 enterprise SSO IDs leaked, each usable as an input to flip the platform's behaviour.
- Compliance country list disclosed, undermining geographic controls on a regulated platform.
- Hidden features (enterprise SSO, internal documentation views) unlockable without an account.
- Payment network selection flippable to a testnet using a leaked privileged ID, with unknown but potentially severe downstream effects on the portal's payment flows.
- Unauthenticated, unrate-limited token validation oracle increasing the risk of brute-force or partial-token compromise.
- Identical exposure on the staging counterpart, confirming a deployment pattern rather than a one-off mistake.
Remediation
- Block public access to all internal admin endpoints. Use a reverse proxy, WAF rule, or network policy to restrict them to internal networks only.
- Restrict the token validation endpoint to internal callers, or add authentication plus rate limiting.
- Rotate every exposed token, with priority given to the wildcard production client token.
- Apply the same fixes to staging. Identical exposure was present there.
- Audit any internet-facing service that ships with administrative or debug endpoints enabled by default, and confirm those endpoints are bound only to trusted interfaces.