CVE-2026-73298: Microsoft Container Migration IDOR Flaw

CVE-2026-73298 Overview

CVE-2026-73298 is an authenticated Insecure Direct Object Reference (IDOR) vulnerability in the Microsoft Container Migration Solution Accelerator, a multi-service, AI-driven application for migrating container service configurations to Azure Kubernetes Service (AKS). The flaw affects version 2.1.2 and earlier. Multiple API endpoints in the process and file management components fail to enforce ownership checks. Authenticated users can read, modify, and delete migration processes and files belonging to other authenticated users within the same organization. Although the application relies on Microsoft Entra ID for authentication, it does not apply per-object authorization between users. The vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact
Any authenticated user of the Container Migration Solution Accelerator can access, modify, or delete other users' migration processes and associated files, resulting in unauthorized disclosure, tampering, and destruction of migration data across the organization.

Affected Products

Microsoft Container Migration Solution Accelerator version 2.1.2 and earlier
Process management API endpoints in the accelerator
File management API endpoints in the accelerator

Discovery Timeline

2026-08-12 - CVE-2026-73298 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-73298

Vulnerability Analysis

The Container Migration Solution Accelerator exposes REST APIs that operate on process objects and file objects tied to a specific user's migration workflow. These endpoints accept object identifiers supplied by the client. The server authenticates the caller using Entra ID but does not verify that the caller owns the referenced object.

As a result, an authenticated user can substitute another user's object identifier in a request and have the server perform the operation without objection. This affects read, write, and delete operations across both the process and file APIs. The impact scales with the number of users sharing the deployment, since any authenticated tenant member can tamper with the migration state of any other member.

Because migration workflows can carry cluster manifests, configuration secrets, and target AKS parameters, unauthorized modification can also alter the outcome of subsequent migrations.

Root Cause

The root cause is missing authorization enforcement between the authenticated principal and the requested object. The application treats successful Entra ID authentication as sufficient for API access. It does not perform an ownership or role check against the object identifier passed by the caller. This is a canonical [CWE-639] pattern.

Attack Vector

Exploitation requires network access to the accelerator's API and a valid Entra ID account with permission to sign in to the application. The attacker enumerates or discovers object identifiers belonging to other users, then issues standard API calls substituting those identifiers to read, modify, or delete the target objects. No privileged role or user interaction is required.

No public proof-of-concept exploit is listed in the enriched data, and the vulnerability is not present in the CISA Known Exploited Vulnerabilities catalog. Refer to the GitHub Security Advisory GHSA-27mc-pccp-3x2x for vendor technical details.

Detection Methods for CVE-2026-73298

Indicators of Compromise

API request logs where the authenticated Entra ID principal does not match the owner recorded on the process or file object being accessed.
Unexpected DELETE or PUT/PATCH operations on process or file identifiers that a given user did not create.
Spikes in enumeration-style requests iterating sequential or guessable object identifiers on the accelerator's process and file endpoints.

Detection Strategies

Instrument the accelerator's API gateway or reverse proxy to log the caller's Entra ID object ID alongside the target resource ID for every process and file endpoint call, then alert on mismatches.
Correlate migration-object audit records with application-tier authentication events to identify cross-user access patterns.
Baseline normal per-user access volumes on the process and file APIs and flag deviations that suggest object-ID sweeping.

Monitoring Recommendations

Enable verbose logging on all process and file management endpoints, capturing HTTP method, resource identifier, and caller identity.
Forward accelerator logs and Entra ID sign-in logs to a centralized analytics platform for cross-referencing.
Monitor storage backends (for example, Azure Blob Storage containers or database tables used by the accelerator) for delete and overwrite events that do not correspond to the object owner.

How to Mitigate CVE-2026-73298

Immediate Actions Required

Upgrade the Container Migration Solution Accelerator to a version later than 2.1.2 that includes the ownership-check fix referenced in the vendor advisory.
Restrict access to the accelerator to a minimal set of trusted Entra ID users until the patched version is deployed.
Review audit logs for prior cross-user access to process or file objects and notify affected users of any data exposure.

Patch Information

Microsoft has published fix guidance in the GitHub Security Advisory GHSA-27mc-pccp-3x2x for the Container Migration Solution Accelerator repository. Deploy the updated release from the official repository and redeploy any running instances. Rotate any credentials or configuration values that may have been exposed through unauthorized read access.

Workarounds

Deploy separate instances of the accelerator per user or per team so that no two principals share a data plane, eliminating cross-user object access.
Place an authorization proxy in front of the accelerator's APIs that validates the caller's Entra ID identity against an external ownership map before forwarding requests.
Temporarily disable the process and file management endpoints for non-administrative users through network-level access controls until the patch is applied.

bash

# Configuration example: restrict accelerator API access to a named Entra ID group
# using an Azure API Management inbound policy (illustrative)
<inbound>
  <validate-jwt header-name="Authorization" require-scheme="Bearer">
    <openid-config url="https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration" />
    <required-claims>
      <claim name="groups" match="any">
        <value>CMSA-Authorized-Users</value>
      </claim>
    </required-claims>
  </validate-jwt>
</inbound>