CVE-2026-76904: Unauthenticated SQL Injection in GeoTools PostGIS DataStore Component

The GeoTools open-source Java library provides standard-compliant methods for manipulating geospatial data. The library's gt-jdbc-postgis module allows client applications to connect to PostgreSQL/PostGIS database backends. When users submit spatial queries through Web Feature Service (WFS) or Web Map Service (WMS) endpoints, GeoTools translates high-level OGC Filter expressions into native database queries.

The vulnerability is located within the implementation of the jsonArrayContains filter function, designed to facilitate native querying of JSON or string array structures on modern PostgreSQL backends. Because this function exposes an attack surface that translates user-supplied parameters into database execution parameters, lack of rigorous boundary isolation within the query-generation module results in a SQL injection vulnerability.

This security weakness is classified under CWE-89 (Improper Neutralization of Special Elements used in an SQL Command). The consequences of successful exploitation range from unauthorized access to sensitive database schemas to total system compromise on the database server if the connection pool operates with high privilege levels.

To support JSON query operations, GeoTools uses PostgreSQL's SQL/JSON path engine, introduced natively in PostgreSQL 12. The underlying database engine processes path evaluations using the jsonb_path_exists function, which expects its arguments as format strings or parameters. The dynamic compilation of this function occurs in modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java.

The specific point of failure resides in the constructEquality method, which is responsible for building the key-value comparison string within the generated JSON path expression. Instead of utilizing parameterized query interfaces or sanitizing the input characters, the GeoTools translation engine formats the expression dynamically using Java's String.formatted framework.

When the compiler processes the string literal argument, it incorporates the user input directly into the comparison query template: (@.%s == "%s"). Because the library does not execute escaping or character substitution before formatting, input data that contains unescaped single or double quotes breaks out of the string context. This allows an attacker to manipulate the boundary of the query, resulting in arbitrary SQL command execution within the database engine.

The vulnerable implementation in FilterToSqlHelper.java accepts the target array and value parameters to generate the query comparison string:

// Vulnerable Code Path in FilterToSqlHelper.java
private String constructEquality(String[] jsonPath, Expression expected) {
    // ... evaluation logic ...
    } else if (value instanceof Double double1) {
        return "(@.%s == %f)".formatted(jsonPath[lastIndex], double1);
    }
    // Vulnerability: Direct string formatting without escaping
    return "(@.%s == \"%s\")".formatted(jsonPath[lastIndex], value);
}

The patched version introduces string preprocessing to properly escape characters that could alter the semantic structure of the generated SQL/JSON instruction:

// Patched Code Path with escapeJsonLiteral Integration
private String constructEquality(String[] jsonPath, Expression expected) {
    // ... evaluation logic ...
    } else if (value instanceof Double double1) {
        return "(@.%s == %f)".formatted(jsonPath[lastIndex], double1);
    }
    // Remediation: Escaping characters using escapeJsonLiteral
    String literal = escapeJsonLiteral(String.valueOf(value));
    return "(@.%s == \"%s\")".formatted(jsonPath[lastIndex], literal);
}

The vulnerability is fully addressed because the escapeJsonLiteral method converts double quotes (") to escaped format strings (\") to neutralize the JSON path boundary break. Simultaneously, single quotes (') are doubled ('') to ensure the outer SQL query engine does not evaluate user input as a query delimiter, maintaining structural integrity across both the SQL and JSON parsers.

An attacker can exploit this vulnerability by submitting a maliciously constructed ECQL filter string via standard OGC WFS or WMS protocols. Exploitation does not require authentication or user interaction.

To construct an exploit, the attacker crafts a request using the jsonArrayContains function, passing a SQL comment or boolean evaluation statement inside the value field. The payload uses nested quote boundaries to escape the JSON query parameters. For example, the attacker can pass a payload containing SQL statements like payload" OR (SELECT 1 FROM pg_sleep(5)) IS NOT NULL --.

When GeoTools compiles the OGC request, the PostGIS dialect helper translates the filter into SQL format:

SELECT * FROM target_table WHERE jsonb_path_exists(column::jsonb, '$ ? (@.property == "payload" OR (SELECT 1 FROM pg_sleep(5)) IS NOT NULL --")')

During execution, the PostgreSQL server evaluates the outer SQL query logic, parsing the sleep command directly. A successful delay of execution demonstrates blind SQL injection capability, allowing the attacker to construct automation scripts to extract data, download configuration files, or interact with database services.

The impact of this SQL injection vulnerability is classified as critical. It exposes the application infrastructure to unauthorized data retrieval, system modifications, and full backend database takeover.

Attackers can exfiltrate sensitive data, including administrative credentials and proprietary geospatial datasets, by extracting schema records through automated SQL blind techniques. If the database schema has write permissions, attackers can perform database modification attacks, altering spatial geometries, system configurations, or service permissions.

Under configurations where the database process runs with superuser privileges or filesystem write access, attackers can escalate access. Utilizing PostgreSQL functions such as COPY ... FROM PROGRAM or standard large objects APIs allows the executing process to execute arbitrary OS commands, achieving remote code execution on the hosting infrastructure.

The standard remediation pathway is upgrading the GeoTools library dependency to a patched release. All applications using the gt-jdbc-postgis package must ensure they build against secure library versions.

The vulnerability is resolved in GeoTools releases 33.6, 34.5, and 35.1. Developers utilizing Maven or Gradle build environments should update their dependency configurations to reflect these versions or newer releases.

If immediate deployment of upgraded software is not possible, administrative workarounds must be applied. Configure database user connection pools with limited privileges, restricting access to administrative system tables and filesystems. Implement rules on Web Application Firewalls (WAF) to search for and block HTTP requests featuring SQL keywords or unmatched single quotes within the ECQL or WFS request payload.