Deserialization of untrusted data in Microsoft Planetary Computer Pro

CVE-2026-41104 is a CWE-502 deserialization flaw in Microsoft Planetary Computer Pro, specifically the Azure-hosted GeoCatalog service. The public records describe it as an *exclusively hosted service*, not a customer-managed server package, so there is no normal host-side version range to sweep for; the affected population is tenants that explicitly deployed Planetary Computer Pro GeoCatalog resources in Azure.

Microsoft scored it 10.0 CRITICAL, but that label does not survive contact with real-world operations. The product is niche, preview-limited, tenant-scoped, and Microsoft-owned on the patch side; meanwhile NVD's enrichment reframed impact as 7.5 HIGH confidentiality-only, and public telemetry shows no KEV listing, no public exploitation, and no public PoC. For an enterprise patch queue, this is not a fleet emergency; it is a low-priority SaaS exposure review.

Why this verdict

• Vendor 10.0 is inflated for patch operations because the public description says *information disclosure* while NVD's later enrichment cut it to confidentiality-only 7.5 HIGH.
• Attack position is narrower than the CVSS suggests: the attacker needs a live, tenant-specific GeoCatalog deployment in a specialized Azure service. That implies a small exposed population, not a ubiquitous edge footprint.
• Modern controls add real friction: Microsoft documentation centers the service on Microsoft Entra ID, RBAC, and explicit GeoCatalog deployment. Even if PR:N is technically true for one endpoint, most real deployments are still identity- and tenant-bounded.
• There is no public exploitation heat: no KEV entry, no public PoC, and a very low user-supplied EPSS 0.0031 all push down urgency.
• Blast radius is product-scoped: compromise would threaten a Planetary Computer Pro tenant and its data, not hand an attacker instant control of your workstation/server estate.
• Customer remediation leverage is limited: because this is an exclusively hosted service, defenders cannot roll a package upgrade across endpoints, which makes this primarily a SaaS assurance and exposure-management item.

Why not higher?

To justify HIGH or CRITICAL here, you would want one of three things: active exploitation, broad deployment, or demonstrated pre-auth tenant-compromise mechanics with clear enterprise-scale blast radius. We have none of those in public evidence. The product is niche, service-hosted, and documented as an Azure resource with Entra-backed access controls, so each prerequisite compounds downward pressure on severity.

Why not lower?

It should not be IGNORE because organizations that actually use Planetary Computer Pro may still have sensitive geospatial data in scope, and the flaw is still remotely reachable in a hosted service. You also need to verify whether Microsoft has remediated the backend and whether your tenant exposure, RBAC assignments, and data sensitivity justify local containment steps.

1. Inventory GeoCatalog usage — Identify whether any subscriptions actually run Microsoft.Orbital/geoCatalogs. Do this now as backlog hygiene for a LOW verdict, because if you do not use the service this drops out of scope immediately.
2. Review GeoCatalog RBAC — Reduce standing access to GeoCatalog Administrator, Owner, and related roles; keep only named identities and applications that genuinely need access. For a LOW verdict there is no mitigation SLA, so treat this as backlog hygiene rather than emergency change control.
3. Constrain app identities — Audit service principals and managed identities permitted to call Planetary Computer Pro, and remove stale or over-broad delegated access. This matters because even when the CVE is pre-auth in theory, real abuse often becomes easier in tenants with sloppy identity sprawl; again, LOW means backlog hygiene.
4. Ask Microsoft for remediation status — Because this is an exclusively hosted service with no customer-visible patched version, confirm through Microsoft support/account channels whether backend remediation is complete for your tenant and whether any post-incident steps are recommended. This is the closest thing to remediation you actually control.
5. Monitor for unusual catalog access — Enable and retain service, identity, and Azure activity logs around GeoCatalog access, then baseline query/read behavior so abnormal dataset enumeration or bulk reads stand out. For LOW, schedule it as normal control hardening rather than emergency containment.

Run this from an auditor workstation or CI runner that has the Azure CLI installed and authenticated with at least Reader access across the subscriptions you want to inspect. Invoke it as ./check_cve_2026_41104.sh or ./check_cve_2026_41104.sh <subscription-id>; no target-host access is needed because this CVE is an *exclusively hosted service* and patch state is not visible from the endpoint.

#!/usr/bin/env bash
# check_cve_2026_41104.sh
# Purpose: Determine whether the current Azure scope uses Microsoft Planetary Computer Pro GeoCatalog.
# Because CVE-2026-41104 is an exclusively hosted service, customer-visible patch state is opaque.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=ERROR

set -euo pipefail

SUBSCRIPTION_OVERRIDE="${1:-}"
FOUND=0
ERRORS=0

if ! command -v az >/dev/null 2>&1; then
  echo "UNKNOWN - Azure CLI ('az') not installed"
  exit 2
fi

if ! az account show >/dev/null 2>&1; then
  echo "UNKNOWN - Azure CLI not authenticated; run 'az login' first"
  exit 2
fi

check_one_subscription() {
  local sub_id="$1"
  local sub_name="$2"

  if ! az account set --subscription "$sub_id" >/dev/null 2>&1; then
    echo "# Failed to select subscription: $sub_name ($sub_id)" >&2
    ERRORS=$((ERRORS+1))
    return
  fi

  local rows
  if ! rows=$(az resource list \
      --resource-type "Microsoft.Orbital/geoCatalogs" \
      --query "[].{name:name,resourceGroup:resourceGroup,location:location,id:id}" \
      -o tsv 2>/dev/null); then
    echo "# Failed to enumerate GeoCatalog resources in: $sub_name ($sub_id)" >&2
    ERRORS=$((ERRORS+1))
    return
  fi

  if [[ -n "${rows}" ]]; then
    FOUND=1
    echo "# Planetary Computer Pro GeoCatalog resources found in subscription: $sub_name ($sub_id)" >&2
    while IFS=$'\t' read -r name rg location id; do
      [[ -z "${name:-}" ]] && continue
      echo "#   name=$name rg=$rg location=$location id=$id" >&2
    done <<< "$rows"
  fi
}

if [[ -n "$SUBSCRIPTION_OVERRIDE" ]]; then
  sub_name=$(az account show --subscription "$SUBSCRIPTION_OVERRIDE" --query name -o tsv 2>/dev/null || echo "$SUBSCRIPTION_OVERRIDE")
  check_one_subscription "$SUBSCRIPTION_OVERRIDE" "$sub_name"
else
  while IFS=$'\t' read -r sub_id sub_name; do
    [[ -z "${sub_id:-}" ]] && continue
    check_one_subscription "$sub_id" "$sub_name"
  done < <(az account list --all --query "[?state=='Enabled'].[id,name]" -o tsv)
fi

if [[ $FOUND -eq 1 ]]; then
  echo "UNKNOWN - GeoCatalog resources exist, but CVE-2026-41104 is a Microsoft-hosted service with no customer-visible patch/version signal. Verify remediation status with Microsoft and review tenant RBAC/logging."
  exit 2
fi

if [[ $ERRORS -gt 0 ]]; then
  echo "UNKNOWN - No GeoCatalog resources found in checked scope, but one or more subscriptions could not be evaluated"
  exit 2
fi

echo "PATCHED - No Microsoft Planetary Computer Pro GeoCatalog resources found in the evaluated Azure scope; CVE-2026-41104 is not applicable here"
exit 0

Sources

1. Microsoft Security Response Center advisory
2. NVD CVE-2026-41104 detail
3. Microsoft Learn: Planetary Computer Pro overview
4. Microsoft Learn: Deploy a GeoCatalog resource
5. Microsoft Learn: Configure application authentication
6. Microsoft Learn: Manage access for Planetary Computer Pro
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS API documentation