/
← Voltar ao feed
medium technology cloud services

Varonis Threat Labs chains PostgreSQL features to gain OS-level code execution on Snowflake Postgres (fixed server-side)

1 fonte(s) · 1 atualização(ões) · publicado 19/10/2026 10:27 · coletado há 4 dias

Varonis Threat Labs disclosed a privilege-escalation chain in Snowflake Postgres that turned a limited, non-superuser role (snowflake_admin, holding CREATEROLE) into operating-system command execution as the postgres account. The chain abused built-in PostgreSQL behaviors, even though Snowflake had blocked the usual SQL-to-OS routes. Varonis reported it on May 31, 2026, and Snowflake acknowledged it on June 1 and confirmed on June 9 that local code execution inside the Snowflake Postgres VM crossed a security boundary. Snowflake fixed the issue server-side before the October 17 publication, so customers need no action. The activity stayed within the researchers' own single-tenant test environment, and the report does not say that customer data was accessed.

Detalhes técnicos

  • CREATEROLE was used to grant the account pg_read_all_data and pg_write_all_data, which allowed edits to pg_cron entries.
  • A scheduled pg_cron job was altered to run as the postgres account. It created a SECURITY DEFINER function that gave superuser access without the direct role change Snowflake had blocked.
  • PostgreSQL's internal language was used to bind new function names to C functions already present in the server. This restored the blocked file read and write functions under different names.
  • The large-object feature was used to write to a configuration file and change archive_command. The configured shell command then ran when a WAL segment was archived, giving OS command execution as postgres.
  • OS-level activity may not pass through SQL queries, so database audit records may not show the full picture.

Remediação

  • Snowflake Postgres customers need no action.
  • For self-managed PostgreSQL, treat CREATEROLE as high-risk and remove it from application accounts unless it is needed.
  • Review role grants, pg_cron jobs and SECURITY DEFINER functions for unexpected changes.
  • Restrict who can create internal or C-language functions, protect configuration files, and limit network exposure of database services.

Linha do tempo

  1. gbhackers.com ↗ · pub. 19/10/2026 10:27 · coletado 19/10 17:54 primeiro registro

    Varonis Threat Labs chains PostgreSQL features to gain OS-level code execution on Snowflake Postgres (fixed server-side)

    ler a análise desta fonte

    Varonis Threat Labs disclosed a privilege-escalation chain in Snowflake Postgres that turned a limited, non-superuser role (snowflake_admin, holding CREATEROLE) into operating-system command execution as the postgres account. The chain abused built-in PostgreSQL behaviors, even though Snowflake had blocked the usual SQL-to-OS routes. Varonis reported it on May 31, 2026, and Snowflake acknowledged it on June 1 and confirmed on June 9 that local code execution inside the Snowflake Postgres VM crossed a security boundary. Snowflake fixed the issue server-side before the October 17 publication, so customers need no action. The activity stayed within the researchers' own single-tenant test environment, and the report does not say that customer data was accessed.

    Technical Details

    • CREATEROLE was used to grant the account pg_read_all_data and pg_write_all_data, which allowed edits to pg_cron entries.
    • A scheduled pg_cron job was altered to run as the postgres account. It created a SECURITY DEFINER function that gave superuser access without the direct role change Snowflake had blocked.
    • PostgreSQL's internal language was used to bind new function names to C functions already present in the server. This restored the blocked file read and write functions under different names.
    • The large-object feature was used to write to a configuration file and change archive_command. The configured shell command then ran when a WAL segment was archived, giving OS command execution as postgres.
    • OS-level activity may not pass through SQL queries, so database audit records may not show the full picture.

    Remediation

    • Snowflake Postgres customers need no action.
    • For self-managed PostgreSQL, treat CREATEROLE as high-risk and remove it from application accounts unless it is needed.
    • Review role grants, pg_cron jobs and SECURITY DEFINER functions for unexpected changes.
    • Restrict who can create internal or C-language functions, protect configuration files, and limit network exposure of database services.