8.5
/ 10
HIGH
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:H/SC:N/VI:H/SI:N/VA:H/SA:N
Description
ChurchCRM versions 6.5.2 and below suffer from a persistent cross site scripting vulnerability in the person property assignment functionality. Note that the advisory says versions 6.3.0 and below are affected but the CVE entry states versions prior to...
Basic Information
ID
PACKETSTORM:218764
Published
Apr 13, 2026 at 00:00
Affected Product
Affected Versions
# CVE-2025-67875: ChurchCRM has stored XSS via Person Property Assignment Leading to Admin Session Hijacking
## Overview
| Field | Details |
|---|---|
| **CVE ID** | [CVE-2025-67875](https://nvd.nist.gov/vuln/detail/CVE-2025-67875) |
| **Severity** | HIGH |
| **Advisory** | [View Advisory](https://github.com/ChurchCRM/CRM/security/advisories/GHSA-fcw7-mmfh-7vjm) |
| **Discovered by** | [Lukasz Rybak](https://github.com/lukasz-rybak) |
## Affected Products
- **ChurchCRM/CRM**
## Details
### Summary
A critical privilege escalation vulnerability exists in ChurchCRM version 6.3.0 and earlier. An authenticated user with specific mid-level permissions ("Edit Records" and "Manage Properties and Classifications") can inject a persistent Cross-Site Scripting (XSS) payload into an administrator's profile. The payload executes when the administrator views their own profile page, allowing the attacker to hijack the administrator's session, perform administrative actions, and achieve a full account takeover.
This vulnerability is a combination of two separate flaws: an Insecure Direct Object Reference (IDOR) that allows any user to view any other user's profile, and a Broken Access Control vulnerability that allows a user with general edit permissions to modify any other user's record properties.
### Details
The attack chain is as follows:
1. **IDOR in `PersonView.php`:** There is no authorization check at the beginning of `PersonView.php`. Any authenticated user can view the profile page of any other user (e.g., `PersonView.php?PersonID=1` for the admin) simply by knowing their ID.
2. **Broken Access Control in `PropertyAssign.php`:** The "Assign a New Property" functionality, accessible from another user's `PersonView.php` page, directs the user to `PropertyAssign.php`. This script correctly checks if the user has the general `isEditRecordsEnabled()` permission, but it **fails to perform an object-level authorization check** to verify if the user is allowed to edit the specific `PersonID` passed in the URL. This allows a user with "Edit Records" to modify properties of any person in the system, including an administrator.
3. **Stored XSS Vector:** An attacker can leverage these two flaws to navigate to the administrator's profile page and use the "Assign a New Property" form to save a malicious XSS payload to the administrator's record. The `Value` field for text-based properties is not properly sanitized on input (only `strip_tags` is applied, which does not remove event handlers) and is not encoded on output, leading to Stored XSS.
* **Input Handling (`src/PropertyAssign.php`):** Saves the property value after only applying `strip_tags()`, which allows event handler attributes like `onerror`.
* **Vulnerable Output Sink (`src/PersonView.php`):** Renders the stored property value directly into the HTML without `htmlspecialchars()`, causing the payload to execute.
```php
// src/PersonView.php, line ~722
<td><?= $r2p_Value ?></td> // Vulnerable: Raw output
```
### PoC
This Proof of Concept demonstrates how a user with specific mid-level permissions can inject a Stored XSS payload into the main administrator's profile.
**Prerequisites:**
* An attacker has an account with two specific permissions enabled:
1. `Edit Records`
2. `Manage Properties and Classifications`
**Scenario:**
1. **Login as Attacker:** Log in as the user with the permissions listed above.
<img width="1787" height="755" alt="image" src="https://github.com/user-attachments/assets/ba13aca7-b4cc-46db-809e-c227b7b62177" />
2. **Target the Administrator:** Navigate directly to the administrator's profile page, which is typically `PersonID=1`.
```
http://localhost:8101/PersonView.php?PersonID=1
```
(Access is granted due to the IDOR in `PersonView.php`).
<img width="2546" height="766" alt="image" src="https://github.com/user-attachments/assets/b52a6b77-4e30-46c3-bca0-ce98f6c129f9" />
3. **Inject Payload:**
* On the administrator's profile page, scroll down to the **Assigned Properties** tab.
* In the "Assign a New Property" form, select the text-based property e.g. ("Test"). (The form is visible due to the "Edit Records" permission).
* In the **Value** textarea that appears, enter the following XSS payload:
```html
<img src=x onerror=alert('XSS_on_ADMIN_Profile')>
```
* Click the "Assign" button. The payload is now stored on the administrator's record. (The assignment is possible due to the Broken Access Control in `PropertyAssign.php`).
<img width="2548" height="799" alt="image" src="https://github.com/user-attachments/assets/7ec283e1-1c7a-4f77-bf27-b0e12775fb1b" />
<img width="2542" height="913" alt="image" src="https://github.com/user-attachments/assets/2c25fe24-bbe5-486e-8af2-c3a18e9e9982" />
4. **Trigger the Attack:**
* The attacker can now wait for the administrator to log in and view their own profile.
* When the administrator navigates to their own profile page (`PersonView.php?PersonID=1`), the payload will execute immediately, and an alert box will appear. The attacker could use a more advanced payload to steal the administrator's session cookie.
<img width="2537" height="838" alt="image" src="https://github.com/user-attachments/assets/d2c925c0-f0ed-4b95-a10d-9f64790ba72f" />
<img width="2544" height="758" alt="image" src="https://github.com/user-attachments/assets/2d947282-b16a-4a06-81f7-7270bf316904" />
### Impact
This is a critical privilege escalation vulnerability. It allows a user with specific, elevated (but non-admin) permissions to gain full control over an administrator's account. By hijacking the admin's session, the attacker can perform any action available to an administrator, including creating new admin accounts, deleting data, and potentially chaining this with other vulnerabilities to achieve full server compromise.
### Attribution
Reported by: Łukasz Rybak
## References
- https://github.com/ChurchCRM/CRM/security/advisories/GHSA-fcw7-mmfh-7vjm
## Disclaimer
This CVE was responsibly disclosed following coordinated vulnerability disclosure practices. The information provided here is for educational and defensive purposes only.
## Overview
| Field | Details |
|---|---|
| **CVE ID** | [CVE-2025-67875](https://nvd.nist.gov/vuln/detail/CVE-2025-67875) |
| **Severity** | HIGH |
| **Advisory** | [View Advisory](https://github.com/ChurchCRM/CRM/security/advisories/GHSA-fcw7-mmfh-7vjm) |
| **Discovered by** | [Lukasz Rybak](https://github.com/lukasz-rybak) |
## Affected Products
- **ChurchCRM/CRM**
## Details
### Summary
A critical privilege escalation vulnerability exists in ChurchCRM version 6.3.0 and earlier. An authenticated user with specific mid-level permissions ("Edit Records" and "Manage Properties and Classifications") can inject a persistent Cross-Site Scripting (XSS) payload into an administrator's profile. The payload executes when the administrator views their own profile page, allowing the attacker to hijack the administrator's session, perform administrative actions, and achieve a full account takeover.
This vulnerability is a combination of two separate flaws: an Insecure Direct Object Reference (IDOR) that allows any user to view any other user's profile, and a Broken Access Control vulnerability that allows a user with general edit permissions to modify any other user's record properties.
### Details
The attack chain is as follows:
1. **IDOR in `PersonView.php`:** There is no authorization check at the beginning of `PersonView.php`. Any authenticated user can view the profile page of any other user (e.g., `PersonView.php?PersonID=1` for the admin) simply by knowing their ID.
2. **Broken Access Control in `PropertyAssign.php`:** The "Assign a New Property" functionality, accessible from another user's `PersonView.php` page, directs the user to `PropertyAssign.php`. This script correctly checks if the user has the general `isEditRecordsEnabled()` permission, but it **fails to perform an object-level authorization check** to verify if the user is allowed to edit the specific `PersonID` passed in the URL. This allows a user with "Edit Records" to modify properties of any person in the system, including an administrator.
3. **Stored XSS Vector:** An attacker can leverage these two flaws to navigate to the administrator's profile page and use the "Assign a New Property" form to save a malicious XSS payload to the administrator's record. The `Value` field for text-based properties is not properly sanitized on input (only `strip_tags` is applied, which does not remove event handlers) and is not encoded on output, leading to Stored XSS.
* **Input Handling (`src/PropertyAssign.php`):** Saves the property value after only applying `strip_tags()`, which allows event handler attributes like `onerror`.
* **Vulnerable Output Sink (`src/PersonView.php`):** Renders the stored property value directly into the HTML without `htmlspecialchars()`, causing the payload to execute.
```php
// src/PersonView.php, line ~722
<td><?= $r2p_Value ?></td> // Vulnerable: Raw output
```
### PoC
This Proof of Concept demonstrates how a user with specific mid-level permissions can inject a Stored XSS payload into the main administrator's profile.
**Prerequisites:**
* An attacker has an account with two specific permissions enabled:
1. `Edit Records`
2. `Manage Properties and Classifications`
**Scenario:**
1. **Login as Attacker:** Log in as the user with the permissions listed above.
<img width="1787" height="755" alt="image" src="https://github.com/user-attachments/assets/ba13aca7-b4cc-46db-809e-c227b7b62177" />
2. **Target the Administrator:** Navigate directly to the administrator's profile page, which is typically `PersonID=1`.
```
http://localhost:8101/PersonView.php?PersonID=1
```
(Access is granted due to the IDOR in `PersonView.php`).
<img width="2546" height="766" alt="image" src="https://github.com/user-attachments/assets/b52a6b77-4e30-46c3-bca0-ce98f6c129f9" />
3. **Inject Payload:**
* On the administrator's profile page, scroll down to the **Assigned Properties** tab.
* In the "Assign a New Property" form, select the text-based property e.g. ("Test"). (The form is visible due to the "Edit Records" permission).
* In the **Value** textarea that appears, enter the following XSS payload:
```html
<img src=x onerror=alert('XSS_on_ADMIN_Profile')>
```
* Click the "Assign" button. The payload is now stored on the administrator's record. (The assignment is possible due to the Broken Access Control in `PropertyAssign.php`).
<img width="2548" height="799" alt="image" src="https://github.com/user-attachments/assets/7ec283e1-1c7a-4f77-bf27-b0e12775fb1b" />
<img width="2542" height="913" alt="image" src="https://github.com/user-attachments/assets/2c25fe24-bbe5-486e-8af2-c3a18e9e9982" />
4. **Trigger the Attack:**
* The attacker can now wait for the administrator to log in and view their own profile.
* When the administrator navigates to their own profile page (`PersonView.php?PersonID=1`), the payload will execute immediately, and an alert box will appear. The attacker could use a more advanced payload to steal the administrator's session cookie.
<img width="2537" height="838" alt="image" src="https://github.com/user-attachments/assets/d2c925c0-f0ed-4b95-a10d-9f64790ba72f" />
<img width="2544" height="758" alt="image" src="https://github.com/user-attachments/assets/2d947282-b16a-4a06-81f7-7270bf316904" />
### Impact
This is a critical privilege escalation vulnerability. It allows a user with specific, elevated (but non-admin) permissions to gain full control over an administrator's account. By hijacking the admin's session, the attacker can perform any action available to an administrator, including creating new admin accounts, deleting data, and potentially chaining this with other vulnerabilities to achieve full server compromise.
### Attribution
Reported by: Łukasz Rybak
## References
- https://github.com/ChurchCRM/CRM/security/advisories/GHSA-fcw7-mmfh-7vjm
## Disclaimer
This CVE was responsibly disclosed following coordinated vulnerability disclosure practices. The information provided here is for educational and defensive purposes only.