# Wiz Research discovers "ExtraReplica"— a cross-account database vulnerability in Azure PostgreSQL

Over-permissive CN regex in Azure PostgreSQL Flexible Server pg_ident.conf let Wiz forge a DigiCert cert and replicate any public-access customer database cross-tenant.

- Payout: $40,000
- Severity: critical
- Program: Azure Database for PostgreSQL
- Credited: Wiz Research
- Disclosed: 2022-04-29
- Write-up quality: 9/10
- Original: https://www.wiz.io/blog/wiz-research-discovers-extrareplica-cross-account-database-vulnerability-in-azure-postgresql
- Library page: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-wiz-research-discovers-extrareplica-cross-account-database-vulnerability-in-azure-postgresql
- Tags: domain:cloud impact:data-leak impact:internal-access kind:research platform:threat-intel sev:critical tech:azure technique:chained technique:recon technique:source-review vuln:access-control vuln:auth-bypass

**Target:** Azure Database for PostgreSQL Flexible Server (pg_ident.conf cert auth, internal subnet)
**Root cause:** pg_ident.conf CN regex `/^(.*?)\.eee03a2acfe6\.database\.azure\.com(.*)$/` ends with a wildcard, so any DigiCert-signed cert whose CN appends the instance identifier plus an attacker domain matches and maps to the replication user. Combined with a PostgreSQL privilege-escalation bug in Azure's engine modifications granting superuser/OS code execution, and shared internal subnet reachability on port 5432.
**Steps:**
1. Exploit Azure's modified PostgreSQL engine bug to escalate to superuser and run OS commands on own Flexible Server instance
2. Recon: container shares network namespace with host; eth0 10.0.0.0/23 reaches other instances on port 5432 even with deny-all firewall
3. Read pg_hba.conf/pg_ident.conf: replication user authenticates via client cert from internal subnets; CN regex ends with `(.*)`
4. Connect via SSL to a target instance to read its cert and extract the unique identifier (e.g. eee03a2acfe6)
5. Purchase DigiCert/RapidSSL cert for CN `replication.<target-id>.database.azure.com.wiz-research.com`
6. Resolve target domain, match IP to Azure public IP ranges to find region; create attacker instance in same region
7. Connect to target as replication user with forged cert and replicate/read its database
**How found:** Pattern from prior ChaosDB research: managed services giving customers a VM inside an internal cloud environment may expose internal components. Chose PostgreSQL Flexible Server for its OS-command features; after gaining code exec, netstat/recon showed shared network namespace and reachable peers on 5432, prompting review of pg_hba.conf/pg_ident.conf where the trailing `(.*)` in the CN regex stood out.
**Exploitation:** Attacker needs a Flexible Server with public access in the target's region. Escalate to OS code execution on own instance, scan internal subnet for target on 5432, obtain target's instance identifier from its SSL cert (or crt.sh for known domains), buy a DigiCert-issued cert for replication.<id>.database.azure.com.<attacker-domain>, then authenticate as replication and copy the victim database.
**Escalation:** Chained privilege escalation (superuser/OS RCE) + internal network reachability + cert CN regex bypass to convert single-tenant access into cross-tenant database replication; crt.sh enables targeting arbitrary known domains.
**Insight:** When a managed DB grants you a container, check whether it shares a network namespace with the host and can reach peer instances on the DB port despite firewall rules; then read pg_hba.conf/pg_ident.conf for cert-auth user maps and look for unanchored regex tails that let you append your own domain to a trusted CN.