CVE-2026-34717
SQL Injection in OpenProject Reporting Module Allows Data Manipulation
Publication date: 2026-04-02
Last updated on: 2026-04-21
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openproject | openproject | to 17.2.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows any authenticated user with access to cost reports to exploit SQL Injection, enabling them to read or modify any data in the database. This can lead to unauthorized access, data integrity compromise, and availability issues.
Such unauthorized access and potential data breaches can negatively impact compliance with data protection regulations like GDPR and HIPAA, which require strict controls over data confidentiality, integrity, and availability.
Therefore, until patched, this vulnerability poses a significant risk to meeting compliance requirements related to protecting sensitive data.
Can you explain this vulnerability to me?
CVE-2026-34717 is a critical SQL Injection vulnerability in OpenProject, an open-source project management software. The issue occurs in the "=n" operator within the file modules/reporting/lib/report/operator.rb, where user input is embedded directly into SQL WHERE clauses without proper parameterization or sanitization.
Specifically, the function parse_number_string only removes locale-specific delimiters but does not neutralize SQL metacharacters, allowing malicious input to be executed as part of SQL commands. This flaw enables attackers to inject unauthorized SQL code through cost report filter parameters.
The vulnerability was patched in OpenProject version 17.2.3 by changing the code to use parameterized queries, which treat user input as data rather than executable SQL.
How can this vulnerability impact me? :
This vulnerability allows any authenticated user with access to cost reports to exploit the SQL Injection flaw to read or modify any data in the database.
The impact includes potential compromise of data confidentiality, integrity, and availability, as attackers can execute unauthorized SQL commands to manipulate or extract sensitive information.
Given the CVSS v3.1 base score of 9.9 (Critical), the risk is very high, with low attack complexity and no user interaction required.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability arises from improper sanitization of user input in the "=n" operator within OpenProject's cost reporting feature, specifically in the file modules/reporting/lib/report/operator.rb at line 177.
To detect if your system is vulnerable, first verify the OpenProject version. Versions prior to 17.2.3 are affected.
You can check the installed OpenProject version by running a command on the server hosting OpenProject, for example:
- grep VERSION /path/to/openproject/lib/open_project/version.rb
- or check the version via the OpenProject web interface or API if available.
To detect exploitation attempts on your system or network, monitor logs for unusual or malformed SQL queries related to cost report filters, especially those containing unexpected SQL metacharacters or injection patterns.
You may also search your application logs or database logs for queries containing suspicious input patterns that resemble SQL injection attempts.
What immediate steps should I take to mitigate this vulnerability?
The primary and immediate mitigation step is to upgrade OpenProject to version 17.2.3 or later, where this SQL Injection vulnerability has been fixed.
If upgrading immediately is not possible, restrict access to the cost reporting features to trusted users only, as exploitation requires authenticated access.
Additionally, monitor and audit database queries and application logs for suspicious activity related to cost report filters.
The underlying fix involves changing the vulnerable code to use parameterized queries, for example:
- query.where(["#{field} = ?", parse_number_string(value)])
This ensures user input is treated as data, not executable SQL code, preventing injection.