Varonis Threat Labs (Lior Adar, BSides NYC) showed that the snowflake_admin role in Snowflake Postgres, whose only notable attribute is CREATEROLE, could reach command execution on the database VM. It self-granted pg_read_all_data and pg_write_all_data (allowed for CREATEROLE since PostgreSQL 14), then rewrote a pg_cron job's username to postgres. pg_cron runs jobs over the local socket without a password, so the job planted a SECURITY DEFINER backdoor and gave the role superuser. From there, LANGUAGE internal functions re-bound the C symbols behind the file-read functions Snowflake had blocked by name, lo_export wrote postgresql.auto.conf, and an injected archive_command ran shell commands on every WAL archive. Varonis says this beat Snowflake's published mitigations without disabling any of them, and could let an attacker tamper with data or recovery outside SQL audit trails. Snowflake fixed it server-side and customers need do nothing. Varonis frames it as a recurring pattern after its earlier AWS RDS and Azure Cosmos for PostgreSQL RCEs.