Defenders Must Audit PostgreSQL Role Chains in Snowflake Environments
Researchers showed how limited database privileges could escalate to full server control, highlighting risks in managed cloud services.
Key points
- Varonis researchers chained PostgreSQL features to gain OS command execution from a limited role.
- The attack used CREATEROLE to access pg_cron and create a SECURITY DEFINER function.
- Snowflake patched the issue on its side, so customers need no further action for this specific finding.
Researchers from Varonis Threat Labs demonstrated a privilege-escalation chain in Snowflake-managed PostgreSQL that allows limited database roles to execute operating-system commands. The team reported the findings to Snowflake on May 31, 2026, and published them publicly on October 17. This incident highlights how small permissions can combine into a serious risk in managed cloud services, similar to other recent findings where limited access led to significant system compromise.
The risk
The attack chain began with a non-superuser account named snowflake_admin that held the CREATEROLE privilege. While this permission alone does not grant full database control, it allowed the researchers to assign the pg_read_all_data and pg_write_all_data roles to their account. These roles provided broad access to system catalogs and database tables, enabling the modification of pg_cron, an extension for scheduled jobs.
By altering a scheduled job to run as the highly privileged postgres account, the researchers created a SECURITY DEFINER function. This function executes with the permissions of its owner rather than the caller, granting the attackers PostgreSQL superuser access. This bypassed Snowflake’s blocks on direct role changes, effectively bridging the gap between limited database access and full administrative control within the database engine.
Who is exposed
Snowflake had previously blocked common SQL-based methods for running commands, reading server files, or changing system settings. However, the researchers found that PostgreSQL’s internal language could bind new database function names to existing C functions within the server software. This technique allowed them to restore access to blocked file-reading and file-writing capabilities under different names, ultimately achieving operating-system level command execution on the server hosting the database.
Cost and compliance
Varonis stated that Snowflake fixed the issue on its side before the research was published. Consequently, customers using Snowflake Postgres do not need to take additional action for this specific finding. The vendor addressed the vulnerability internally, preventing the exploitation of this specific privilege-escalation chain in managed environments.
Our take on the response
Snowflake’s proactive patching demonstrates effective vendor response, but the underlying mechanics reveal significant risks in managed database configurations. Security teams should treat this as a warning to audit all database roles and extensions, ensuring that even limited privileges cannot be chained to bypass security controls.
What defenders should look for
Teams usually monitor for unexpected changes to scheduled job configurations or the creation of new SECURITY DEFINER functions. Check whether database roles have been granted broad read or write access to system catalogs. Look for attempts to bind internal language functions to existing C functions, which may indicate an attempt to bypass file-access restrictions. Contain potential breaches by isolating affected database instances and reviewing all role assignments for excessive privileges.
What to do and how to stay safe
- Audit all database roles to ensure the principle of least privilege is strictly enforced, removing unnecessary CREATEROLE permissions.
- Monitor logs for modifications to scheduled job extensions like pg_cron, as these can be used to escalate privileges.
- Review the creation of SECURITY DEFINER functions to ensure they are authorized and necessary for business operations.
- Once the vendor provides an update, verify that all managed database instances are running the patched version to prevent similar exploitation.
Step-by-step guide: Multi-Factor Authentication Fatigue: Why Users Click Yes Too Fast
General security guidance from the BlueTeam Herald newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Do Snowflake customers need to patch their own servers for this vulnerability?
No, Snowflake fixed the issue on its side, so customers do not need to take additional action for this finding.
What privilege started the attack chain?
The chain began with the CREATEROLE privilege on a non-superuser account called snowflake_admin.
When was this vulnerability reported to Snowflake?
The team first reported the chain on May 31, 2026, and shared it publicly on October 17.
