PostgreSQL Quoting APIs SQL Injection Vulnerability

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

• vendor PostgreSQL.org PostgreSQLversion unspecified

How to fix CVE-2025-1094

• Recommended remediation

  9 related fix commits linked. Confirm the fix covers your edition and version.

• Official advisories

  • CVE.org · cve.org
  • FIRST EPSS · first.org
  • VulnCheck KEV · vulncheck.com

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Technology hubs

Code

The project this record applies to. Exploit listings stay in References.

No public source repository is identified for this product.

Related Odoo Git fixes

Quoted Community commit messages that cite this CVE. Presence of a commit is not proof that every edition or backport includes the fix. Enterprise proprietary diffs are never shown here. Timeline

• Feb 16, 2025 · referenced

  In fmtIdEnc(), handle failure of enlargePQExpBuffer().

  In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Coverity complained that we weren't doing that, and it's right. This fix just makes fmtIdEnc() honor the general convention that OOM causes a PQExpBuffer to become marked "broken", without any immediate error. In the pretty-unlikely case that we actually did hit OOM here, the end result would be to return an empty string to the caller, probably resulting in invalid SQL syntax in an issued command (if nothing else went wrong, which is even more unlikely). It's tempting to throw an "out of memory" error if the buffer becomes broken, but there's not a lot of point in doing that only here and not in hundreds of other PQExpBuffer-using places in pg_dump and similar callers. The whole issue could do with some non-time-crunched redesign, perhaps. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking…

  https://github.com/postgres/postgres/commit/a7f95859ef7763ffb7f87894553ab25f5268f33c

• Feb 15, 2025 · referenced

  Make escaping functions retain trailing bytes of an invalid character.

  Make escaping functions retain trailing bytes of an invalid character. Instead of dropping the trailing byte(s) of an invalid or incomplete multibyte character, replace only the first byte with a known-invalid sequence, and process the rest normally. This seems less likely to confuse incautious callers than the behavior adopted in 5dc1e42b4. While we're at it, adjust PQescapeStringInternal to produce at most one bleat about invalid multibyte characters per string. This matches the behavior of PQescapeInternal, and avoids the risk of producing tons of repetitive junk if a long string is simply given in the wrong encoding. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking those fixes. Author: Andres Freund Reported-by: Jeff Davis Discussion: https://postgr.es/m/20250215012712.45@rfd.leadboat.com Backpatch-through: 13

  https://github.com/postgres/postgres/commit/9f45e6a91d8460ac0b1f30e6ae3eefb185b8d0ab

• Feb 10, 2025 · referenced

  Adapt appendPsqlMetaConnect() to the new fmtId() encoding expectations.

  Adapt appendPsqlMetaConnect() to the new fmtId() encoding expectations. We need to tell fmtId() what encoding to assume, but this function doesn't know that. Fortunately we can fix that without changing the function's API, because we can just use SQL_ASCII. That's because database names in connection requests are effectively binary not text: no encoding-aware processing will happen on them. This fixes XversionUpgrade failures seen in the buildfarm. The alternative of having pg_upgrade use setFmtEncoding() is unappetizing, given that it's connecting to multiple databases that may have different encodings. Andres Freund, Noah Misch, Tom Lane Security: CVE-2025-1094

  https://github.com/postgres/postgres/commit/5bf12323b6b8b05790aab6876555568898f4fc81

• Feb 10, 2025 · referenced

  Fix type in test_escape test

  Fix type in test_escape test On machines where char is unsigned this could lead to option parsing looping endlessly. It's also too narrow a type on other hardware. Found via Tom Lane's monitoring of the buildfarm. Reported-by: Tom Lane Security: CVE-2025-1094 Backpatch-through: 13

  https://github.com/postgres/postgres/commit/979205e47bdc094787b10142e84a7634f7c720dd

• Feb 10, 2025 · referenced

  docs: EUC_TW can be up to four bytes wide, not three

  docs: EUC_TW can be up to four bytes wide, not three Backpatch-through: 13 Security: CVE-2025-1094

  https://github.com/postgres/postgres/commit/32c34006b24bf7432c2d0f47da10492de7253d52

• Feb 10, 2025 · referenced

  Specify the encoding of input to fmtId()

  Specify the encoding of input to fmtId() This commit adds fmtIdEnc() and fmtQualifiedIdEnc(), which allow to specify the encoding as an explicit argument. Additionally setFmtEncoding() is provided, which defines the encoding when no explicit encoding is provided, to avoid breaking all code using fmtId(). All users of fmtId()/fmtQualifiedId() are either converted to the explicit version or a call to setFmtEncoding() has been added. This commit does not yet utilize the now well-defined encoding, that will happen in a subsequent commit. Reviewed-by: Noah Misch Reviewed-by: Tom Lane Backpatch-through: 13 Security: CVE-2025-1094

  https://github.com/postgres/postgres/commit/3e98c8ce50e46d58b91bf3ea806e995296dc5b91

• Feb 10, 2025 · referenced

  Add test of various escape functions

  Add test of various escape functions As highlighted by the prior commit, writing correct escape functions is less trivial than one might hope. This test module tries to verify that different escaping functions behave reasonably. It e.g. tests: - Invalidly encoded input to an escape function leads to invalidly encoded output - Trailing incomplete multi-byte characters are handled sensibly - Escaped strings are parsed as single statement by psql's parser (which derives from the backend parser) There are further tests that would be good to add. But even in the current state it was rather useful for writing the fix in the prior commit. Reviewed-by: Noah Misch Backpatch-through: 13 Security: CVE-2025-1094

  https://github.com/postgres/postgres/commit/ac00ff1c96081ea4981f1001209b4719f5cd82ac

• Feb 10, 2025 · referenced

  Fix handling of invalidly encoded data in escaping functions

  Fix handling of invalidly encoded data in escaping functions Previously invalidly encoded input to various escaping functions could lead to the escaped string getting incorrectly parsed by psql. To be safe, escaping functions need to ensure that neither invalid nor incomplete multi-byte characters can be used to "escape" from being quoted. Functions which can report errors now return an error in more cases than before. Functions that cannot report errors now replace invalid input bytes with a byte sequence that cannot be used to escape the quotes and that is guaranteed to error out when a query is sent to the server. The following functions are fixed by this commit: - PQescapeLiteral() - PQescapeIdentifier() - PQescapeString() - PQescapeStringConn() - fmtId() - appendStringLiteral() Reported-by: Stephen Fewer Reviewed-by: Noah Misch Reviewed-by: Tom Lane Backpatch-through: 13 Securi…

  https://github.com/postgres/postgres/commit/5dc1e42b4fa6a4434afa7d7cdcf0291351a7b873

• Feb 10, 2025 · referenced

  Add pg_encoding_set_invalid()

  Add pg_encoding_set_invalid() There are cases where we cannot / do not want to error out for invalidly encoded input. In such cases it can be useful to replace e.g. an incomplete multi-byte characters with bytes that will trigger an error when getting validated as part of a larger string. Unfortunately, until now, for some encoding no such sequence existed. For those encodings this commit removes one previously accepted input combination - we consider that to be ok, as the chosen bytes are outside of the valid ranges for the encodings, we just previously failed to detect that. As we cannot add a new field to pg_wchar_table without breaking ABI, this is implemented "in-line" in the newly added function. Author: Noah Misch Reviewed-by: Andres Freund Backpatch-through: 13 Security: CVE-2025-1094

  https://github.com/postgres/postgres/commit/4dc28963533704fc7dd922b9447467466a233d89

Timeline

Detection, updates, and resolution for this record.

1. Feb 13, 2025 · VulnCheck KEV

   Detected

   Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns. Specifically, SQL injection requires the application to use the function result to construct input to psql, the PostgreSQL interactive terminal. Similarly, imp

2. Feb 13, 2025 · CISA KEV

   Known exploited

   Apply remediations or mitigations per vendor instructions or discontinue use of the product if remediation or mitigations are unavailable.

Sources

• CVE.orgVulnerability recordCVE-2025-1094

  Official CVE identifier

  cve.org
• FIRST EPSSExploitation probabilityCVE-2025-1094

  30-day exploitation probability 90.0%

  first.org
• VulnCheck KEVConfirmed exploitationCVE-2025-1094

  Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns. Specifically, SQL injection requires th

  vulncheck.com

References

• VulnCheck exploitation evidence · greynoise.io
• VulnCheck exploitation evidence · loginsoft.com
• VulnCheck exploitation evidence · rapid7.com

Freshness

Last verified in this catalog Oct 18, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.