What is the CVSS score of CVE-2026-41075?

CVE-2026-41075 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Request Tracker are affected by CVE-2026-41075?

Request Tracker (RT) versions 5.0.0-5.0.9 and 6.0.0-6.0.2 contain a SQL injection vulnerability (CVSS 8.8) accessible to any authenticated user, enabling unauthorized database access and ticket data…. A patch is available.

How to fix or mitigate CVE-2026-41075?

Within 24 hours: Inventory all Request Tracker deployments and identify systems running RT 5.0.0-5.0.9 or RT 6.0.0-6.0.2; assess the sensitivity of ticket data and user base. Within 7 days: Upgrade to patched versions-RT 5.0.10 for the 5.0.x track or RT 6.0.3 for the 6.0.x track. Within 30 days: Verify patches across all systems, audit database query logs for SQL injection exploitation attempts, and review access logs for unauthorized ticket reads during the vulnerability exposure window.

Request Tracker CVE-2026-41075

HIGH

SQL Injection (CWE-89)

2026-05-22 GitHub_M

SQLi Rt Bestpractical

8.8

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.8 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from Vendor (GitHub_M) · only source for this CVE.

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 22, 2026 - 21:45 vuln.today

Analysis Generated

May 22, 2026 - 21:45 vuln.today

DescriptionCVE.org

RT is an open source, enterprise-grade issue and ticket tracking system. Versions 5.0.0 through 5.0.9 and 6.0.0 through 6.0.2 contain an SQL injection vulnerability. An authenticated user can craft input that is incorporated into database queries without proper validation, potentially allowing them to read or modify data in the RT database. This issue has been fixed in versions 5.0.10 and 6.0.3. If developers are unable to upgrade immediately, they can temporarily work around this issue by restricting RT account access to trusted users.

AnalysisAI

Authenticated SQL injection in Best Practical's Request Tracker (RT) ticketing system affects versions 5.0.0-5.0.9 and 6.0.0-6.0.2 via the entry_aggregator parameter in the JSON search endpoint, allowing any logged-in RT user to read or modify arbitrary data in the underlying database. The flaw was disclosed alongside the rt-5.0.10/6.0.3 release on 2026-05-20 and carries CVSS 8.8 due to high impact across confidentiality, integrity, and availability. No public exploit identified at time of analysis, and the vulnerability is not listed in CISA KEV.

Technical ContextAI

Request Tracker is a widely deployed Perl-based enterprise ticketing platform from Best Practical (CPE cpe:2.3:a:bestpractical:rt). The defect is a classic CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) where the entry_aggregator query parameter - used by RT's JSON-based ticket search to control how multiple search clauses are AND/OR-joined - is concatenated into a dynamically constructed SQL statement without sufficient validation or parameterization. Because RT stores tickets, user records, transactions, and ACL data in the same RDBMS (MySQL/PostgreSQL/Oracle/MariaDB are all supported), a successful injection reaches the entire RT data model.

RemediationAI

Vendor-released patch: upgrade to RT 5.0.10 (for the 5.0.x branch) or RT 6.0.3 (for the 6.0.x branch), both published 2026-05-20 and available from https://download.bestpractical.com/pub/rt/release/ and the GitHub release pages. If immediate upgrade is not possible, the vendor's documented workaround is to restrict RT account access to trusted users only - practically meaning disabling self-registration, auditing the existing user table, and tightening group memberships - which preserves functionality for internal staff but breaks customer-facing or anonymous-submission workflows. Additional defense-in-depth options include placing RT behind a reverse-proxy WAF rule that rejects unexpected entry_aggregator values on the JSON search endpoint and enabling database query logging to detect anomalous statements, accepting the trade-off of additional log volume and potential false-positive blocks on legitimate complex searches.