CWE-253Base

Incorrect Check of Function Return Value

Incomplete in the CWE catalog · 24 CVEs mapped

24
CVEs mapped
7.2
Median CVSS
What it is

The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.

Recent examples
7.2cvss
CVE-2026-15686

CVE-2026-15686 - HIGH Severity Vulnerability

Adminer multi_query Incorrect Check of Function Return Value Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Adminer. Authentication is required to exploit this vulnerability. The specific flaw exists within the multi_query method. The issue results from an incorrect check of a function return value. An attacker can leverage this vulnerability to execute code in the context of the web server. Was ZDI-CAN-28201.

HIGHno explanation yet
1%
epss
5.9cvss
CVE-2026-59847

CVE-2026-59847 - MEDIUM Severity Vulnerability

A flaw was found in libssh. Incorrect AES-GCM finalization checks in builds using the OpenSSL backend can effectively remove integrity protection, allowing an in-path attacker to modify plaintext on the wire without detection.

MEDIUMno explanation yet
0%
epss
7.8cvss
CVE-2026-53090

CVE-2026-53090 - HIGH Severity Vulnerability

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.

HIGHno explanation yet
0%
epss
The record
Technical detail
CWE ID
CWE-253
Abstraction
Base
Structure
Simple
Status
Incomplete
References (1)