VYPR

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 (3)

  • CVE-2026-6477HigMay 14, 2026
    risk 0.57cvss 8.8epss 0.00

    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(...,…

  • CVE-2017-0904HigNov 13, 2017
    risk 0.46cvss 8.1epss 0.02

    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…

  • CVE-2017-1002157Jan 10, 2019
    risk 0.00cvss epss 0.03

    modulemd 1.3.1 and earlier uses an unsafe function for processing externally provided data, leading to remote code execution.