FKIE_CVE-2026-58225
Vulnerability from fkie_nvd - Published: 2026-07-10 11:16 - Updated: 2026-10-24 23:10
Severity
Summary
SQL Injection vulnerability in elixir-ecto postgrex allows an attacker who can influence a LISTEN channel name to inject SQL into the reconnect replay query, causing a denial of service of the notification connection.
Postgrex.Notifications sanitizes channel names with quote_channel/1, which doubles double quotes so the name is safe inside a double-quoted identifier. This protects the single-statement LISTEN and UNLISTEN paths. On every (re)connect, however, handle_connect/1 replays all registered channels at once by concatenating their LISTEN statements and wrapping them in a dollar-quoted anonymous code block (DO $$BEGIN ... END$$). quote_channel/1 does not escape the $$ dollar-quote delimiter that opens and closes this block.
The listen/3 guards only reject null bytes and names longer than 63 bytes, so a channel name containing $$ passes validation unchanged. Once such a name is embedded, its $$ prematurely terminates the outer dollar-quoted string and PostgreSQL parses the remainder as additional top-level statements. Because handle_connect/1 runs on every (re)connect, the malformed replay query is rejected each time and the notification connection never re-establishes its subscriptions, silently dropping notifications for every channel sharing that connection.
An application is affected when it passes untrusted input (for example a tenant or user identifier) as a channel name to Postgrex.Notifications.listen/3. The double-quote doubling prevents forming a fully valid injected statement, so arbitrary SQL execution is not possible, but the corrupted query reliably breaks the shared notification connection for all tenants, resulting in denial of service.
This issue affects postgrex: from 0.16.0 before 0.22.3.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-ecto:postgrex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Postgrex.Notifications\u0027"
],
"packageName": "postgrex",
"packageURL": "pkg:hex/postgrex",
"product": "postgrex",
"programFiles": [
"lib/postgrex/notifications.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Postgrex.Notifications\u0027:handle_connect/1"
},
{
"name": "\u0027Elixir.Postgrex.Notifications\u0027:listen/3"
}
],
"repo": "https://github.com/elixir-ecto/postgrex",
"vendor": "elixir-ecto",
"versions": [
{
"lessThan": "0.22.3",
"status": "affected",
"version": "0.16.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-ecto:postgrex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Postgrex.Notifications\u0027"
],
"packageName": "elixir-ecto/postgrex",
"packageURL": "pkg:github/elixir-ecto/postgrex",
"product": "postgrex",
"programFiles": [
"lib/postgrex/notifications.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Postgrex.Notifications\u0027:handle_connect/1"
},
{
"name": "\u0027Elixir.Postgrex.Notifications\u0027:listen/3"
}
],
"repo": "https://github.com/elixir-ecto/postgrex",
"vendor": "elixir-ecto",
"versions": [
{
"lessThan": "795c6062f62c4394272ff4b89170688857b4f841",
"status": "affected",
"version": "266b530faf9bde094e31e0e4ab851f933fadc0f5",
"versionType": "git"
}
]
}
],
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "SQL Injection vulnerability in elixir-ecto postgrex allows an attacker who can influence a LISTEN channel name to inject SQL into the reconnect replay query, causing a denial of service of the notification connection.\n\nPostgrex.Notifications sanitizes channel names with quote_channel/1, which doubles double quotes so the name is safe inside a double-quoted identifier. This protects the single-statement LISTEN and UNLISTEN paths. On every (re)connect, however, handle_connect/1 replays all registered channels at once by concatenating their LISTEN statements and wrapping them in a dollar-quoted anonymous code block (DO $$BEGIN ... END$$). quote_channel/1 does not escape the $$ dollar-quote delimiter that opens and closes this block.\n\nThe listen/3 guards only reject null bytes and names longer than 63 bytes, so a channel name containing $$ passes validation unchanged. Once such a name is embedded, its $$ prematurely terminates the outer dollar-quoted string and PostgreSQL parses the remainder as additional top-level statements. Because handle_connect/1 runs on every (re)connect, the malformed replay query is rejected each time and the notification connection never re-establishes its subscriptions, silently dropping notifications for every channel sharing that connection.\n\nAn application is affected when it passes untrusted input (for example a tenant or user identifier) as a channel name to Postgrex.Notifications.listen/3. The double-quote doubling prevents forming a fully valid injected statement, so arbitrary SQL execution is not possible, but the corrupted query reliably breaks the shared notification connection for all tenants, resulting in denial of service.\n\nThis issue affects postgrex: from 0.16.0 before 0.22.3."
},
{
"lang": "es",
"value": "Vulnerabilidad de inyecci\u00f3n SQL en elixir-ecto postgrex permite a un atacante que puede influir en el nombre de un canal LISTEN inyectar SQL en la consulta de repetici\u00f3n de reconexi\u00f3n, causando una denegaci\u00f3n de servicio de la conexi\u00f3n de notificaci\u00f3n.\n\nPostgrex.Notifications sanea los nombres de los canales con quote_channel/1, que duplica las comillas dobles para que el nombre sea seguro dentro de un identificador entre comillas dobles. Esto protege las rutas LISTEN y UNLISTEN de una sola declaraci\u00f3n. En cada (re)conexi\u00f3n, sin embargo, handle_connect/1 reproduce todos los canales registrados a la vez concatenando sus declaraciones LISTEN y envolvi\u00e9ndolas en un bloque de c\u00f3digo an\u00f3nimo entre comillas de d\u00f3lar (DO $$BEGIN ... END$$). quote_channel/1 no escapa el delimitador de comillas de d\u00f3lar $$ que abre y cierra este bloque.\n\nLas guardas de listen/3 solo rechazan bytes nulos y nombres de m\u00e1s de 63 bytes, por lo que un nombre de canal que contenga $$ pasa la validaci\u00f3n sin cambios. Una vez que dicho nombre est\u00e1 incrustado, su $$ termina prematuramente la cadena externa entre comillas de d\u00f3lar y PostgreSQL analiza el resto como declaraciones de nivel superior adicionales. Debido a que handle_connect/1 se ejecuta en cada (re)conexi\u00f3n, la consulta de repetici\u00f3n malformada es rechazada cada vez y la conexi\u00f3n de notificaci\u00f3n nunca restablece sus suscripciones, descartando silenciosamente las notificaciones para cada canal que comparte esa conexi\u00f3n.\n\nUna aplicaci\u00f3n se ve afectada cuando pasa una entrada no confiable (por ejemplo, un identificador de inquilino o usuario) como nombre de canal a Postgrex.Notifications.listen/3. La duplicaci\u00f3n de comillas dobles impide formar una declaraci\u00f3n inyectada completamente v\u00e1lida, por lo que la ejecuci\u00f3n arbitraria de SQL no es posible, pero la consulta corrupta rompe de forma fiable la conexi\u00f3n de notificaci\u00f3n compartida para todos los inquilinos, lo que resulta en una denegaci\u00f3n de servicio.\n\nEste problema afecta a postgrex: desde 0.16.0 antes de 0.22.3."
}
],
"id": "CVE-2026-58225",
"lastModified": "2026-10-24T23:10:00.160",
"metrics": {
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 2.1,
"baseSeverity": "LOW",
"confidentialityRequirement": "NOT_DEFINED",
"exploitMaturity": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-58225",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-10T11:47:10.671088Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-07-10T11:16:36.300",
"references": [
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://cna.erlef.org/cves/CVE-2026-58225.html"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/ecto/security/advisories/GHSA-4mw9-4qgj-m97w"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/postgrex/commit/795c6062f62c4394272ff4b89170688857b4f841"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-58225"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/elixir-ecto/ecto/security/advisories/GHSA-4mw9-4qgj-m97w"
}
],
"sourceIdentifier": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-89"
}
],
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"type": "Secondary"
}
]
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.