Anonymous PostgreSQL SQL Injection in Drupal Core

This repository is a small standalone Python exploit project for CVE-2026-9082 affecting Drupal Core backed by PostgreSQL. It contains two executable scripts and minimal supporting files: a README, requirements.txt, and .gitignore. The main purpose is to exploit an unauthenticated SQL injection in Drupal's POST /user/login endpoint when _format=json is used and the name field is supplied as a JSON object rather than a string. The first script, cve_2026_9082_check.py, is a reconnaissance and validation tool. It builds a requests session, posts crafted JSON to /user/login?_format=json, and confirms injection using error-based, hex-encoded error-based, time-based, and side-effect SQL techniques. It extracts PostgreSQL version, current database user, superuser status, data_directory, selected table names, and even Drupal admin account data from users_field_data. This is not merely a detector; it actively exploits the SQL injection to exfiltrate data. The second script, cve_2026_9082_rce.py, performs the full SQLi-to-RCE chain. Based on the visible code and README, it fingerprints PostgreSQL ABI/version, compiles a malicious shared object locally, uploads it to the PostgreSQL data directory using large object functions, rewrites postgresql.auto.conf to set session_preload_libraries and dynamic_library_path, reloads PostgreSQL with pg_reload_conf(), triggers fresh backend connections so the library loads, executes an operator-supplied command via _PG_init()/system(), reads command output from /tmp/cve9082_rce using pg_read_file(), and finally restores the original configuration. The exploit appears operational rather than a simple proof of concept because it automates the full chain and includes cleanup logic, but it is not part of a larger exploitation framework. Primary network targeting is the Drupal web endpoint /user/login?_format=json. Secondary targets are PostgreSQL internals and filesystem paths reachable through SQL functions, especially data_directory, postgresql.auto.conf, and the temporary marker file. Overall, the repository is a focused offensive toolset for unauthenticated web exploitation leading to database-level abuse and potential operating-system command execution when PostgreSQL runs with superuser privileges.

This repository is a real exploit plus a self-contained Docker lab for CVE-2026-9082, targeting a Drupal JSON:API SQL injection when Drupal is configured to use PostgreSQL with excessive database privileges. The main exploit is drupal-postgres-preload-rce.py, a standalone Python script using requests to send crafted GET requests to /jsonapi/node/article with malicious filter parameters. Its purpose is not merely to prove SQL injection, but to escalate a SELECT-only SQLi into full OS command execution. Core exploit flow: the script first probes the injection context and extracts PostgreSQL metadata such as version(), current_user, superuser status, and data_directory. It parses the PostgreSQL major version and selects an ABI-specific Pg_magic layout for PostgreSQL 12, 13-14, 15-17, or 18+. It then generates C source for a malicious preload module, compiles it locally into a shared object matching the target architecture, and uploads the binary to the target PostgreSQL data directory using PostgreSQL large-object/file-write primitives. Next, it rewrites postgresql.auto.conf to enable session_preload_libraries pointing to the uploaded library, reloads PostgreSQL configuration with pg_reload_conf(), triggers fresh backend sessions, and reads command output from a marker file (/tmp/cve9082_rce) via pg_read_file(). Finally, it attempts cleanup by restoring or clearing the modified preload settings. The exploit’s main capability is arbitrary command execution as the postgres OS account. The payload is operational rather than framework-grade weaponized: it accepts an arbitrary command argument, but relies on a specific privilege model and local compilation of a matching shared library. Repository structure: README.md documents the vulnerability, exploitation chain, and lab usage. docker-compose.yml defines two services: a PostgreSQL 18.4 container and a Drupal 10.4.9 container exposed on 127.0.0.1:8089. The drupal/ directory contains the Dockerfile for building the vulnerable Drupal environment, entrypoint.sh for automated installation and configuration, and seed-content.php to create a published article so the anonymous JSON:API endpoint is available. requirements.txt contains the sole Python dependency, requests. Notable targeting assumptions: the lab intentionally connects Drupal to PostgreSQL as the postgres superuser, which is essential to the escalation path. Without PostgreSQL superuser-level access, the exploit would likely stop at SQL injection or fail during file-write/config-reload stages. The exploit is therefore best understood as a chained SQLi-to-RCE technique against misconfigured Drupal-on-PostgreSQL deployments, not a generic Drupal RCE independent of database privileges.

This repository is a small standalone Python exploit project consisting of one README and one executable script, cve_2026_9082_scanner.py. It is not part of a larger exploitation framework. The script is both a scanner and an exploitation utility targeting an alleged unauthenticated SQL injection in Drupal Core JSON:API deployments using PostgreSQL, identified as CVE-2026-9082. Repository structure is simple: README.md documents the vulnerability claim, usage examples, supported modes, and references; cve_2026_9082_scanner.py contains all logic for target normalization, HTTP session handling, Drupal/JSON:API detection, resource discovery, vulnerability testing, exploitation actions, multithreaded mass scanning, CLI parsing, and optional result export. Core exploit behavior: the script builds crafted GET requests to /jsonapi/{resource_type} using JSON:API filter parameters where the array key inside filter[sqli][condition][value][<key>] is attacker-controlled. The code’s build_qs() function inserts canary values plus a malicious key, and send_injection() dispatches the request. Detection is implemented in detect_vuln() using two methods: (1) time-based SQLi with pg_sleep(), comparing baseline and injected response times; and (2) boolean-based SQLi by comparing response characteristics for TRUE versus FALSE conditions. The script first checks whether the target looks like Drupal and whether /jsonapi is exposed, then attempts to discover usable resource types from /jsonapi links or fallback paths such as node/article, node/page, and node/basic_page. Capabilities described and partially evidenced by the code/README include: single-target vulnerability checks, concurrent mass scanning from a file, PostgreSQL version extraction, current DB user/database extraction, admin credential dumping for uid=1, public table enumeration, and arbitrary SQL query execution/extraction. It also supports proxying, configurable timeout and delay values, optional TLS verification disablement, and writing scan results to an output file. The exploit is operational rather than a mere proof of concept because it includes real HTTP request logic, concurrency, detection heuristics, and post-detection data extraction features. Based on the visible code and README, it is clearly offensive exploit tooling rather than only a detector. No obviously destructive fake-exploit behavior is present in the provided content.

This repository is a compact exploit PoC for CVE-2026-9082, a Drupal Core PostgreSQL SQL injection vulnerability reachable through JSON:API filter parameters. The repository contains one primary Python exploit script (CVE-2026-9082.py), a descriptive README, a placeholder img/README.md, and a docker-compose test lab for spinning up Drupal 11.3.9 with PostgreSQL. The exploit script is a standalone Python CLI tool using requests and rich. Its workflow is: detect Drupal and JSON:API availability, discover usable JSON:API resource types, test whether the target appears vulnerable, and then run one or more extraction actions. The core exploit mechanism is the construction of a malicious JSON:API filter query string where a user-controlled array key is URL-encoded into filter[sqli][condition][value][<key>]. This abuses Drupal's PostgreSQL entity query placeholder generation so that part of the key becomes literal SQL after PDO stops parsing the placeholder name. The script appears to support multiple operator modes (including timing/boolean-oriented extraction), and exposes commands for vulnerability checking, version extraction, DB info extraction, admin data extraction, table enumeration, and arbitrary SQL query extraction. Main exploit capabilities observed from the script and README: - Unauthenticated reconnaissance of Drupal and JSON:API - Resource type discovery under /jsonapi - Vulnerability testing against affected Drupal/PostgreSQL targets - Extraction of PostgreSQL/Drupal version information - Extraction of database username/name information - Enumeration of database tables - Attempted extraction of Drupal admin credential-related data (uid=1) - Arbitrary SQL query execution/extraction via a custom query option The exploit is not merely a detector; it is an operational SQLi exploitation tool with built-in post-verification data extraction features. It does not appear to deliver a shell payload directly, but it enables meaningful database exfiltration and could support further compromise depending on target configuration. The included docker-compose file shows the intended lab setup: a PostgreSQL 16 container and a Drupal 11.3.9 container exposed on localhost:8888, reinforcing that the exploit specifically targets PostgreSQL-backed Drupal deployments.