CVE-2016-0766

What it actually does

The flaw permits low-privileged database users to modify unspecified custom configuration settings (GUCS) exposed to PL/Java, bypassing intended access controls and resulting in privilege escalation to higher database roles.

Why it matters to the business

Organizations running affected PostgreSQL deployments or container images that include them face risk of unauthorized database access escalation, which can lead to data exposure, integrity loss, or full system compromise; the large number of downstream package dependents increases the potential blast radius if unpatched instances remain in production or build pipelines.

How an attack unfolds

An attacker with low-privileged remote database access identifies PL/Java-enabled custom settings, issues crafted configuration changes that exploit the missing restrictions, and escalates to administrative privileges, enabling further actions such as data exfiltration or persistence within the PostgreSQL instance.

How to fix it

Upgrade PostgreSQL to versions 9.1.20, 9.2.15, 9.3.11, 9.4.6, 9.5.1 or later. For affected kaniko packages, update to the versions fixed in 1.21.0-r1 (kaniko, kaniko-compat, kaniko-warmer, and their Chainguard/Wolfi variants). Apply the postgresql.git commit 3dca6f36fcd694c8c49d26e7c4971194dee2754a where applicable and verify PL/Java configuration restrictions post-upgrade.

How to confirm the fix worked

Confirm PostgreSQL version strings match or exceed the fixed releases, review postgresql.conf and PL/Java extension settings to ensure custom GUCS are properly restricted, and test that low-privileged users can no longer modify protected configuration parameters.

Typical attack path

1. Obtain low-privileged remote access to a PostgreSQL instance with PL/Java installed
2. Identify and target exposed custom configuration settings (GUCS) for PL/Java
3. Issue configuration modification commands that bypass access restrictions
4. Escalate to higher-privileged database roles
5. Leverage elevated access for further compromise or data access

How to detect it

Review PostgreSQL logs for unexpected modifications to custom configuration settings or PL/Java-related parameters by non-administrative users; examine authentication and role-change events around the time of suspected access; correlate with application or container logs from affected kaniko-based builds if present.

What your security team should do

• Prioritize immediate upgrade of all PostgreSQL instances and dependent kaniko images to the listed fixed versions
• Audit current deployments for PL/Java usage and restrict custom configuration settings to trusted roles only
• Monitor for any remaining unpatched instances given the multi-year exposure window
• Include the affected packages in routine container image scanning and update pipelines