CVE-2025-61464
BaseFortify
Publication date: 2025-10-23
Last updated on: 2025-10-30
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| sir | gnuboard | to 4.36.04 (inc) |
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
Can you explain this vulnerability to me?
CVE-2025-61464 is a critical second-order SQL injection vulnerability in Gnuboard4 (version 4.36.04 and before) found in the file bbs/search.php. It occurs because user input can overwrite server-side variables, specifically the $search_table array, which is used directly as a table identifier in SQL queries without proper validation or quoting. This allows attackers to inject malicious SQL commands into the FROM clause of queries, leading to data leakage and logic bypass. The vulnerability arises from unsafe handling of user-controlled array elements combined with variable pollution, enabling error-based and blind SQL injection attacks that can exfiltrate sensitive data such as user passwords. [1]
How can this vulnerability impact me? :
This vulnerability can have severe impacts including unauthorized access to sensitive data by exfiltrating information such as user passwords from the database. Attackers can manipulate SQL queries to bypass application logic, perform error-based and blind SQL injection attacks, and potentially compromise the integrity and confidentiality of the system. This can lead to data breaches, loss of user trust, and further exploitation of the affected system. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to reproduce the SQL injection using crafted POST requests targeting the `search_table` parameter in `bbs/search.php`. For example, sending a POST request with payloads like `z2_0 order by updatexml(1,concat(0x7e,(select mb_password from g4_member where mb_no=1),0x7e),1)#` can trigger error-based SQL injection revealing sensitive data. Detection can be done by monitoring web server logs for suspicious POST requests with unusual `search_table` values or by using tools like curl to manually test the injection point. Example command to test via curl: `curl -X POST -d "search_table[0]=z2_0 order by updatexml(1,concat(0x7e,(select mb_password from g4_member where mb_no=1),0x7e),1)#" https://your-target-site/bbs/search.php`. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include: 1) Prevent variable pollution by unsetting and rebuilding sensitive arrays before use, e.g., `unset($search_table, $read_level, $table_index); $search_table = array(); $read_level = array(); $table_index = 0;`. 2) Enforce strict whitelist validation and quoting of table identifiers, allowing only alphanumeric characters and underscores with length restrictions, and wrapping identifiers in backticks, e.g., `if (!preg_match('/^\w{1,30}$/', $tbl)) continue; $tmp_write_table = "`{$g4['write_prefix']}{$tbl}`";`. 3) Enforce integer casting for indices and paging variables and avoid using `extract($_REQUEST)`-style patterns, e.g., `$page = (int)($page ?: 1); $rows = (int)$srows ?: 10; $from_record = (int)$from_record; $table_index = isset($table_index) ? (int)$table_index : 0;`. Applying these patches will prevent SQL injection exploitation. [1]