Azure CLI logic for PostgreSQL Server networking defaults causes overlapping CIDRs and outages

[sophiewangtech]

Issue Type

Bug Report

Description

Issue:
customer ran the az cli command to create a postgres server. He found that the 10.0.0.0/16 address space was automatically added to the vnet. Because there is already another vnet that has this address space, it caused the networking conflict and resulted in network outage and production down. The issue can be reproduced at will.

Analysis:

• Checked the document az postgres flexible-server | Microsoft Learn . It appears that 10.0.0.0/16 is the default value to use.
  --address-prefixes
  The IP address prefix to use when creating a new virtual network in CIDR format. Default value is 10.0.0.0/16.

--subnet-prefixes
The subnet IP address prefix to use when creating a new subnet in CIDR format. Default value is 10.0.0.0/24.

• After multiple tests, it seems by-design behavior that "when you pass only --vnet and --subnet names without giving the "--address-prefixes" and " and "--subnet-prefixes", the CLI will verify the existence of the vnet and subnet. If it finds the subnet does not exist, it will automatically add a default VNet address space (10.0.0.0/16). Then it will show the prompt "Do you want to create a new subnet". Even if customer choose to not create the subnet, the address space (10.0.0.0/16) has already been added and there is no way customer can deny the action.

• Share with customer the two options to avoid such issue.
  Option 1: Add the address-prefix and subnet-prefix you want to use so that the default value won't be used.
  --address-prefixes 172.0.0.0/16
  --subnet-prefixes 172.0.0.0/24 \

Option 2: before running the az cli command to create the postgres server, make sure both vnet and subnet already exist with the proper prefixes you want to use.

• However, customer has huge concerns about the az cli tool. The customer experienced a critical production outage when the Azure CLI automatically injected a 10.0.0.0/16 address block into their live VNet. This occurred solely due to a non-existing subnet parameter, yet the CLI proceeded to modify the VNet’s core address space without any warning or interactive confirmation. The customer contends that it is fundamentally unreasonable for a production-level tool to trigger such a significant infrastructure change. This silent, unprompted automation caused severe IP conflicts that instantly disrupted domestic business operations.

Here are the requested changes we'd like the az cli product group team to help with.
Requested changes
1. Safety guardrails
○ If subnet doesn’t exist and --address-prefixes/--subnet-prefixes are not provided, fail fast with a clear error instead of injecting 10.0.0.0/16.
2. Stronger warnings and UX prompts
○ Emit a high-severity warning when adding any address space to a VNet, stating the exact CIDRs and the risk of overlap.
○ Add a confirmation prompt that shows current VNet address spaces and asks the user to proceed only if overlap has been checked.

Command or Script

xxx [ ~ ]$ az postgres flexible-server create \
      --resource-group 1227lab \
      --name postgrestest1227test1 \
      --location "eastasia" \
      --admin-user testuser \
      --admin-password "xxxx123456!" \
      --sku-name standard_d4ds_v4 \
      --tier GeneralPurpose \
      --version 16 \
      --vnet vnet1227 \
      --subnet subnet1227test1 \
      --storage-size 32767
Update default value of "--version" in next breaking change release(2.80.0) scheduled for Nov 2025. The default value will be changed from "17" to a supported version based on regional capabilities.
Checking the existence of the resource group '1227lab'...
Resource group '1227lab' exists ? : True 
You have supplied a Vnet and Subnet name. Verifying its existence...
Using existing Vnet "vnet1227" in resource group "1227lab"
The address prefix does not exist in the Vnet. Adding address prefix 10.0.0.0/16 to Vnet vnet1227.
Do you want to create a new Subnet subnet1227test1 in resource group 1227lab (y/n): n
Operation cancelled.

Expected Behavior

When az cli detects the specified subnet does not exist and attempts to add "10.0.0.0/16" to the vnet, it needs to emit a high-severity warning when adding any address space to a VNet, stating the exact CIDRs and the risk of overlap.

Actual Behavior

when az cli detects the specified subnet does not exist, it automatically add a default VNet address space (10.0.0.0/16) and then show the prompt "Do you want to create a new subnet". Even if customer choose to not create the subnet, the address space (10.0.0.0/16) has already been added and there is no way customer can deny the action.

Environment

Cloud shell
"azure-cli": "2.79.0"

Additional Context

No response

[azure-client-tools-bot-prd]

Hi @sophiewangtech,

2.79.0 is not the latest Azure CLI(2.81.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @gbowerman, @jasomaning, @nachoalonsoportillo.

[2012952877]

Thank you for opening this issue, we will look into it.

Dear expert, thank you for the response.

This behavior is extremely risky in production environments, as it allows a simple input mistake to silently modify an existing VNet’s address space and cause immediate CIDR conflicts and outages.

The issue is reproducible, affects PostgreSQL and MySQL Flexible Server.

Please prioritizing this with proper guardrails (fail-fast or explicit confirmation) to prevent unintended VNet mutations.