PostgreSQL and CVE-2018-1058: why search_path is still an underestimated risk

> TL;DR: CVE-2018-1058 was not a classic SQL injection but a search_path and schema trust problem. Here is why this PostgreSQL flaw is still highly...

A flaw very different from classic injection cases

CVE-2018-1058 remains one of the most instructive PostgreSQL security cases because it does not match the usual story of a database compromised through one obvious injectable query. PostgreSQL explains officially that the issue involved search_path handling and the ability for one user to create same-named objects that could influence how other users queries behave.

Why this matters

This case is useful because it shows that database security is not only about encryption, backups, or SQL injection. Schema layout, object resolution, and privilege boundaries are also part of the attack surface.

The official PostgreSQL guide explicitly describes this as a trojan-horse style issue. That is what makes it so valuable: a default behavior that is reasonable in some contexts becomes dangerous in multi-user environments.

What teams often forget

Many teams see PostgreSQL as safe once the connection is secured and the network is restricted. But trust also exists inside the database: who can create objects in public, what search_path is applied, and which objects resolve first.

The 2026 lesson

PostgreSQL officially recommends steps such as revoking CREATE on schema public from PUBLIC and reviewing search_path configuration. That is a very practical reminder: database security is not finished just because port 5432 is not open to the world.

Our view

If you want a representative database security flaw, CVE-2018-1058 is excellent because it is about internal trust and privilege modeling. It is not spectacular in a marketing sense. It is better than that: it teaches something durable about how a database can be used against its own users.

Key Takeaways