Уязвимость компонента Schema Handler системы управления базами данных PostgreSQL, позволяющая нарушителю обойти ограничения безопасности

Уязвимость системы управления базами данных PostgreSQL, связанная с недостатками разграничения доступа, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код

Уязвимость системы управления базами данных PostgreSQL, связанная с возможностью SQL-инъекций в расширениях, позволяющая нарушителю выполнять произвольный SQL-запрос к базе данных

Уязвимость системы управления базами данных PostgreSQL, связанная с недостатками разграничения доступа, позволяющая нарушителю читать и обновлять защищенные данные

schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.

Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.

IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.

A vulnerability was found in PostgreSQL with the use of the MERGE command, which fails to test new rows against row security policies defined for UPDATE and SELECT. If UPDATE and SELECT policies forbid some rows that INSERT policies do not forbid, a user could store such rows.

Уязвимость компонента Schema Handler системы управления базами данных PostgreSQL, позволяющая нарушителю обойти ограничения безопасности

Уязвимость системы управления базами данных PostgreSQL, связанная с недостатками разграничения доступа, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код

Уязвимость системы управления базами данных PostgreSQL, связанная с возможностью SQL-инъекций в расширениях, позволяющая нарушителю выполнять произвольный SQL-запрос к базе данных

schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.

Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.

IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.

Уязвимость компонента Schema Handler системы управления базами данных PostgreSQL, позволяющая нарушителю обойти ограничения безопасности

Уязвимость системы управления базами данных PostgreSQL, связанная с недостатками разграничения доступа, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код

Уязвимость системы управления базами данных PostgreSQL, связанная с возможностью SQL-инъекций в расширениях, позволяющая нарушителю выполнять произвольный SQL-запрос к базе данных

schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.

Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.

IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.

Уязвимость компонента Schema Handler системы управления базами данных PostgreSQL, позволяющая нарушителю обойти ограничения безопасности

Уязвимость системы управления базами данных PostgreSQL, связанная с недостатками разграничения доступа, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код

Уязвимость системы управления базами данных PostgreSQL, связанная с возможностью SQL-инъекций в расширениях, позволяющая нарушителю выполнять произвольный SQL-запрос к базе данных

schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.

Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.

IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.

Уязвимость компонента Schema Handler системы управления базами данных PostgreSQL, позволяющая нарушителю обойти ограничения безопасности

Уязвимость системы управления базами данных PostgreSQL, связанная с недостатками разграничения доступа, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код

Уязвимость системы управления базами данных PostgreSQL, связанная с возможностью SQL-инъекций в расширениях, позволяющая нарушителю выполнять произвольный SQL-запрос к базе данных

Уязвимость системы управления базами данных PostgreSQL, связанная с недостатками разграничения доступа, позволяющая нарушителю читать и обновлять защищенные данные

schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.

Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.

IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.

A vulnerability was found in PostgreSQL with the use of the MERGE command, which fails to test new rows against row security policies defined for UPDATE and SELECT. If UPDATE and SELECT policies forbid some rows that INSERT policies do not forbid, a user could store such rows.

In PHP versions 8.0.* before 8.0.30, 8.1.* before 8.1.22, and 8.2.* before 8.2.8 various XML functions rely on libxml global state to track configuration variables, like whether external entities are loaded. This state is assumed to be unchanged unless the user explicitly changes it by calling appropriate function. However, since the state is process-global, other modules - such as ImageMagick - may also use this library within the same process, and change that global state for their internal purposes, and leave it in a state where external entities loading is enabled. This can lead to the situation where external XML is parsed with external entities loaded, which can lead to disclosure of any local files accessible to PHP. This vulnerable state may persist in the same process across many requests, until the process is shut down.

In PHP version 8.0.* before 8.0.30,  8.1.* before 8.1.22, and 8.2.* before 8.2.8, when loading phar file, while reading PHAR directory entries, insufficient length checking may lead to a stack buffer overflow, leading potentially to memory corruption or RCE.