Untrusted relations and WAL

Hi hackers,

I know that everybody who can do anything about vulnerabilities is busy
with the workload LLMs generate for pgsql-security these days. Still,
the list does not forbid ideas for fun, and this one has been bothering
me. There is no patch attached, and there will not be one: I understand
the problem is beyond what I can solve alone, and current AI will not
lift me to the required level either. I would be glad to hear thoughts.

Our threat model is clear and well served by the security team: "a
security vulnerability in PostgreSQL is an issue that allows a user to
gain access to privileges or data that they do not have permission to
use, or allows a user to execute arbitrary code through a PostgreSQL
process" [0]. It covers a lot: the wire protocol, SQL constructs,
database objects, ACLs, type input functions. And yet a typical exploit
is just an SQL query. Frankly, a bit boring. Let's add attack surface in
the form of new bytes!

Today, letting a friend run your $PGDATA on their machine is handing them
a Trojan horse, no weaker than an .exe or an ELF. No surprise: we have
functions, which are small programs, i.e. code, i.e. executable code,
and running somebody else's code is what security people call RCE.

Cleaning the catalog is a tractable problem. A sufficiently patched
pg_upgrade can drop every give_me_superuser() SECURITY DEFINER, recreate
extensions from local packages, throw away remaining C functions, and so
on, until the catalog is fresh. I have prototyped this far. Making
relations and WAL safe is where my imagination ends.

Why would anyone give PGDATA to a friend who does not trust its bytes?

* A managed PostgreSQL service could onboard an on-premise database
without downtime: make the cluster a physical replica, then switch
the load. Much faster than pg_dump/pg_restore, and much simpler than
setting up logical replication for an arbitrary schema.
Just a small GUC dance around shared_buffers\max_connections needed.

* Compute/storage separation systems like Neon or Aurora. Storage
processes WAL from many tenants, so attacking it with a zero-day
freshly published by our security team (there is no shortage) is
worth somebody's time. I believe, and this is worth checking, that
they confine the WAL parser in a container and hand out page images
that nothing interprets further: pages go to compute as they are.
As soon as we want to do anything interesting with pages in a place
shared by tenants (put them into Iceberg?), the page contents can
attack us. In the managed case a per-database container is also not
a perfect answer, but I do not want to describe control plane attacks
on the list.

It would be wonderful to harden every redo function: no combination of
bytes and WAL records shall... do what, exactly? What would a security
model even look like here?

This year brotli had CVE-2026-111497 [1]: decompressing a crafted
stream corrupts decoder state and can lead to code execution. I
reported exactly the same property of pglz to pgsql-security in 2019.
Back then I could not imagine a real, widely deployed general-purpose
codec having this kind of bug. The answer was that our model does not
let a user hand compressed bytes to pglz, which is true. It was fixed
later anyway, and that is good. But we have many such places: the
binary layout of jsonb can attack the jsonb code, clever
bytes can attack arrays, the TOAST machinery, tsvector, range types -
all of them are parsers of bytes an attacker chose, with no history of
security hardening because the model says they never see untrusted
input.

So the questions:

1. Is it true that we cannot, even in theory, state a security model in
which WAL and relations are untrusted? Or is there a clever way to
draw a comprehensible boundary there?

2. Alternatively, could a large hardening project over everything we
read from disk make sense? Although it seems we already have plenty
of real reports on the surfaces we did promise to defend.

Thank you for reading this far. Any ideas are welcome.

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/support/security/
[1] https://nvd.nist.gov/vuln/detail/cve-2026-111497