Bug 2499934 (CVE-2026-15043)

Summary: CVE-2026-15043 DBI::SQL::Nano: DBI::SQL::Nano: Incorrect SQL operator evaluation can lead to incorrect data filtering.
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in DBI::SQL::Nano, a mini-SQL engine for Perl. This vulnerability occurs because the engine incorrectly evaluates SQL operators for text comparisons, specifically inverting the logic for "less than or equal to" and "greater than or equal to" operations. This can lead to applications that rely on these comparisons for filtering data, such as for policy or authorization, silently returning incorrect results. The impact of this flaw depends on how an application uses these SQL queries.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2501292    
Bug Blocks:    

Description OSIDB Bzimport 2026-07-14 10:01:48 UTC 
DBI::SQL::Nano versions from 1.42 before 1.651 for Perl have inverted <= and >= SQL operators on text.

DBI::SQL::Nano, DBI's built-in mini-SQL engine, evaluated WHERE predicates incorrectly in some cases. In the non-numeric string branch of the is_matched method, <= was evaluated using Perl's ge operator, and >= was evaluated using Perl's le operator.

SQL::Nano is the fallback query engine for DBI's file-backed drivers (DBD::File, DBD::DBM, CSV-style drivers) whenever SQL::Statement is not installed, and is forced whenever DBI_SQL_NANO=1. Queries over such tables use these predicates directly.

The impact depends on the context. Where an application relies on a WHERE clause to filter file-backed data for policy or authorization, an inverted <=/>= comparison silently returns the wrong rows.