A recent security assessment of Snowflake-managed PostgreSQL databases has underscored a critical vulnerability within cloud-managed database services that could transform a database role with limited privileges into full control over the server hosting the database. This finding brings to light complexities associated with permission management in cloud environments, emphasizing how seemingly benign access rights can, when combined, lead to severe security risks.
Researchers from Varonis Threat Labs embarked on a thorough investigation, demonstrating that despite Snowflake’s measures to restrict commonplace SQL commands designed to execute operating-system commands or access files, there still existed a pathway for exploitation through various built-in features of PostgreSQL. The core of this security breach centered around a non-superuser account, referred to as snowflake_admin, which possessed the CREATEROLE privilege. This permission, while not granting full database control on its own, initiated a chain reaction that allowed researchers to exploit other trusted features within the PostgreSQL framework.
In this attack scenario, the CREATEROLE permission acquired by the snowflake_admin account enabled the researchers to assign two additional roles—pg_read_all_data and pg_write_all_data. These roles can significantly broaden access to database tables and system catalogs, facilitating alterations to entries in pg_cron, an extension used for scheduling jobs in PostgreSQL. By manipulating a scheduled job to execute under the highly privileged postgres account, the researchers successfully created a SECURITY DEFINER function, which operates with the permissions of its creator rather than the caller. This innovative maneuver provided a loophole through which the researchers could gain PostgreSQL superuser access, circumventing Snowflake’s restrictions on direct role changes.
While obtaining database-level privileges marked a significant achievement, it was not equivalent to seizing control of the server. Snowflake had implemented specific restrictions to prevent traditional methods of accessing server files, changing system settings, or executing programs via SQL commands. Nevertheless, the researchers uncovered a clever tactic involving PostgreSQL’s internal programming language that enabled them to bind a new database function to an existing C function found in the server software. This revelation allowed them to bypass Snowflake’s protections against file-reading and file-writing functions.
Armed with the ability to read and write files, the researchers utilized PostgreSQL’s large-object functionality to alter a configuration file known as archive_command. This command triggers the execution of a shell command when PostgreSQL archives a completed write-ahead log (WAL) segment. The WAL plays a crucial role in recording database modifications prior to finalizing them in data files. When the modified command was activated, the researchers successfully achieved operating-system command execution as the postgres system account.
This incident serves as a stark reminder that merely blocking well-known SQL functions intended to interact with the operating system may not suffice if alternative exploit pathways remain accessible. The implications are notably grave in managed database environments, where the provider maintains control over the server and its operating system, while customers retain responsibility for managing database role permissions. The risk of potential exploitation of database-to-server vulnerabilities has been observed in other instances as well, highlighting the pervasive threat landscape that exists within PostgreSQL and associated tools.
Looking ahead, the repercussions of such a security breach could be dire, as an adversary with similar access could effectively alter or erase critical database files, interfere with recovery mechanisms, and manipulate local logging information. Moreover, since such activities would run outside typical SQL queries, conventional database audit trails might not capture the entirety of the malicious actions taken.
Upon identifying this chain of vulnerabilities, Varonis promptly disclosed their findings to Snowflake, who addressed the issues server-side prior to the public release of the research findings. The initial report dated May 31, 2026, was officially published on October 17, signaling prompt action on Snowflake’s part to safeguard customer data. Importantly, the researchers emphasized that their testing remained confined to a controlled single-tenant environment, asserting that no customer data was compromised during the investigation.
For organizations managing their PostgreSQL servers, Varonis recommends treating the CREATEROLE permission as a high-risk capability and advocating its removal from application accounts unless explicitly needed. Regular audits of role grants, pg_cron jobs, and SECURITY DEFINER functions are essential to ensure unexpected changes do not slip through the cracks. Moreover, administrators should impose strict limitations on the ability to create internal or C-language functions, safeguard database configuration files, and isolate database services from unnecessary network access.
In summary, this comprehensive review serves as a cautionary tale about the vulnerabilities that can arise within cloud-managed database services. It highlights the critical importance of meticulous permission management and the need for vigilant oversight to protect sensitive data from potential exploitation.