CIVI-SA-2026-28: Escalation via Extension Download API

The Extension Download API provides administrators with tools for installing and sideloading extensions. The API is available in PHP, HTTP, CLI, etc. To execute the API, both the POSIX process and the CiviCRM user must have certain permissions.

The issue here is not a specific vulnerability in the API; on its own, it respects ordinary permissioning. However, if the system has another vulnerability (such as XSS), then the Extension Download API is an appealing target for escalation.

The current update reduces the appeal of Extension Download API (as a path for escalation). Specifically, the update prevents HTTP-based callers from sideloading extensions. The change shouldn't affect most users, and it is a simple "defense-in-depth" step. However, it is technically a break in backward-compatibility.

Questions and Answers

Q: Who might have trouble with this change?

This may affect system-builders who sideload extensions using "API Explorer" or "REST". There are several ways to accommodate this restriction, such as:

• Switch to different API entry-point (PHP or cv/drush/wp-cli); or...
• Sideload your extensions via SFTP/SSH, or...
• Publish your extensions in the main civicrm.org feed; or...
• Update CIVICRM_EXTENSION_DOWNLOAD_TRUSTED_HOSTS to include your own server.

Q: Should I disable the Extension Download API?

This is a trade-off. Disabling remote access to the API will further lock-in your codebase. This can be good, because it limits some escalations. However, it also prevents web-based administrators from applying security+compatibility updates for extensions.

It essentially depends on whether you use the web-based admin UI:

• If you manage extensions via CLI/GIT, then it's fine to disable it.
• If you manage extensions via Web UI, then leave it enabled.

Q: How can I disable the Extension Download API?

The most effective way to disable downloads is to configure your web-server filesystem. Simply disable write-access to the extension-folder (for the HTTPD-user). This has always been an intended mode-of-operation since v4.x, and it will be equally effective regardless of your CiviCRM versions or settings-flags or vulnerabilities.

Additionally, you can set some options in civicrm.settings.php:

• Disable the feed of available downloads ($civicrm_setting['domain']['ext_repo_url'] = false;).
• Disable the trusted sources (define('CIVICRM_EXTENSION_DOWNLOAD_TRUSTED_HOSTS', [])).
• Hardcode $civicrm_setting['domain']['extensionsDir'] and $civicrm_setting['domain']['extensionsURL'] to absolute path and absolute URL.

Q: Will this stop escalation of XSS?

Not really. It limits one obvious escalation, but a persistent attacker will find others. For more general defenses, look into efforts like dev/core#6587 - Stronger security confirmation for HTTP-based sysadmin.