VYPR
High severityNVD Advisory· Published May 12, 2026· Updated May 13, 2026

CVE-2026-32687

CVE-2026-32687

Description

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in elixir-ecto postgrex ('Elixir.Postgrex.Notifications' module) allows SQL Injection.

The channel argument passed to 'Elixir.Postgrex.Notifications':listen/3 and 'Elixir.Postgrex.Notifications':unlisten/3 is interpolated directly into LISTEN "..." / UNLISTEN "..." SQL statements without escaping the " character. An attacker who can influence the channel name can inject a " to break out of the quoted identifier and append arbitrary SQL. Because the notifications connection uses the PostgreSQL simple query protocol, multi-statement payloads are accepted, allowing DDL and DML commands to be chained (e.g. ; DROP TABLE ...; --). The same unsanitized interpolation also occurs in handle_connect/1 when replaying LISTEN commands after a reconnect.

This vulnerability is associated with program file lib/postgrex/notifications.ex and program routines 'Elixir.Postgrex.Notifications':listen/3, 'Elixir.Postgrex.Notifications':unlisten/3, 'Elixir.Postgrex.Notifications':handle_connect/1.

This issue affects postgrex: from 0.16.0 before 0.22.2, from pkg:github/elixir-ecto/postgrex@266b530faf9bde094e31e0e4ab851f933fadc0f5 before 0.22.2.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Postgrex Notifications module has an SQL injection flaw where channel names are interpolated into LISTEN/UNLISTEN statements without escaping double quotes, enabling arbitrary SQL execution.

Vulnerability

CVE-2026-32687 is an SQL injection vulnerability in the Elixir.Postgrex.Notifications module of the postgrex library (versions 0.16.0 up to but not including 0.22.2). The root cause is that the channel argument passed to listen/3 and unlisten/3 is directly interpolated into LISTEN "..." and UNLISTEN "..." SQL statements without escaping the double-quote (") character [1][2]. The same unsanitized interpolation also occurs in handle_connect/1 when replaying LISTEN commands after a reconnection [1].

Exploitation

An attacker who can influence the channel name—for example, through a pub/sub bridge that uses a tenant ID or topic slug as the channel—can inject a double-quote to break out of the quoted identifier and append arbitrary SQL [4]. Because the notifications connection uses the PostgreSQL simple query protocol, multi-statement payloads are accepted, allowing an attacker to chain DDL and DML commands (e.g., ; DROP TABLE ...; --) [1][2]. The vulnerability is reachable via any code path that calls listen/3 or unlisten/3 with unsanitized input [4].

Impact

Successful exploitation allows an attacker to execute arbitrary SQL on the notifications connection as the configured database user. This can lead to reading, modifying, or destroying any data that the application's database role can access [4]. The impact is amplified by the lack of protocol-level limits on chained statements, making the realistic blast radius include full read/write/delete capabilities on the database [4].

Mitigation

The vulnerability is fixed in postgrex version 0.22.2 [1][2]. The fix, visible in commit 7cdedbd, introduces a quote_channel/1 helper that doubles double-quotes inside channel names and also validates that channel names do not contain null bytes and do not exceed 63 bytes [3]. Users should upgrade to the latest version or, as a workaround, sanitize any user-supplied channel names by rejecting strings containing double-quotes or null bytes [4].

AI Insight generated on May 18, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Elixir Ecto/Postgrexreferences2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)range: >=0.16.0, <0.22.2

Patches

0

No patches discovered yet.

Vulnerability mechanics

AI mechanics synthesis has not run for this CVE yet.

References

4

News mentions

0

No linked articles in our index yet.