A critical security flaw in Azure API Management’s Developer Portal allows attackers to register accounts on any APIM instance configured with Basic Authentication, regardless of whether administrators have disabled user signup through the Azure Portal interface.
The vulnerability enables cross-tenant account creation, potentially granting unauthorized access to API documentation, subscription keys, and other sensitive resources exposed via the Developer Portal.
Tracked under GitHub Security Advisory GHSA-vcwf-73jp-r7mv, the vulnerability stems from a fundamental disconnect between UI-level signup restrictions and the underlying API infrastructure.
While administrators can hide the signup form through portal settings, the backend signup API endpoint remains fully active and accessible, accepting registration requests directly without validating tenant boundaries.
Technical Attack Vector
The exploit requires two key components: an attacker-controlled APIM instance with signup enabled and a target APIM instance with signup “disabled” in the UI but Basic Authentication still configured. The attack manipulates HTTP request headers to bypass administrative controls.
The attacker intercepts a legitimate signup request from their own APIM portal using tools like Burp Suite and modifies the Host header to point to the target instance.
The /signup endpoint processes requests based solely on the Host header without validating tenant boundaries, allowing the malicious request to complete successfully.
The attacker gains full portal access despite the target administrator believing signup restrictions were enforced.
A critical technical detail: the POST request to the signup endpoint accepts a JSON payload containing user credentials and challenge data.
By simply changing the Host header from the attacker’s instance to the target’s URL, the endpoint treats the request as legitimate and creates the account on the victim’s system.
Two architectural issues combine to create this bypass. First, disabling signup only hides the form in the portal user interface the backend API remains active and unaffected. Second, the signup API lacks tenant validation logic.
Requests are processed based on the Host header without confirming the request originates from the same tenant’s portal.
Microsoft’s MSRC treated this design as intentional. However, security researchers argue that hiding administrative controls in the UI while maintaining active backend APIs creates a false sense of security.
Organizations believe they have restricted signup access when they have only removed the visible interface.
Organizations face vulnerability if their APIM instances have the Developer Portal enabled, use Basic Authentication identity provider, and have disabled signup visibility through the Azure Portal.
Non-Consumption tier APIM instances (Developer, Basic, Standard, Premium) are particularly vulnerable. The Consumption tier has limited portal features and reduced exposure.
Conversely, instances relying solely on Azure AD or OAuth authentication, or those with the Developer Portal completely disabled, remain protected. Simply removing the signup form from the UI provides zero protection.
Microsoft provides no official patch. Organizations should immediately remove the Basic Authentication identity provider entirely from APIM instances.
Audit all existing Developer Portal user accounts for unauthorized signups, particularly checking for API-based registrations. Implement Azure AD authentication as the sole identity provider to enforce proper tenant boundaries.
Security researchers released open-source tools including a Python verification script and a Nuclei scanning template.
Organizations can audit their own instances using Azure Resource Graph queries to identify APIM resources with the vulnerable configuration combination: enabled Developer Portal, non-Consumption SKU, active Basic Authentication provider, and disabled signup visibility.
The vulnerability was discovered September 30, 2025, and initially reported to Microsoft Security Response Center. Microsoft closed the first report as “not a vulnerability” on October 30.
After resubmission with additional technical details, MSRC closed the case as “by design” on November 20. Public disclosure occurred November 26, with a CVE request submitted November 27.
Organizations should prioritize audit and remediation given Microsoft’s unwillingness to treat this as a security issue despite clear cross-tenant implications and bypassed administrative controls.
Find this Story Interesting! Follow us on Google News, LinkedIn and X to Get More Instant Updates
%20(1).webp?fit=1600,900&ssl=1&description=The vulnerability enables cross-tenant account creation, potentially granting unauthorized access to API documentation, subscription keys){kind=link}