Security Advisories

CiviCRM permission-checks may incorporate a mix of boolean operations (AND and OR). In certain combinations, the permission-check has a premature short-circuit and grants access erroneously.

The issue is highly dependent on the specific boolean expression. It is believed that civicrm-core does not have any live, vulnerable expressions. However, extensions could have exploitable expressions.

It was possible to retrieve associated financial entities for contributions that were associated with contacts a user may not have been able to see

By default, CiviCRM Standalone accepts password credentials from all users -- for both web-based user-logins and REST-based service-logins.

CiviCRM Standalone also has an option for Multifactor Authentication (MFA), which provides defense-in-depth to limit the potency of a compromised password.

Prior to 6.19.3, MFA constrained password access for web-logins (all users) but not service-logins (all users). This could bypass the extra MFA checks. In 6.19.3, MFA blocks passwords for all service-logins.

CiviCRM web-pages must frequently make small requests for specific pieces of data (AJAX requests). Modern CiviCRM web-pages process these requests through an opinionated framework (APIv4 AJAX), but many pages use an older framework (basic/legacy AJAX).

Within the basic/legacy framework, there were multiple issues:

Permissions were not adequately checked for event billing locations, allowing location details associated with events (including non-public events) to be accessed publicly.

A malicious actor may provide a special link to a staff-user, which causes the user to quietly change their logged-in identity.

We have not found a way to use this issue to reveal private information or manipulate ordinary data records. However, it can lead to inaccurate audit-logs (and create general confusion).

CiviCRM "Form Builder" allows an administrator to define custom forms. Forms reference an initial data-record (such as an "Individual submission form"), and forms may reference related records (such Phone or Email).

If a form provides acccess to related records, then a form-user can steal related records. This reveals the content of the record, and it deprives the original owner of access.

In CiviCRM's data-model, there are several kinds of records which may be owned by a particular person. For example, if a user creates a custom SavedSearch, then the SavedSearch is owned by that user. CiviCRM allows the owner to revise their record, but it blocks access for most other users.

In APIv3 and Search Builder, queries with regular-expressions are vulnerable to SQL injections.

A backend user may send a specially crafted API call which bypasses an access-control list (ACL).

The vulnerability allows read access to some records but not all records. In the initial proof-of-concept, this appears limited. However, future attackers may build on this vulnerability to access more records.

On CiviCRM Standalone, a user with access to the backend UI can send a specially-crafted request which bypasses regular access-controls and escalates their privileges.

This issue does not affect other runtime environments.

APIv4's EntitySet feature allows execution of multiple sub-requests. In several cases, the sub-requests execute without meaningful permission checks.

CiviCRM allows the administrator to flag some Groups as reserved. Reserved groups should only be managed by users with an extra permission (administer reserved groups), but this constraint was not enforced properly.

In configurations that combine CiviCRM Standalone with an SSL/TLS proxy, it may be possible to issue insecure cookies.

This issue does not affect other runtime environments.

When writing records via APIv4, the use of joins can implicitly reveal information about inaccessible records.

The updated version of CiviCRM imposes new limits on the use of joins within write operations.

The limitations are expected to have minimal impact on ordinary/legitimate callers. However, some API callers may experience a new error (e.g. No unique index on ENTITY.FIELD.). If you are affected, then you may wish to:

Any user (including an anonymous user) can bypass APIv4 permission checks with a specially crafted REST call.

Discussion: This is a variation of CIVI-SA-2026-35. The original fix for CIVI-SA-2026-35 was narrowly framed to minimize regression-risk; but this allowed similar bugs to remain in other code-paths. The new patch for CIVI-SA-2026-37 is more aggressive. Consequently, it closes off more variations on the bug.

If a user has access to APIv4 REST for purposes of creating/updating one kind of record (such as Contribution), then they may be able to infer implicit information from a related record-type (such as Contact), even if the user lacks regular access to the Contact.

This vulnerability arises from insufficient security checks in the "write/join" mechanism.

Any user (including an anonymous user) can bypass APIv4 permission checks with a specially crafted REST call.

The vulnerability arises from a discrepancy in how capitalization is handled by JSON, PHP arrays, and PHP methods.

In CiviMail, multiple fields and screens could be used as vectors for cross-site scripting.

Exploiting this requires that the attacker have permission to manage CiviMail content.

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.