SQL Injection in Drupal Core Database Abstraction API

This repository is a small standalone Python exploit/scanner project with 3 files: an MIT LICENSE, a detailed README, and one main code file, cve_2026_9082_scanner.py. It is not tied to a major exploitation framework. The Python script is the sole operational component and serves as both a mass scanner and a single-target exploitation utility for an unauthenticated Drupal JSON:API SQL injection identified as CVE-2026-9082. The exploit logic targets Drupal Core instances backed by PostgreSQL. It abuses JSON:API filter parameter array keys to inject SQL into requests sent to /jsonapi/{resource_type}. The script first fingerprints targets by checking /jsonapi and the X-Generator header or page content for Drupal indicators. It then discovers likely JSON:API resource types from the /jsonapi index or falls back to common node types such as node/article, node/page, and node/basic_page. Detection is implemented with two techniques: a time-based blind SQLi using pg_sleep() and a boolean-based comparison of response characteristics. The visible code includes a crafted injection key containing PostgreSQL logic around current_user and pg_sleep(), indicating the exploit is intended to confirm injection without authentication. The README and CLI handling show additional exploitation modes for extracting PostgreSQL version, database user/name, Drupal admin credentials (uid=1), public table names, and arbitrary SQL query results. Operationally, the script supports single-target mode and concurrent mass scanning using Python threads. It accepts target URLs directly or from an input file, supports configurable timeout and delay values, optional TLS verification disabling, and HTTP proxying through a user-supplied proxy such as Burp. Results can be printed in color and written to an output file. Overall, this is a real exploit-oriented tool rather than a simple detector: it contains active SQL injection request generation, vulnerability confirmation logic, and post-detection data extraction capabilities. However, it does not appear to include a direct shell or RCE payload in the provided content; instead it focuses on SQLi-based reconnaissance and database extraction.

Repository contains an operational exploit chain centered on lo_upload.py plus a supporting malicious PostgreSQL shared-library payload and a Docker-based reproduction lab. The main exploit file, lo_upload.py, is a standalone Python script that sends crafted JSON POST requests to a Drupal login endpoint and abuses a SQL injection primitive to execute PostgreSQL large object functions. Its core capability is arbitrary file write to the database server filesystem: it creates a large object, uploads the local file in 8 KB chunks with lo_put, exports it to an attacker-chosen path with lo_export, then removes the large object with lo_unlink. It also includes a blind verification step using md5(pg_read_binary_file(...)) and pg_sleep timing. The included evil_shell.c is a PostgreSQL extension/shared object payload intended to be uploaded by the Python script. When PostgreSQL loads it and _PG_init executes, it writes a marker file and forks a bash reverse shell to 192.168.52.129:4444. This demonstrates the repository’s intended post-write objective: turning arbitrary file write into code execution on the database host. Repository structure: README.md is minimal; lo_upload.py is the primary exploit; evil_shell.c is the sample second-stage payload; Docker_env/docker-compose.yml provisions a local Drupal 11.3.9 + PostgreSQL 16 lab; Docker_env/setup.sh automates Drupal installation, JSON:API enablement, and seed content creation. The lab files reference SA-CORE-2026-004, while the Python exploit comments reference CVE-2019-6340-style SQLi behavior, so the repository appears to mix a reproduction environment for one Drupal issue with an exploit technique and payload chain for SQLi-to-PostgreSQL file write/RCE. Overall, this is not merely a detector or README: it is exploit code with a concrete offensive capability and a bundled RCE-oriented payload.

Repository contains a working Python exploit plus a Dockerized local lab for a Drupal JSON:API to PostgreSQL SQLi-to-RCE chain. The main exploit file is drupal-postgres-preload-rce.py, which targets a Drupal JSON:API endpoint at /jsonapi/node/article by abusing a crafted filter parameter to inject SQL into a SELECT context. The exploit first fingerprints the backend by querying version(), current_user, superuser status, and data_directory, then derives the correct PostgreSQL module ABI layout for versions 12, 13-14, 15-17, and 18+. It locally compiles a malicious C shared object matching the target architecture, uploads it to the PostgreSQL server using large-object based file writes, rewrites postgresql.auto.conf to set session_preload_libraries, reloads PostgreSQL configuration, triggers a fresh backend connection so the library loads, and finally reads command output from /tmp/cve9082_rce using pg_read_file(). Cleanup logic restores or clears preload settings afterward. The exploit is operational rather than a simple PoC because it includes a full payload path for arbitrary command execution, but it is not part of a larger exploitation framework. The repository also includes docker-compose.yml, a PostgreSQL container definition, a Drupal Dockerfile, an entrypoint script that installs Drupal 10.4.9 and enables JSON:API, a PHP seed script that publishes an article so the endpoint is anonymously reachable, and SQL initialization for the lab database. Overall purpose: demonstrate and reproduce CVE-2026-9082 in a controlled environment, specifically the escalation from unauthenticated Drupal JSON:API SQL injection to OS command execution on a PostgreSQL-backed deployment where Drupal connects as postgres superuser.

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.