Azure API Management has a toggle labeled "disable developer signup." An administrator clicks it, sees the signup button disappear from their Developer Portal, and moves on. The portal is locked down. Except it isn't.
Praetorian published research on March 24 showing that the toggle is cosmetic. The underlying REST API endpoint at /signup remains active and continues accepting registration requests from anyone on the internet, regardless of what the UI displays. An anonymous attacker can create an account, subscribe to API products, obtain valid API keys, and call backend services. No credentials, no prior access, no Azure subscription in the target tenant.
The scale of exposure is staggering. Praetorian found 25,379 unique Azure APIM Developer Portals on Shodan. Based on heuristic analysis, 97.9% of them still accept signup requests. Only 51 instances out of 25,379 have actually removed the vulnerable Basic Authentication provider.
How the Attack Works
The vulnerability is not a single bug. It is three design decisions that combine into one kill chain.
The UI toggle is cosmetic. When an administrator sets the signup enabled flag to false, the Developer Portal reads this flag and hides the signup form. The REST API endpoint at /signup stays live. The toggle controls the frontend. The backend ignores it.
No tenant validation on the signup endpoint. Azure APIM Developer Portals are multi-tenant. The infrastructure routes requests based on the Host header. When an attacker sends a POST /signup with the victim's portal hostname, the infrastructure routes it to the victim's instance. There is no check that the request came from that tenant's portal, that the sender belongs to the target organization, or that the request originated from the correct domain.
The CAPTCHA service is shared across all tenants globally. The signup flow includes a CAPTCHA challenge. But the validation service is global to Azure APIM. A CAPTCHA challenge generated on Instance A is accepted as valid when submitted to Instance B. An attacker solves the CAPTCHA on their own portal and replays the solution against the target.
The full attack chain takes five steps: identify the target portal on Shodan, confirm the /signup endpoint is still active with a probe request, create an account using a cross-tenant CAPTCHA replay, self-subscribe to an auto-approved API product, and call backend APIs with a valid subscription key.
The built-in "Starter" product that ships with every new APIM instance has auto-approve enabled by default. An attacker who creates an account can immediately subscribe and receive a valid API key without administrator involvement.
Microsoft's Response: "By Design"
This is where the story goes from technical to structural.
Security researcher Mihalis Haatainen at Bountyy Oy first reported this to Microsoft's Security Response Center (MSRC) in September 2025. After two submissions with additional technical details, MSRC issued its final determination: "By design."
No CVE. No security advisory. No automated patch. No notification to affected customers.
Four months after public disclosure, the data shows almost nobody has remediated. The reason is straightforward: because MSRC classified it as intentional behavior, there was no advisory to drive awareness and no patch to drive upgrades. Organizations using the "disable signup" toggle as their primary control don't know it doesn't work.
What This Exposes About Cloud Security
The Azure APIM flaw is a case study in a category of vulnerability that is growing more common and harder to detect: the gap between administrative intent and system enforcement.
An administrator makes a security decision using the tools their cloud provider gives them. They flip a toggle, check a box, apply a policy. The UI confirms the change. Everything looks correct. But the underlying system doesn't enforce what the UI represents. The control is decorative.
This pattern is not unique to Azure APIM. It surfaces whenever cloud platforms build management interfaces that control the visual layer but leave the API layer unconstrained. And it creates a particularly dangerous form of false confidence, because the administrator did the right thing. They followed the documented procedure. They checked their work. And they have no reason to believe the system isn't enforcing their decision.
Traditional security tooling doesn't catch this either. Vulnerability scanners test for known CVEs. Configuration auditors check against vendor-documented best practices. If the vendor says "by design," it doesn't appear in any compliance check. SAST and DAST tools test application code, not the behavior of the cloud platform's own management APIs.
The only way to find this class of issue is to test what the system actually does, not what it says it does. Does the /signup endpoint respond after "disabling" it? Does the CAPTCHA validate cross-tenant? Does the Starter product auto-approve subscriptions? These are questions about application architecture and trust boundaries, not about patches or configurations.
Praetorian's Simulated Attack
Praetorian demonstrated the full chain against a controlled APIM instance they own, configured with a mock healthcare IoT API behind the default Starter product.
The results: from anonymous internet access to patient health records (synthetic test data) and IoT device authentication tokens. Five steps, zero credentials, zero prior relationship to the target organization.
They reproduced the cross-tenant CAPTCHA replay by generating and solving a CAPTCHA on a separate APIM instance under their control, then submitting the solution against the target instance. The infrastructure accepted it without question.
What You Need to Do
Because MSRC has classified this as "by design," no patch is coming. If you run Azure APIM, you need to take manual action.
Delete the Basic Authentication identity provider entirely. This is the only remediation that fully eliminates the attack surface. Removing the Basic Auth provider deactivates the /signup endpoint. The toggle alone is not enough.
Switch to Azure AD (Entra ID) as the sole identity provider. Azure AD authentication ties account creation to your organization's directory. Cross-tenant signups become impossible because users must authenticate through your tenant's identity system.
Set approvalRequired to true on every product. Even if you can't immediately remove Basic Auth, requiring admin approval for all subscriptions prevents attackers from self-subscribing and obtaining API keys.
Audit existing developer portal accounts. Look for accounts created after you "disabled" signup. Check for accounts using external email domains or created via the Basic identity provider. Remove unauthorized accounts and revoke their subscription keys.
The Bigger Question
25,379 Developer Portals. 97.9% still exploitable. Four months after disclosure. No patch coming.
This is what happens when a platform vendor decides that a security gap is intentional. The vulnerability persists not because it's hard to fix, but because the official position is that there's nothing to fix.
For security teams, the lesson is uncomfortable but necessary: your cloud provider's management console is not your security boundary. The UI is a convenience layer. The API is the truth. If you're not testing what the API actually enforces, you're relying on assumptions that may look exactly like the Azure APIM toggle: confident, professional, and completely decorative.
The 51 organizations that removed the Basic Auth provider are the ones who tested the actual behavior rather than trusting the interface. The other 25,328 are still exposed.
Your admin console is not your security posture. Test the API.