CVE-2022-1429

What it actually does

The flaw is a SQL injection vulnerability in Pimcore's GridHelperService.php before version 10.3.6. Unsafely handled user-controlled input can be incorporated into backend database queries, allowing a remote attacker to alter query logic and read data that should not be exposed. The assigned CVSS vector indicates network exploitation with low complexity, no required privileges, no user interaction, and primary impact to confidentiality rather than integrity or availability.

Why it matters to the business

Successful exploitation can expose sensitive business data stored in Pimcore, such as customer records, product information, content data, user metadata, or other database-backed application data. Because public exploit code is available and the EPSS score is high, internet-accessible or unpatched Pimcore deployments should be treated as high-priority remediation targets even though this is not currently listed in CISA KEV and is not known to be ransomware-associated.

How an attack unfolds

An attacker identifies a Pimcore instance running a vulnerable version prior to 10.3.6 and targets functionality backed by GridHelperService.php. They send crafted HTTP requests containing SQL metacharacters or query-manipulation syntax in parameters processed by grid-related backend logic. If the input is concatenated into SQL without proper parameterization, the database interprets attacker-controlled content as part of the query. The attacker can then enumerate database structure, confirm injectable parameters through error behavior or response differences, and extract sensitive records using SQL injection techniques. In most cases, evidence appears in web access logs, application exception logs, database error logs, and unusual database queries associated with Pimcore grid endpoints.

How to fix it

Upgrade Pimcore to version 10.3.6 or later. If tracking the upstream Git repository directly, ensure the code includes fixed commit 1b805b9748fc0214bb19020d1051448431ba9e69. Remove or isolate unsupported Pimcore versions prior to 10.3.6. If immediate upgrade is not possible, restrict external access to Pimcore administrative and grid-related routes, place the application behind strong authentication and network controls, and use a WAF rule set capable of blocking common SQL injection patterns. Mitigations should be treated as temporary because the durable fix is the patched Pimcore code that safely handles query construction.

How to confirm the fix worked

Confirm the installed Pimcore version is 10.3.6 or later, or verify that the source tree contains commit 1b805b9748fc0214bb19020d1051448431ba9e69. Review dependency manifests, container images, deployed application code, and vendor directories to ensure no vulnerable Pimcore copy remains in production, staging, or internet-facing test systems. Validate that GridHelperService.php matches the patched upstream implementation. Perform a safe authenticated or unauthenticated web application security test, as appropriate for the deployment, to confirm SQL metacharacters in grid-related parameters are rejected, escaped, or parameterized and do not produce SQL errors, timing differences, or altered result sets.

Typical attack path

1. Discover a Pimcore application exposed to the network.
2. Fingerprint the application version or infer vulnerability by testing behavior of grid-related requests.
3. Submit crafted requests containing SQL injection syntax to parameters handled by GridHelperService.php.
4. Use response differences, SQL errors, timing behavior, or returned data to confirm injection.
5. Enumerate database schema or accessible tables.
6. Extract sensitive application data from the database.
7. Optionally automate repeated requests to dump larger datasets while attempting to blend into normal web traffic.

How to detect it

Review historical logs from the publication date onward where available, with priority on the last 90 days and any period before patching. Useful sources include reverse proxy logs, web server access logs, WAF alerts, Pimcore application logs, PHP-FPM logs, database audit logs, database slow query logs, and error logs. Look for requests to Pimcore administrative or grid-related endpoints containing SQL injection markers such as UNION SELECT, information_schema, sleep functions, boolean conditions, comment sequences, encoded quotes, or repeated parameter tampering. Correlate suspicious HTTP requests with database errors such as SQL syntax errors, unknown column errors, malformed WHERE/ORDER BY clauses, or unusually large SELECT queries. Investigate repeated requests from the same source IP, requests that produce 500 responses, abnormal response sizes, and database queries accessing tables unrelated to the intended grid view. If exploitation is suspected, preserve raw logs, identify data returned during the suspicious requests, and review whether sensitive database records were accessed or exported.

• GridHelperService.php
• /admin/
• /pimcore/
• UNION SELECT
• UNION%20SELECT
• information_schema
• information_schema.tables
• information_schema.columns
• SLEEP(
• BENCHMARK(
• WAITFOR DELAY
• ' OR '1'='1
• %27%20OR%20%271%27%3D%271
• --
• %2D%2D
• /*
• %2F%2A
• SQLSTATE[42000]
• SQLSTATE[HY000]
• You have an error in your SQL syntax
• Doctrine\\DBAL\\Exception
• PDOException
• ORDER BY
• GROUP BY

What your security team should do

• Prioritize patching Pimcore instances before other medium-risk backlog items because public exploit code exists and EPSS is high.
• Inventory all Pimcore deployments, including Git-based installs, containers, developer-managed instances, and legacy web servers.
• Upgrade to Pimcore 10.3.6 or later, or verify inclusion of commit 1b805b9748fc0214bb19020d1051448431ba9e69.
• Restrict access to Pimcore administrative and grid-related functionality to trusted networks or VPN until patching is complete.
• Search historical web, application, WAF, and database logs for SQL injection probing and suspicious requests against Pimcore routes.
• If suspicious activity is found, perform database access review, assess potential data exposure, rotate credentials that may have been stored in the application database, and preserve logs for incident response.
• Add SIEM detections for SQL injection strings in requests to Pimcore endpoints and for database errors emitted by the application.