GHSA-rvxj-7f72-mhrx: EGroupware has SQL Injection in Nextmatch Filter Processing
Summary**Critical Authenticated SQL Injection in Nextmatch Widget Filter Processing**A critical SQL Injection vulnerability exists in the core components of EGroupware, specifically in the `Nextmatch` filter processing. The flaw allows authenticated attackers to inject arbitrary SQL commands into the `WHERE` clause of database queries. This is achieved by exploiting a PHP type juggling issue where JSON decoding converts numeric strings into integers, bypassing the `is_int()` security check used by the application.Details**Root Cause Analysis**
The vulnerability exists in how the database abstraction layer (`Api\Db`) and high-level storage classes (`Api\Storage\Base`, `infolog_so`) process the `col_filter` array used in "Nextmatch" widgets.The application attempts to validate input using `is_int($key)` to determine if an array key represents a raw SQL fragment that should be trusted. However, when processing JSON-based POST requests, PHP's `json_decode` automatically converts numeric string keys (e.g., `"0"`) into native integers.Consequently, an attacker can send a JSON payload with an associative array containing numeric keys. The application interprets these keys as integers (`is_int` returns true) and blindly appends the associated values - containing malicious SQL - directly to the query.**Vulnerable Code Locations****File:** `sources/egroupware/api/src/Db.php` (Approx. Line 1776)
Method: `column_data_implode`**File:** `sources/egroupware/api/src/Storage/Base.php` (Approx. Line 1134)
Method: `parse_search`PoCThe vulnerability was on a local Docker instance and confirmed (read-only) on the public demo instance ([demo.egroupware.net](http://demo.egroupware.net/)).**Automated Exploit Script:**
The following script automates the login, exec_id extraction, and data exfiltration via Error-Based SQL Injection.**Proof of Verification** on [demo.egroupware.net](http://demo.egroupware.net/):The script was executed against ther public demo to confirm exploitability in a production-like environment (read-only).
<img width="773" height="393" alt="image" src="https://github.com/user-attachments/assets/ae97ea37-21fa-4718-98f5-f7f9696f3c2e" />**Impact:**
Attackers with low-privileged access can fully compromise the database. This allows for:**Confidentiality Loss:** Reading sensitive data (e.g., password hashes, session tokens, personal contact details, configuration secrets).**Integrity Loss:** Modifying or deleting arbitrary data within the application.**Availability Loss:** Potential to drop tables or corrupt data.Remediation**1. Input Validation (Whitelisting)**
Do not rely solely on `is_int()` for security decisions when handling external input, especially JSON data where keys can be numeric strings. Implement a strict **whitelist (allowlist)** of allowed column names for filtering in `Nextmatch` widgets. If the key/column is not in the whitelist, reject the request.**2. Parameter Binding**
Ensure all filter values are bound as parameters (prepared statements) rather than being concatenated directly into the SQL string.**3. Strict Type Checking**
When processing JSON input, ensure that keys are strictly checked against expected types (e.g., using `===` for strict comparison or `filter_var`) before being used in SQL generation logic.CreditsReported by Łukasz Rybak
CVSS v4.0: 8.7