A remote code execution vulnerability was found within the pg module when the remote database or query specifies a specially crafted column
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 2.11.2, 3.6.4, 4.5.7, 5.2.1, 6.0.5, and 6 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 1 proof of concept on GitHub
Summary
A remote code execution vulnerability was found within the pg module when the remote database or query specifies a specially crafted column name. There are 2 likely scenarios in which one would likely be vulnerable. 1) Executing unsafe, user-supplied sql which contains a malicious column name. 2) Connecting to an untrusted database and executing a query which returns results where any of the column names are malicious.
Timeline
- CVE published
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- HackerOne pg node module
< 2.11.2 || >= 3.0.0 < 3.6.4 || >= 4.0.0 < 4.5.7 || >= 5.0.0 < 5.2.1 || >= 6.0.0 < 6.0.5 || >= 6.1.0 < 6.1.6 || >= 6.2.0 < 6.2.5 || >= 6.3.0 < 6.3.3 || >= 6.4.0 < 6.4.2 || >= 7.0.0 < 7.0.2 || >= 7.1.0 < 7.1.2
- pgnpm
fixed in 2.11.2
- pgnpm
From 3.0.0 · fixed in 3.6.4
- pgnpm
From 4.0.0 · fixed in 4.5.7
- pgnpm
From 5.0.0 · fixed in 5.2.1
- pgnpm
From 6.0.0 · fixed in 6.0.5
- pgnpm
From 6.1.0 · fixed in 6.1.6
- pgnpm
From 6.2.0 · fixed in 6.2.5
- pgnpm
From 6.3.0 · fixed in 6.3.3
- pgnpm
From 6.4.0 · fixed in 6.4.2
- pgnpm
From 7.0.0 · fixed in 7.0.2
- pgnpm
From 7.1.0 · fixed in 7.1.2