Researchers at Varonis Threat Labs discovered a privilege escalation chain in Snowflake Postgres that enabled operating system command execution by combining several built in PostgreSQL features. The attack began with a non-superuser account named snowflake_admin, which had the CREATEROLE privilege. Although this permission does not provide full database control on its own, researchers used it to grant the account two powerful built-in roles, pg_read_all_data and pg_write_all_data. These roles provided broad access to database tables and system catalogs, allowing the researchers to manipulate scheduled jobs managed by the pg_cron extension. Varonis reported the issue to Snowflake, which fixed the vulnerability on its side before the research was published. The researchers modified a scheduled pg_cron job to execute as the highly privileged postgres account. When triggered, the job created a `SECURITY DEFINER` function, which executes with its owner's privileges. This enabled the researchers to obtain PostgreSQL superuser access despite Snowflake blocking direct privilege escalation. They then exploited PostgreSQL's internal language capabilities to associate new database function names with existing C functions in the server software, restoring access to file-reading and file-writing operations that had been restricted. Using these capabilities, the team leveraged PostgreSQL's large object feature to modify a configuration file and change the archive_command setting. This setting executes a shell command when PostgreSQL archives a completed write ahead log (WAL) segment. When the command ran, the researchers achieved operating system command execution under the postgres system account. Potential consequences of similar attacks include database file destruction, recovery disruption, and manipulation of local logs. Because operating system activity may bypass normal SQL queries, database audit logs might not capture the complete sequence of actions. Varonis first reported the issue on May 31, 2026, and publicly disclosed it on October 17. Snowflake 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 said the demonstration remained within their own single-tenant test environment, with no reported access to customer data. For self-managed PostgreSQL deployments, they recommend restricting CREATEROLE, reviewing role grants and scheduled jobs, auditing SECURITY DEFINER functions, and limiting access to C language functions and sensitive configuration files.
The U.S. Department of Homeland Security (DHS) has directed federal civilian agencies to eliminate DeepSeek AI tools and related services from their IT environments due to concerns...
Cybercriminals are abusing legitimate financial technology (fintech) platforms to conduct phishing attacks and validate stolen banking credentials, according to research by Group-I...
OVHcloud disclosed a software supply-chain attack on its command-line interface (CLI) repository after an attacker compromised a developer’s GitHub account and distributed malici...