The discussion centers on whether a Postgres type-confusion vulnerability constitutes Remote Code Execution (RCE) or a more limited privilege escalation, given that exploitation requires existing authenticated access. Participants disagree on the severity and scope, with some arguing it is a serious RCE affecting exposed instances while others classify it as an internal lateral movement vector or ACE.
29 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4Abstrct
Schemaverse
PLpgSQL2021–2026
Abstrct / Schemaverse
Schemaverse
The Schemaverse is a space-based strategy game implemented entirely within a PostgreSQL database. Compete against other players using raw SQL commands to command your fleet. Or, if your PL/pgSQL-foo is strong, wield it to write AI and have your fleet command itself!
3Distinct people
6Mentions
0Explicit recommenders
442GitHub stars
What to know before exploring
What it is
The Schemaverse is a space-based strategy game implemented entirely within a PostgreSQL database. Compete against other players using raw SQL commands to command your fleet. Or, if your PL/pgSQL-foo is strong, wield it to write AI and have your fleet command itself!
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
Informational One commenter mentions the schemaverse repository as an example of pushing authentication and access control into a database engine. The comment describes this approach as 'sort of neat' but notes that security attacks were half-expected.
What changed this week. Read the supporting reply
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Informational
One commenter mentions the schemaverse repository as an example of pushing authentication and access control into a database engine. The comment describes this approach as 'sort of neat' but notes that security attacks were half-expected.
Supporting reply 1 · 1 discussions summarized
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:59:22 PM UTC.
Mentions over time
HN mentions by year6 dated mentions
Observed mentions: 2021-11-29 05:02:08 UTC to 2026-07-10 22:37:24 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
1 sourcesSOsomat·Jul 10, 2026
"But let’s look at what happens if an attacker discovers a blind SQL injection vulnerability anywhere else in the application.
The attacker doesn’t need to read the database or invert any hashes. An attacker can simply register a legitimate account and generate his own valid API key."
No they can't, The given scenario has not pushed the auth into the database at all. if your accounts are also database accounts why does the user have permission to create new accounts.
I have done this as an experiment, I was dreading building a comprehensive auth system and noticed that the barely used postgres internal auth system is very well fleshed out so just made every user be a database user. The application has little concept of auth at all, it just passes the user login into the database connection and all the auth (logins, what data the user can
Read the rest
get, what data the user can write) is all done as database policy. It worked surprisingly well, I don't know if I would use it on a real system(whatever that means, pg logins probably do not scale) The idea still sort of makes my skin crawl, Nobody does it this way, I assume for a reason. But in theory it is fine.
I probably got the idea from the schemaverse game, where the whole game is internal to postgres, and the users are given direct select access.
https://github.com/Abstrct/Schemaverse