A security test of Snowflake-managed PostgreSQL has shown how a database role with limited privileges could be turned into control of the server running the database.
Researchers chained several built-in PostgreSQL features to reach operating-system command execution, even though Snowflake had blocked common ways to run commands and access files through SQL.
The finding highlights how small permissions can combine into a serious risk in managed cloud services. The researchers said the chain began with a non-superuser account called snowflake_admin.
Its key privilege was CREATEROLE, which lets an account create and manage roles. By itself, this permission does not give full control of a database. In this case, however, it helped open a path through other features that the database trusted.
Researchers from Varonis Threat Labs identified the privilege-escalation chain and reported it to Snowflake.
Varonis said Snowflake fixed the issue on its side before the research was published, so customers using Snowflake Postgres do not need to take additional action for this finding. The team first reported the chain on May 31, 2026, and shared it publicly on October 17.
Researchers Hack Snowflake PostgreSQL Database
The first step relied on CREATEROLE. The researchers used it to grant the starting account two built-in roles: pg_read_all_data and pg_write_all_data.
Those roles provide broad access to database tables and system catalogs. That access then let the researchers change entries in pg_cron, a PostgreSQL extension that runs scheduled jobs.
The researchers altered a scheduled job so it would run as the highly privileged postgres account. When the job ran, it created a SECURITY DEFINER function.
This kind of function runs with the permissions of its owner, rather than those of the user who calls it. The researchers used the function to gain PostgreSQL superuser access without using the direct role change that Snowflake had blocked.
That database-level access was not yet the same as control of the server. Snowflake had blocked familiar routes, including commands that read server files, change system settings, or run programs through SQL.
The researchers found that PostgreSQL’s internal language could bind a new database function name to a C function already present in the server software. This allowed them to restore access to blocked file-reading and file-writing functions under different names.
With file access, the team used PostgreSQL’s large-object feature to write to a configuration file. They changed archive_command, a setting that runs a shell command when PostgreSQL archives a completed write-ahead log (WAL) segment.
A WAL records database changes before they are fully written to data files. When the configured command ran, the researchers reached operating-system command execution as the postgres system account.
The finding is a reminder that blocking well-known SQL-to-operating-system functions may not be enough if related capabilities remain available through other routes.
It also matters because a managed database’s provider controls the server and its operating system, while customers still decide how database roles are assigned.
Similar database-to-server risks have appeared in other settings, including a PostgreSQL code execution flaw and a pgAdmin shell command flaw.
Possible impact and response
If a threat actor gained similar access, they could potentially alter or destroy database files, interfere with recovery, or change local logs.
Since the activity at the operating-system level may not pass through normal SQL queries, database audit records might not show the full picture.
Varonis said the demonstrated activity remained within the researchers’ own single-tenant test environment; the report does not say that Snowflake customer data was accessed.
.webp)
Snowflake addressed the chain server-side before publication. The report says the company acknowledged the disclosure on June 1 and confirmed on June 9 that local code execution inside the Snowflake Postgres virtual machine crossed a security boundary.
The researchers noted that the finding involved a chain of PostgreSQL behaviors, rather than one newly identified malware sample. For background on another PostgreSQL-related execution risk, readers can review GBHackers’ report on Appsmith PostgreSQL remote code execution.
For teams running their own PostgreSQL servers, the researchers recommend treating CREATEROLE as a high-risk permission and removing it from application accounts unless it is needed.
Administrators should review role grants, scheduled pg_cron jobs, and SECURITY DEFINER functions for unexpected changes.
They should also restrict who can create internal or C-language functions, protect database configuration files, and keep database services isolated from unnecessary network access.
Indicators of compromise (IoCs):-
| IoC type | Value |
|---|---|
| File hashes | None disclosed |
| Domains or IP addresses | None disclosed |
| Malware names | None disclosed |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Join 16,000+ SOC teams using ANY.RUN to streamline threat investigations and reduce manual effort. Explore for your team
