While auditing RLS policies on NDF.CTG (a live community platform, 200+ users), I found a role-escalation vulnerability — a policy was missing its WITH CHECK clause. Without it, a member could update their own row and silently promote themselves to admin. The USING clause was doing its job on reads, but writes had no equivalent guard. Fixed it, then went back and audited all 9 tables for the same gap. It's the kind of bug that's invisible until someone exploits it — no error, no crash, just a quiet privilege escalation. Now it's part of my checklist for every new RLS policy: never assume USING covers writes.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
Nice catch, and it's a sneaky one because Postgres reuses USING for the write check when WITH CHECK is missing — so the policy behaves fine whenever a user edits their own row, and the one thing it never looks at is what the row became. On a similar bug I ended up going one layer down for the role column specifically: revoke UPDATE on that column and grant it only on the safe ones (GRANT UPDATE (name, bio) ON profiles), since RLS can't see which columns changed. Then even a future policy mistake can't hand out admin.