CiviCRM 6.17.1 Security Release: What Joomla Sites Should Do

On 5 August 2026 CiviCRM released 6.17.1, 6.16.5 and 6.10.10 (ESR) to fix a highly critical security issue. If your Joomla site runs CiviCRM and has not been updated since, this is the one to do now.

What the problem is

CIVI-SA-2026-37: any user – including an anonymous visitor – could bypass APIv4 permission checks with a specially crafted REST call. In other words, data and actions that should need a login and the right permission could be reached without either.

It is a variation of an earlier issue (CIVI-SA-2026-35), whose first fix was deliberately narrow. The new fix closes more variations of the same bug.

Who is affected

The Joomla version doesn't matter – this is in CiviCRM core.

What to do

CiviCRM lists three ways to mitigate it. Any one is enough:

1. Upgrade to a fixed version – today, that means the current release (6.19.1 at the time of writing), or 6.10.10+ if you stay on ESR.
2. Install the hotfix extension "Hotfix: Camel Attack" through the extensions screen or the command line, if you can't upgrade straight away.
3. Apply the patch linked from the advisory – for developers who manage CiviCRM by hand.

Upgrading is the best option; the hotfix buys time. If you use the hotfix, plan the full upgrade anyway.

Check after updating

The advisory notes a regression risk: APIv4 now treats more properties as case-sensitive. That matches how APIv4 is meant to work, but third-party code that relied on the old, looser behavior may break. After updating, test:

• Integrations that call CiviCRM's API – website forms, external apps, sync scripts.
• Custom CiviCRM extensions written in-house.
• FormBuilder forms and SearchKit displays that the public can reach.

An "unknown field" or "not found" error from an integration after this update usually means a property name with the wrong capitalization in the calling code.

Lessons for next time

• Subscribe to CiviCRM's security announcements, so you hear about the next one the day it ships.
• Keep a staging copy fresh enough that a security update can be tested in an hour, not a week. Our update routine is built for exactly this.
• Keep fixes out of CiviCRM core, so security updates never wait on re-applying patches. More here.

Verify it, don't assume it

# terminal – which version is really running, and is the hotfix extension installed?
cv status --cwd=/var/www/example.org | grep -i civicrm
cv ext:list -Li --cwd=/var/www/example.org | grep -i hotfix

# integration code that may rely on case-insensitive APIv4 property names
grep -rnE 'api4\(|Civi\\Api4' /path/to/integrations --include=*.php | cut -c1-140

After a security update, look at the web server log for the days before it: requests to /civicrm/ajax/api4/ or the REST endpoint from unknown addresses, at volumes no form would produce, are worth a closer look.