CVE-2025-66390: Azure API Management Cross‑Tenant Signup Bypass — What It Means for Your Business and How to Respond

Introduction

If your organization uses Microsoft Azure API Management (APIM) with its Developer Portal, CVE-2025-66390 demands immediate attention from business leaders and risk owners. This vulnerability allows an attacker to create user accounts in your APIM tenant even when you have disabled self-service signup in the portal interface. The risk is not theoretical; it undermines the access controls you rely on to keep your API ecosystem closed to unauthorized users. This post explains why this CVE matters to your business, who is at risk, what operational and compliance exposures it creates, and how to respond decisively. You will learn how to determine whether you are affected, what real-world incidents could look like in your industry, and which actions to take now to reduce risk. Technical details for security engineers are reserved for the appendix so business stakeholders can focus on impact and remediation.

S1 — Background & History

CVE-2025-66390 was published to the National Vulnerability Database (NVD) on July 21, 2026, following public disclosure of a cross-tenant signup bypass in Microsoft Azure API Management. The vulnerability affects APIM deployments through October 17, 2025, where the Developer Portal’s self-service signup using username/password Basic Authentication is enabled in any tenant. Multiple security vendors and independent researchers have assigned a CVSS base score of 9.8, indicating critical severity. In plain language, this is an improper access control flaw: the system fails to enforce signup restrictions at the backend API level, allowing account creation across tenant boundaries. The issue was reported by external researchers and tracked under CWE-284 (Improper Access Control). Microsoft has stated that the observed behavior does not cross a documented security boundary and characterizes it as a configuration or state issue rather than a product defect requiring a patch. Despite this position, the practical outcome is the same: unauthorized accounts can be created in tenants that administrators believed were closed to public registration.

S2 — What This Means for Your Business

For business leaders, CVE-2025-66390 translates into tangible operational, data, reputational, and compliance risks. Operationally, an attacker who creates an account in your APIM Developer Portal can access internal API documentation, test consoles, and potentially subscription keys or credentials tied to developer accounts. This exposure can lead to unauthorized API calls, data exfiltration, or manipulation of backend services that your APIs protect. From a data protection standpoint, any personally identifiable information (PII) or business-sensitive metadata stored or referenced in your API ecosystem becomes accessible to an unauthorized actor. Reputational damage follows quickly if customers or partners learn that your API platform allowed unauthorized access, eroding trust in your digital services. Compliance obligations are also at stake. Regulations such as GDPR, HIPAA, and sector-specific frameworks expect you to maintain effective access controls over systems processing sensitive data. A failure to prevent unauthorized account creation can be interpreted as a control deficiency, triggering audit findings, regulatory scrutiny, or breach notification requirements. In short, this vulnerability weakens the perimeter you assumed was in place and creates a pathway for attackers to establish a foothold inside your API management environment.

S3 — Real-World Examples

Regional Bank with Partner APIs: A mid-sized bank uses Azure APIM to expose account aggregation and payment initiation APIs to fintech partners. An attacker exploits CVE-2025-66390 to create a developer account despite the bank having disabled public signup. The attacker retrieves API documentation and test credentials, then uses them to probe for weak endpoints, risking exposure of customer transaction data and triggering regulatory reporting obligations.

Healthcare SaaS Provider: A healthcare software vendor hosts patient scheduling and billing APIs on APIM for clinic customers. Unauthorized account creation gives an attacker access to API keys and sandbox environments containing synthetic patient records. The incident forces the vendor to assess potential HIPAA implications, notify affected clinics, and invest in emergency access reviews and monitoring.

E-Commerce Platform Serving Retailers: A platform provider manages merchant inventory and order APIs via APIM. An attacker registers through the bypass, obtains API credentials, and begins scraping competitor pricing and order volumes from test endpoints. The platform faces customer complaints, potential contract penalties, and a rushed security remediation program to restore confidence.

Government Contractor with Internal APIs: A defense contractor uses APIM to internalize access to logistics and procurement APIs. Even with signup disabled in the portal UI, an external actor creates an account and gains visibility into API structures and test data. The contractor must initiate an internal investigation, review access logs, and coordinate with federal compliance officers to determine reportability

S4 — Am I Affected?

Use this checklist to determine whether your organization is exposed to CVE-2025-66390.

• You are running Microsoft Azure API Management with the Developer Portal enabled.
• Your APIM instance has username/password Basic Authentication configured as an identity provider for the Developer Portal.
• You rely on the portal’s UI toggle to disable self-service signup, but have not removed the Basic Authentication identity provider.
• Your APIM deployment date is on or before October 17, 2025, and you have not implemented additional network or policy-level restrictions on the signup endpoint.
• You have observed unexpected new developer accounts or registration events in audit logs despite signup appearing disabled.

If you answered yes to any of these items, you should treat your environment as potentially affected and proceed with the mitigation steps outlined below.

Key Takeaways

• CVE-2025-66390 enables unauthorized account creation in Azure API Management tenants even when self-service signup is disabled in the portal UI.
• Business impact includes exposure of API documentation, credentials, and sensitive data, along with reputational and compliance risks.
• Microsoft classifies the issue as a configuration state problem and has not issued a product patch; remediation requires configuration hardening.
• Immediate actions include removing Basic Authentication signup, enforcing federated identity providers, and auditing existing developer accounts.
• Ongoing vigilance through log monitoring and access reviews is essential to detect and prevent unauthorized registrations.

Call to Action

Do not wait for a breach to validate your API security posture. IntegSec’s penetration testing team can assess your Azure API Management deployment, identify configuration gaps like CVE-2025-66390, and deliver actionable remediation guidance tailored to your environment. Contact us today to schedule a targeted pentest and reduce your cybersecurity risk with confidence. https://integsec.com

TECHNICAL APPENDIX (security engineers, pentesters, IT professionals only)

A — Technical Analysis

CVE-2025-66390 is an improper access control vulnerability (CWE-284) in Microsoft Azure API Management’s Developer Portal self-service signup flow. The root cause is a missing server-side enforcement that ties the UI-level signup configuration to the backend registration endpoint. When Basic Authentication signup is enabled in any tenant (Tenant A), the backend /signup API endpoint remains active and processes registration requests based on the HTTP Host header or tenant identifier supplied by the client. An attacker can capture a legitimate registration request from Tenant A and replay it with a modified Host header targeting Tenant B, even if Tenant B has disabled signup in the portal UI. The attack vector is network-based (AV:N), requires no privileges (PR:N), no user interaction (UI:N), and has low complexity (AC:L), yielding a CVSS v3.1 vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and a base score of 9.8 (Critical). The NVD entry references this issue under CVE-2025-66390, with Microsoft noting the behavior as a disputed configuration/state issue rather than a product defect.

B — Detection & Verification

Use the following methods to detect and verify exposure to CVE-2025-66390 in your Azure APIM environment.

• Version and Configuration Enumeration:
•  Confirm whether Basic Authentication is enabled and whether signup is disabled only at the UI layer. 
  

• Scanner Signatures and Log Indicators:
  Look for HTTP POST requests to the /signup or equivalent registration endpoint with Host headers that do not match the tenant’s canonical hostname. Correlate Azure APIM diagnostic logs and Azure Activity Logs for NewUser or UserCreated events in tenants where signup is documented as disabled. Alert on registration events from IP addresses or user agents inconsistent with legitimate developer traffic.
• Behavioral Anomalies and Network Exploitation Indicators:
  Baseline expected registration volume per tenant and flag deviations. Inspect Application Gateway or Azure Front Door logs for cross-tenant Host header mismatches on signup and identity endpoints. Review developer group membership on a scheduled cadence to identify unauthorized accounts created via the bypass.

C — Mitigation & Remediation

Apply the following actions in sequence to mitigate CVE-2025-66390.

1. Immediate (0–24h): Disable Basic Authentication Signup
   Remove the username/password Basic Authentication identity provider entirely from every APIM instance that does not explicitly require it. S

   Simply toggling signup off in the UI is insufficient.

2. Short-term (1–7d): Enforce Federated Identity and Network Controls
   Replace Basic Authentication with Entra ID (Azure AD) or Entra ID B2C for all Developer Portal authentication. Restrict access to the Developer Portal and its API endpoints using private endpoints, IP allowlists, or Azure Front Door with WAF rules that block requests carrying non-canonical Host headers. Apply APIM inbound policies to reject requests to signup routes when the tenant is not intended to accept public registration.
3. Long-term (ongoing): Continuous Monitoring and Governance
   Forward Azure APIM diagnostic logs and Azure Activity Logs to a centralized analytics platform for continuous review. Baseline registration volume per tenant and alert on deviations. Integrate APIM audit events into your SIEM and create detection rules for cross-tenant Host header anomalies on identity endpoints. Conduct quarterly access reviews of Developer Portal accounts and validate that no Basic Authentication providers are reintroduced.

Official Vendor Position: Microsoft has not issued a product patch, stating the behavior does not cross a security boundary. Remediation therefore depends on configuration hardening as described above.

D — Best Practices

• Eliminate reliance on UI-only toggles for access control; enforce restrictions at the API and identity provider layers.
• Use federated identity providers (Entra ID/Entra ID B2C) exclusively for Developer Portal authentication to remove local credential attack surfaces.
• Implement network-level segmentation and WAF policies to validate Host headers and block cross-tenant request patterns.
• Integrate APIM audit logs into SIEM workflows with alerting on unexpected user creation events.
• Conduct regular access reviews and configuration audits to ensure Basic Authentication signup remains disabled across all tenants.