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. A flaw was found in PostgreSQL, which could permit incorrect policies being applied in certain cases where role-specific policies are used and a given query is planned under one role and 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 only affects databases that have used CREATE POLICY to define a row security policy.
With Rapid7 live dashboards, I have a clear view of all the assets on my network, which ones can be exploited, and what I need to do in order to reduce the risk in my environment in real-time. No other tool gives us that kind of value and insight.
– Scott Cheney, Manager of Information Security, Sierra View Medical Center