CVE-2026-76240: stigmem Postgres SQL Injection via Schema Identifier
stigmem-node 0.9.0a1 interpolates Postgres backend schema identifiers into SQL strings without defensive quoting. In the affected code path the schema value is operator-controlled, but the unsafe pattern could allow SQL injection if a schema name were derived from tenant, request, or user input. Fixed in 0.9.0a2, which adds identifier quoting and validation. As a workaround, only configure schema names from trusted deployment configuration.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
stigmem-nodeto a version that resolves this vulnerability.Fixed in 0.9.0a2 - Compensating control
As a workaround, only configure schema names from trusted deployment configuration (do not derive schema names from tenant, request, or user input).
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Deployments of stigmem-node 0.9.0a1 using the Postgres backend are exposed when the configured schema identifier can be influenced by tenant, request, or other user-controlled input. The affected code path treats the schema value as operator-controlled.
What must an attacker control to exploit it?
An attacker would need influence over a schema name that reaches the Postgres backend SQL construction path. The risk arises because schema identifiers are interpolated into SQL strings without defensive quoting.
Are default deployments affected?
The available information does not establish whether the default configuration uses a Postgres schema value that is user-influenced. Risk depends on whether schema names are derived from untrusted input.
What can be done if updating is not immediately possible?
Configure schema names only from trusted deployment configuration. Do not derive schema identifiers from tenant, request, or user input.
How can I remediate this issue?
Upgrade to stigmem-node 0.9.0a2, which adds identifier quoting and validation.