Total Database Collapse: Inside the ElectricSQL CVSS 10.0 SQL Injection

ElectricSQL, the popular sync engine used to power modern real-time applications, has disclosed a catastrophic SQL injection vulnerability in its core API. The flaw, tracked as CVE-2026-40906, has been assigned a maximum CVSS score of 10.0.

This critical-severity bug allows any authenticated user to gain full administrative control over the underlying PostgreSQL database, enabling them to read, modify, or completely destroy data across all tenants.

The vulnerability resides in the order_by parameter of the ElectricSQL /v1/shape API. Researchers discovered that the internal validation function, Parser.validate_order_by, utilized a permissive “catch-all” wildcard clause.

Because this wildcard silently accepted a variety of unexpected AST (Abstract Syntax Tree) node types—such as TypeCast and FuncCall—maliciously crafted SQL expressions were concatenated directly into the final database query.

Attackers can use invalid type casts to force PostgreSQL into returning sensitive data directly within error messages, a technique known as error-based data extraction.

By leveraging the dblink_exec() function, an attacker can execute arbitrary INSERT, UPDATE, or DELETE statements. This also enables the ability to drop tables or create new superuser roles for persistent, independent access.

Injecting pg_sleep() allows an attacker to tie up database connections, effectively causing a denial of service (DoS) without requiring any special extensions.

The most severe impact of CVE-2026-40906 is the complete collapse of application-level tenant isolation. In multi-tenant environments where separate users or organizations share a single database, a compromised account in one tenant can now “access, modify, or destroy data belonging to any other tenant in the same database”.

The destructive potential is further heightened because the dblink extension, which powers the write and delete paths, is “available by default on most managed PostgreSQL services”

ElectricSQL has addressed the flaw in version 1.5.0 using a robust two-layer defense. The fix replaces the permissive wildcard with a deny-by-default allowlist and introduces an AST rebuild process that ensures only normalized, machine-generated SQL ever reaches the database.

While ElectricSQL states they have “no evidence that this vulnerability was exploited in the wild,” the critical nature of the flaw makes immediate patching the only viable defense for self-managed instances.