June 1, 2026
When a Routine Pentest Becomes a CVE: XSS to Admin in Rock RMS
Raxis Pentester Jason Taylor has discovered a new high-risk vulnerability in Rock RMS: CVE-2026–36748. Learn how to duplicate and mitigate.
Mark Puckett
3 min read
One of the things I love most about the business of penetration testing is that the job never gets boring. Every engagement is a puzzle. Most of the time, our team finds the expected vulnerabilities and chained attack paths. But every so often, a tester digs into something that turns into a legitimate, original discovery. That happened recently, and the result is CVE-2026–36748.
During a routine web application penetration test, Raxis Lead Penetration Tester Jason Taylor noticed something worth pulling on. The target application used Rock RMS, an open-source church and nonprofit management platform built by Spark Development Network. Rock RMS has a solid user base in the nonprofit world, which means a vulnerability here has real-world consequences for organizations that often run lean IT operations and can be more exposed than they realize.
Jason found a cross-site scripting (XSS) vulnerability in the Social Media Links field on the My Account profile page. Unsanitized input in a social media field is not exactly a headline grabber on its own. But Jason didn't stop there.
From XSS to Full Admin Access
He stood up Rock RMS in his own lab and started asking a different question: how far can I push this? After some careful crafting, he built a payload that does something genuinely impactful. When a standard user injects the payload into their social media profile field and an administrator later views that user's profile page, the payload fires silently in the admin's browser session. It calls the Rock RMS API to retrieve the attacker's person GUID, then makes a follow-up POST request to add that user to the RSR Rock Administration security group. No password reset required. No loud alerts. The attacker just quietly becomes an admin.
From a technical standpoint, the CVSS score came in at 9.0 (High), with a vector of AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H. That score reflects the fact that a low-privilege user on any affected Rock RMS installation can set this up and then either wait for an admin to browse new member profiles or socially engineer one into viewing their profile page under the guise of requesting support. The blast radius once admin access is achieved is essentially the entire platform.
This is a textbook example of why input sanitization cannot be treated as optional, even in fields that look harmless. Social media URLs feel innocuous. They are not.
Affected Versions and Mitigation
Jason tested versions 16.13 and 17.7. Both are vulnerable. All versions through 17.7.0 are believed to be affected. Spark Development Network releases publicly after a one-year early access period, so patched pre-release builds may exist, but they were not available for testing at the time of disclosure.
Mitigation is straightforward if patching is not yet an option: disable Social Media Links in user profiles. Navigate to Admin > Settings > General > Person Attributes and set each social media type to inactive. That removes the attack surface entirely.
A Word on Responsible Disclosure
Raxis follows the industry standard 90-day responsible disclosure policy. Jason reported this to Spark Development Network on March 1, 2026. He followed up twice, in March and again in April, without any response. A CVE was assigned on May 18, 2026 with a third follow-up that also went unanswered. We are publishing today, June 1, because the 90-day window has closed. Vendors sometimes go quiet, but that cannot be a reason to keep users in the dark.
If you run Rock RMS for your organization, disable those social media fields today and monitor for a vendor patch.
What This Means for IT Managers and Security Teams
This finding is a good reminder of a few things that tend to get lost in the day-to-day. First, your attack surface includes every input field in every application your users touch, not just the obvious ones. Second, stored XSS in a platform with privileged users is almost always more dangerous than it looks at first glance. Regular penetration testing of your web applications is what catches these things before someone with worse intentions does.
Jason's full technical writeup is published on the Raxis blog, including the complete proof of concept, payload, and step-by-step disclosure timeline. If you manage Rock RMS or do application security work, it is worth reading in detail.
This is exactly the kind of work our team does every day. We are proud of Jason for taking a routine finding and doing the extra work to understand its full potential, responsibly disclosing it, and getting a CVE on record. That is what great penetration testing looks like.
Raxis is a cybersecurity firm specializing in penetration testing and red team operations. Learn more at raxis.com.