Listen to this Post
How the mentioned CVE works (around 20 lines):
The vulnerability resides in `Postgrex.Notifications.listen/3` and unlisten/3. These functions interpolate the `channel` argument directly into a PostgreSQL `LISTEN “…”` or `UNLISTEN “…”` simple query without escaping double‑quote (") characters. PostgreSQL escapes a double‑quote inside a quoted identifier by doubling it (""), but Postgrex does not perform this transformation. An attacker who can control the channel name (e.g., via a tenant ID, topic slug, or any user input) can inject a `”` character to prematurely close the quoted identifier. Everything after that `”` is parsed as arbitrary SQL on the same connection. Because LISTEN/UNLISTEN are sent as simple queries (not using the extended protocol), multi‑statement payloads are allowed. The attacker can chain commands such as ; CREATE TABLE …, ; DROP …, ; CREATE ROLE …, or any SQL that the application’s database role can execute. No escaping, parameterisation, or protocol‑level guard protects the channel argument. The notifications connection runs with the same DB user as the rest of the application, so a successful injection yields full read/modify/destroy capabilities over all data accessible to that role.
dailycve form (3 words max per line):
Platform: Postgrex Elixir
Version: <0.22.2
Vulnerability: SQL injection
Severity: Critical
Date: 2024-12-10
Prediction: 2024-12-10 (v0.22.2)
What Undercode Say:
Analytics:
Check installed Postgrex version mix deps | grep postgrex Simulate vulnerable listen call channel = "\"; DROP TABLE users; --" Postgrex.Notifications.listen(pid, channel, fn _ -> nil end) Log all LISTEN queries from PostgreSQL sudo tail -f /var/log/postgresql/postgresql-.log | grep LISTEN Detect attempt with quote in channel name grep -r "Postgrex.Notifications.listen" ./lib --include=".ex" | grep -v "sanitize"
Exploit:
Craft a channel name containing a double‑quote followed by malicious SQL. Example:
`” ; DELETE FROM sessions WHERE true; –`
When interpolated into `LISTEN “…”`, it becomes:
`LISTEN “” ; DELETE FROM sessions WHERE true; –“`
The first `”` closes the empty channel identifier, then the semicolon ends the `LISTEN` statement, allowing execution of DELETE FROM sessions. The remainder (--") is commented out. Any SQL statement chain works (e.g., ; CREATE TABLE stolen(data text); INSERT INTO stolen SELECT current_user, FROM sensitive_table).
Protection from this CVE:
- Upgrade to Postgrex v0.22.2 or later (official fix).
- Sanitise channel names if upgrade is impossible – reject any string containing `”` or null byte (
\0):if String.contains?(channel_name, ["\"", "\0"]) do raise "invalid channel name" end
- Use parameterised queries – not applicable for
LISTEN/UNLISTEN, so upgrade is the only complete fix. - Restrict database role – ensure the notifications connection uses a role with minimal privileges (e.g., no
CREATE,DROP, or access to sensitive tables). This mitigates but does not eliminate the risk.
Impact:
Successful SQL injection on the notifications connection gives the attacker the ability to read, modify, or destroy any data accessible to the application’s database user. Because simple queries allow multi‑statement execution, an attacker can chain data exfiltration, privilege escalation (e.g., CREATE ROLE), or destructive commands. The blast radius includes all tables, schemas, and database objects the connected role can reach. No authentication bypass is needed – only control over the channel name. Applications using `Postgrex.Notifications` with user‑supplied channel names (e.g., pub/sub bridges, tenant‑based notifications) are directly vulnerable. Ecto is not affected by default, but any dependency that uses `Postgrex.Notifications` must be audited.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
