CWE-242
Use of Inherently Dangerous Function
BaseDraftLikelihood: High
Description
The product calls a function that can never be guaranteed to work safely.
Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account. The gets() function is unsafe because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer. Similarly, the >> operator is unsafe to use when reading into a statically-allocated character array because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the >> operator and overflow the destination buffer.
Hierarchy (View 1000)
Parents
Children
none
CVEs mapped to this weakness (2)
| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-6477 | Hig | 0.57 | 8.8 | 0.00 | May 14, 2026 | Use of inherently dangerous function PQfn(..., result_is_int=0, ...) in PostgreSQL libpq lo_export(), lo_read(), lo_lseek64(), and lo_tell64() functions allows the server superuser to overwrite a client stack buffer with an arbitrarily-large response. Like gets(), PQfn(..., result_is_int=0, ...) stores arbitrary-length, server-determined data into a buffer of unspecified size. Because both the \lo_export command in psql and pg_dump call lo_read(), the server superuser can overwrite pg_dump or psql stack memory. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected. | |
| CVE-2017-0904 | Hig | 0.46 | 8.1 | 0.01 | Nov 13, 2017 | The private_address_check ruby gem before 0.4.0 is vulnerable to a bypass due to use of Ruby's Resolv.getaddresses method, which is OS-dependent and should not be relied upon for security measures, such as when used to blacklist private network addresses to prevent server-side request forgery. |