A flaw in the way Postgrex.Notifications builds reconnection queries allows an attacker who can influence a LISTEN channel name to insert unescaped dollar-quote delimiters. The injected delimiters terminate the outer DO $$ block, causing PostgreSQL to parse the remainder as unrelated statements and to reject the replayed LISTEN commands. Because the vulnerable path cannot inject arbitrary SQL, the immediate visible effect is that the shared notification connection never re‑establishes its subscriptions, silently dropping all notifications for channels sharing that connection. The weakness is a classic SQL injection scenario (CWE‑89) that, in this context, manifests as a denial of service rather than data exfiltration or code execution.

The vulnerability affects the elixir‑ecto Postgrex library, specifically versions from 0.16.0 up to but not including 0.22.3. Any application using Postgrex.Notifications.listen/3 with untrusted input for the channel name is susceptible.

The CVSS base score is 2.1, indicating low severity, and the EPSS score is unavailable. The issue is not listed in the CISA KEV catalog. The likely attack vector is application‑controlled input; an attacker controlling a tenant or user identifier that is passed untrusted to listen/3 can trigger the denial of service. Once triggered, the problem persists on every reconnect until the problematic channel name is removed or the code is patched. The risk to confidentiality or integrity is low, but the availability impact can be significant for workflows relying on notifications.