CVE-2026-8054
SQL Injection in dotCMS Core
Publication date: 2026-05-27
Last updated on: 2026-05-27
Assigner: dotCMS LLC
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| dotcms | core | 25.11.04-1 |
| dotcms | core | 26.04.28-02 |
| dotcms | core | 26.04.28-03 |
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-2026-8054 is a SQL Injection vulnerability in the dotCMS platform affecting the Publish Audit API endpoints (/api/auditPublishing/get and /api/auditPublishing/getAll). The vulnerability arises because these endpoints accepted unsanitized input used directly in dynamically constructed SQL queries without proper neutralization of special SQL elements.
Specifically, the method `PublishAuditAPIImpl.getPublishAuditStatuses` constructed SQL IN clauses by embedding user-supplied bundle IDs directly into the query string using unsafe string formatting. This allowed attackers to inject malicious SQL code that could break out of the intended query context and execute arbitrary SQL commands.
Additionally, the endpoints did not enforce authentication, allowing remote unauthenticated attackers to exploit this vulnerability.
The fix involved replacing unsafe string concatenation with parameterized queries using JDBC placeholders, binding parameters safely, handling null or empty inputs properly, correcting error logging, and enforcing authentication requiring a backend user with the publishing-queue portlet permission.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows remote unauthenticated attackers to read, modify, or destroy arbitrary database content via SQL injection in the Publish Audit API endpoints. This unauthorized access and potential data manipulation could lead to violations of data protection regulations such as GDPR and HIPAA, which require strict controls over access to sensitive data and the integrity of stored information.
The fix enforces authentication and permission checks, requiring an authenticated backend user with the publishing-queue portlet permission, thereby reducing the risk of unauthorized data access and helping to maintain compliance with these standards.
How can this vulnerability impact me? :
This vulnerability allows remote unauthenticated attackers to read, modify, or destroy arbitrary database content within the dotCMS platform.
Because the SQL injection flaw enables execution of arbitrary SQL commands, attackers could potentially access sensitive data, alter or delete records, and disrupt the normal operation of the application.
The lack of authentication enforcement on the affected endpoints increases the risk, as attackers do not need valid credentials to exploit the vulnerability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of this SQL injection vulnerability involves checking for unauthorized or malformed requests to the Publish Audit API endpoints (/api/auditPublishing/get and /api/auditPublishing/getAll) that include suspicious input in parameters such as bundle IDs.
One approach is to monitor HTTP requests to these endpoints for payloads containing SQL injection patterns like "x' OR '1'='1", "x'; DROP TABLE publishing_queue_audit; --", or unterminated comments.
You can use network monitoring tools or web application firewalls (WAF) to log and analyze such requests.
For example, using curl or similar tools to test the endpoints with suspicious input can help detect vulnerability:
- curl -v 'http://<dotcms-host>/api/auditPublishing/get?bundleIds=x'%20OR%20'1'='1'
- curl -v 'http://<dotcms-host>/api/auditPublishing/getAll?bundleIds=x';%20DROP%20TABLE%20publishing_queue_audit;--'
If the system responds with data or errors indicating SQL execution, it may be vulnerable.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Upgrade dotCMS Core to version 26.04.28-03 or later, where the vulnerability is fixed by enforcing authentication and using parameterized queries.
- Ensure that the Publish Audit API endpoints (/api/auditPublishing/get and /api/auditPublishing/getAll) require authenticated backend users with the publishing-queue portlet permission.
- If upgrading immediately is not possible, restrict network access to these endpoints to trusted users only.
- Monitor logs for suspicious activity targeting these endpoints.