SQLBot EUVD-2026-82562

Requires an authenticated SQLBot account (PR:L) able to create/configure a datasource that targets SQLBot's own internal PostgreSQL service. Exploitation further depends on the default tested trusted-loopback (pg_hba.conf trust/peer) authentication, under which the internal connection accepts invalid credentials and runs with PostgreSQL superuser privileges - a prerequisite for pg_read_file()/pg_read_binary_file()/pg_ls_dir() to succeed. The read-only policy does not block these because the payload remains a SELECT. Limiting factors: authentication is mandatory, the attacker must be able to reach and configure the internal PG datasource, and hardened deployments that disable trusted loopback or run PostgreSQL as a non-superuser substantially reduce or eliminate the filesystem-read impact. Affects versions prior to 1.9.0.

This is a genuine but moderate-priority confidentiality flaw, well-characterized by the vendor's CVSS 4.0 vector (6.0: AV:N/AC:H/AT:P/PR:L/UI:N/VC:H). The signals are internally consistent: network vector but authenticated (PR:L - the attacker must be a logged-in SQLBot user), high complexity plus a present attack requirement (AC:H/AT:P), reflecting that exploitation depends on the attacker being able to configure a datasource pointing at SQLBot's internal PostgreSQL AND on the default trusted-loopback authentication that grants superuser and accepts invalid credentials. Impact is confidentiality-only (VI:N/VA:N) - arbitrary server-side file read (/etc/passwd, /etc/hosts, config, credentials, secrets, source code), not write or RCE. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided data, so this is 'no public exploit identified at time of analysis' rather than active exploitation. However, the GitHub Security Advisory (GHSA-vwjq-5h4h-x8g5), the fix commit, and the PR are all public, and the one-line change (client-controlled table_name → server-side table lookup by id) makes the injection mechanism trivially derivable, so the barrier to weaponization is low even without a published PoC. Net: real vulnerability worth patching, but gated by authentication and a specific PostgreSQL-loopback configuration rather than a wormable internet-facing critical.

An authenticated SQLBot user creates a datasource pointing at SQLBot's internal PostgreSQL service (which under the default trusted-loopback config runs as superuser and accepts invalid credentials), then submits a crafted table_name to POST /api/v1/datasource/previewData that stays a SELECT under the read-only policy but invokes pg_read_file() / pg_ls_dir(). The API response returns filesystem contents such as /etc/passwd, configuration files, and application source code. No public exploit is identified, but the fix commit and advisory make the technique easy to reconstruct.