CVE-2025-29744: pg-promise · n/a
Affects pg-promiseSource CVE Database V5
Not known to be exploited · CVSS 5.4 Medium : upgrade to 11.5.5 when convenient.
Data as of 26 Oct 2026, 07:57 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 12% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 11.5.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:NExploitation evidence
Disclosed: evidence found.
CVE published 12 Jun 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-26.
What to do
Upgrade pg-promise to 11.5.5.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
npmpg-promisepkg:npm/pg-promiseOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
To mitigate this vulnerability effectively, European organizations should: 1) Immediately upgrade all instances of pg-promise to version 11.5.5 or later, where the vulnerability is fixed. 2) Conduct a thorough audit of all Node.js applications using pg-promise to identify and remediate any unsafe handling of numeric inputs, especially negative numbers, in database queries. 3) Implement strict input validation and sanitization at the application layer to ensure that only expected data types and value ranges are accepted before passing parameters to the database layer. 4) Employ parameterized queries and prepared statements consistently to prevent injection attacks, even if the underlying library has vulnerabilities. 5) Monitor database query logs for anomalous or suspicious queries that could indicate attempted exploitation. 6) Use Web Application Firewalls (WAFs) with rules tailored to detect and block SQL Injection attempts targeting PostgreSQL syntax. 7) Educate development teams about secure coding practices related to database interactions, emphasizing the risks of improper input handling. 8) Review and tighten database user permissions to follow the principle of least privilege, limiting the potential damage from any successful injection. These steps go beyond generic advice by focusing on both immediate patching and systemic improvements in input handling and monitoring.
Description
pg-promise before 11.5.5 is vulnerable to SQL Injection due to improper handling of negative numbers.