dotcms-publish-audit-api-unauthenticated-sql-injection

dotCMS Publish Audit API unauthenticated SQL injection (severity 10.0), exact endpoints exposed: /api/auditPublishing/get and /api/auditPublishing/getAll — immediate database compromise risk

What happened

dotCMS has a critical, unauthenticated SQL injection in its Publish Audit API, specifically the /api/auditPublishing/get and /api/auditPublishing/getAll endpoints. An unauthenticated attacker can send crafted input and read, modify or destroy arbitrary database content.

The advisory says the flaw affects dotCMS Core releases 25.11.04-1 through 26.04.28-02. The vendor states a fix exists in dotCMS Core 26.04.28-03 which changes the code path to require an authenticated backend user with the publishing-queue portlet permission. Long-term support releases are not affected because the vulnerable code path was never backported.

How the issue was discovered and whether active exploitation is underway has not been disclosed. What is confirmed is the severity, the exact API endpoints involved and the fixed version identifier, so organisations running the affected releases have clear, actionable signals.

Why this matters to businesses

If you run dotCMS to publish content or manage sites, this is about your data, your customers and your contracts. An attacker who can read or tamper with the CMS database can alter published content, inject fraudulent pages, delete records or extract sensitive data used elsewhere in your business.

That can mean downtime while you restore, legal and regulatory headaches if personal data is exposed, cancelled supplier contracts, and board-level time answering auditors and customers. Given this is unauthenticated, perimeter-only protections may not stop it.

And yes, if your team thinks “we’ll patch later”, this is exactly the sort of hole that bites you very quickly, honestly.

If you’ve got the same weakness, here’s what happens next

First, attackers can quietly dump or tamper with tables, then use that foothold to pivot to other systems that reuse credentials or DB connections. Second, recovery can stretch out because you need forensics, restores and proofs to regulators and clients.

Third, backups may contain poisoned data, so restores are not a simple button press and costs spiral as legal, PR and overtime stack up. Finally, even if you close the hole quickly, trust evaporates and you spend months answering questions rather than building features.

What to do on Monday morning

1. Inventory: find every dotCMS instance and record exact versions and network exposure, focus on any running 25.11.04-1 through 26.04.28-02.

2. Patch or mitigate: upgrade to dotCMS Core 26.04.28-03 where possible, or apply vendor mitigations that restrict access to the /api/auditPublishing endpoints to authenticated backend users.

3. Network controls: block or restrict access to publishing API endpoints at the WAF or firewall, limit to known admin IP ranges and require VPN for backend access.

4. Credentials and permissions: rotate database credentials used by dotCMS, review backend user accounts and ensure the publishing-queue portlet permission is constrained to named admin roles only.

5. Logging and detection: enable detailed DB query and API logging, add alerts for unusual SELECT, UPDATE or DELETE patterns originating from public endpoints, and retain logs for forensics.

6. Backups and restore test: verify your backups are complete, immutable if possible, and perform a restore test to ensure you can recover to a known good state without reintroducing tampered data.

7. Incident plan: prepare communications for customers and regulators, and gather your incident response team and forensics contacts so you can move fast if you find evidence of compromise.

Where ISO standards fit, without the sales pitch

An ISO-aligned information security management system helps here by making these steps routine rather than heroic. An organisation with clear change control, asset inventory and patch processes mapped to an ISO 27001 approach is less likely to leave internet-facing APIs unprotected.

When it comes to surviving a messy recovery, an established business continuity plan built around ISO 22301 gives you the playbooks and senior decision triggers you need, so the outage doesn’t become a board-level crisis for weeks.

For baseline configuration and supplier assurance, the IASME-style controls that enforce access restrictions and patch deadlines turn a public CVE into a normal operational task rather than a firefight.

If you need to bring people up to standard quickly, these standards give pragmatic maps of what to check and who must sign off, not just another audit pile.

Act now, not later: this is the sort of vulnerability that rewards speed and common sense more than drama.

Take a breath, make a plan and start with an inventory and the patch or access controls mentioned above.