
PostgreSQL Exposure Across the EU: A Snapshot from Shodan Data
March 06, 2026
PostgreSQL is widely respected as one of the most robust open source database engines in production today. It powers enterprise applications, fintech platforms, SaaS products, government systems, and cloud-native architectures.
It is not designed to be publicly exposed by default.
Yet Shodan visibility shows a substantial number of PostgreSQL services reachable directly from the internet across the European Union.
This is not a vulnerability scan. It is a visibility snapshot of what is responding on port 5432.
Methodology
Scope: 27 European Union member states
AT, BE, BG, HR, CY, CZ, DK, EE, FI, FR, DE, GR, HU, IE, IT, LV, LT, LU, MT, NL, PL, PT, RO, SK, SI, ES, SE
Query focus:
- Services responding as PostgreSQL on port 5432.
The results below are based entirely on Shodan indexed data at the time of collection. Not every service running on port 5432 is guaranteed to be PostgreSQL. However, fingerprinting indicates that the overwhelming majority are genuine PostgreSQL deployments.
Total PostgreSQL Exposure in the EU
Total exposed PostgreSQL services: 185,649
That is nearly two hundred thousand database servers directly reachable from the public internet within the EU alone. For a database engine that is typically intended to sit behind an application layer, that is a meaningful surface area.
| Country | Instances |
|---|---|
| Germany (DE) | 74,128 |
| Poland (PL) | 31,822 |
| Netherlands (NL) | 20,875 |
| France (FR) | 19,834 |
| Finland (FI) | 11,171 |
| Belgium (BE) | 4,748 |
| Spain (ES) | 3,338 |
| Ireland (IE) | 3,293 |
| Sweden (SE) | 3,148 |
| Italy (IT) | 3,138 |
| Czechia (CZ) | 1,461 |
| Romania (RO) | 1,415 |
| Bulgaria (BG) | 1,161 |
| Austria (AT) | 818 |
| Hungary (HU) | 764 |
| Denmark (DK) | 682 |
| Portugal (PT) | 556 |
| Slovenia (SI) | 531 |
| Slovakia (SK) | 519 |
| Lithuania (LT) | 472 |
| Greece (GR) | 446 |
| Latvia (LV) | 433 |
| Estonia (EE) | 376 |
| Croatia (HR) | 340 |
| Luxembourg (LU) | 112 |
| Cyprus (CY) | 57 |
| Malta (MT) | 11 |
Germany represents roughly 40 percent of all EU PostgreSQL exposure. Poland ranks second, which is notable compared to its MySQL footprint.
Product Breakdown
| Product | Instances |
|---|---|
| PostgreSQL | 185,569 |
| AWS Redshift | 9 |
The dataset is overwhelmingly composed of standard PostgreSQL instances. A small number fingerprint as AWS Redshift clusters. Even managed cloud databases require strict access controls. Public reachability without tight IP restrictions still increases risk.
Is Public PostgreSQL Exposure a Security Problem?
In most modern architectures, yes. PostgreSQL is typically intended to be:
- Inside a private subnet
- Behind an application server
- Restricted to internal services
- Accessible only via VPN or controlled IP ranges
Direct exposure on port 5432 creates an authentication surface that can be:
- Probed for version information
- Targeted with credential stuffing
- Subjected to brute force attempts
- Assessed for known CVEs
- Tested for misconfigured authentication rules
Exposure does not automatically mean compromise. But it does dramatically increase the number of entities that can interact with your database.
From a Pentester Perspective
When we discover an internet exposed PostgreSQL instance during an assessment, it immediately becomes a priority target. We evaluate:
- Can we connect directly from the internet?
- Is TLS enforced?
- What authentication method is configured?
- Are weak passwords accepted?
- Is there rate limiting?
- Is the version supported and patched?
If we can reach the login interface and attempt authentication without IP restriction or throttling, this is typically classified as a High finding. If weak credentials are discovered, trust authentication is misconfigured, or superuser access is exposed remotely, it becomes Critical.
Databases frequently contain the most sensitive data in an organization. Compromise impact is rarely low.
PostgreSQL Hardening Checklist
1. Restrict Network Access First
- Bind PostgreSQL to a specific internal interface
- Avoid listening on 0.0.0.0 unless required
- Allow inbound 5432 only from specific IP addresses
- Place the database inside a private subnet
2. Harden pg_hba.conf
- No trust authentication for remote hosts
- No broad CIDR rules such as 0.0.0.0/0
- Restrict connections to known IP ranges
- Use scram-sha-256 instead of md5
3. Enforce Strong Authentication
- Use long, unique passwords
- Remove unused roles
- Avoid shared credentials
- Limit login roles strictly
4. Require TLS
- Enable SSL and use valid certificates
- Require encrypted client connections
- Disable plaintext access
5. Remove Remote Superuser Access
- The postgres superuser account should not be accessible from the internet
- Restrict to administrative networks only
6. Apply Least Privilege Everywhere
- Separate read-only and read-write roles
- Avoid granting SUPERUSER, CREATEDB, or CREATEROLE unnecessarily
7. Keep PostgreSQL Updated
- Run supported major versions
- Apply security updates promptly
8. Monitor and Log
- Monitor failed authentication attempts
- Watch for privilege escalation events
9. Add Brute Force Protection
- Implement firewall rate limiting
- Network intrusion prevention
Part of the EU Exposure Series
Explore our other research on protocol exposure across the 27 EU member states:
Final Thoughts
185,649 publicly reachable PostgreSQL services across the EU represents a meaningful attack surface. PostgreSQL is mature and capable of strong security, but direct exposure combined with weak authentication creates a high-value target. Visibility tells us what is reachable; segmentation, authentication, and monitoring determine whether it is defensible.
