ChurchTools Integration Suite WP Registry grade D+. High-severity findings · 3 findingsWP RegistryHigh-severity findings · 3 findingsOpen the reportD+

High-severity findings.

Audited release

1.3.0.14

Findings

3

Worst severity

high

Content hash

2f7a48442763598d4812f4a7… Copy

Findings

• high Public event modal stores and executes unsanitized ChurchTools HTML via jQuery.html()

  xss_stored

  wp_ajax_nopriv_cts_get_event_details is reachable by anyone with the churchtools_suite_public nonce, which enqueue_public_assets localizes on every front-end page. The handler loads cts_events by sequential integer id and returns event_description/appointment_description after wpautop() only — no wp_kses_post / esc_html. churchtools-suite-public.js then calls jQuery.html() on those strings (and concatenates unsanitized address_name, location_name, address_street, zip, and city into $('#cts-modal-location-value').html()). jQuery.html() executes <script> and inline event handlers, unlike native innerHTML. Write path: ChurchTools_Suite_Event_Sync_Service copies $event['note'] / appointment note into those columns with no sanitization. Single-event PHP templates already wrap the same fields in wp_kses_post(), so this is an omitted sanitizer on the AJAX/modal path rather than intentional raw HTML. Anyone who can edit a ChurchTools appointment note (typically many church staff, not WordPress admins) can XSS every visitor who opens the modal. Location/address fields are the same sink even if notes are plain text.

  admin/class-churchtools-suite-admin.php:2324-2451

  Recommendation

  Sanitize on output the same way single-event templates already do: wp_kses_post() (or wp_kses with an explicit allowlist) before returning descriptions, and escape location/address fragments as text (or build them with $().text()). Prefer textContent / jQuery.text() in the modal JS; if HTML is required, insert only after server-side kses. Strip or kses notes at sync time as defense in depth.

• medium Unauthenticated event-details AJAX enumerates volunteer names and addresses without calendar ACL

  information_disclosure

  The same nopriv handler (and nopriv cts_load_calendar_month) is the public event API. get_by_id($event_id) has no check that the event's calendar is_selected, that a shortcode on the referring page allowed that calendar, or that the block's show_services flag is on. The JSON always includes services[].person_name plus street/zip/city. Event ids are autoincrement integers, and the public nonce is on every page (assets always enqueue), so an unauthenticated visitor can enumerate /wp-admin/admin-ajax.php?action=cts_get_event_details without a published calendar widget. Shortcode/block show_services=false only hides names in the DOM; the AJAX response still returns them. Calendar-filtered shortcodes similarly do not bind the AJAX read path, so events synced for a members-only view remain globally readable.

  admin/class-churchtools-suite-admin.php:2324-2451

  Recommendation

  Treat the AJAX read as an access-controlled public API: only return events whose calendar is_selected (or that match an allow-listed calendar_ids argument that the shortcode actually used). Omit services/person_name unless the caller passes a signed/show_services flag that matches the published widget. Avoid sequential id disclosure or require a non-guessable appointment token. Do not localize the public nonce on pages that do not render a ChurchTools view if the endpoint should not be site-wide.

• medium ChurchTools password stored in plaintext and all API traffic disables TLS verification

  insecure_config

  Settings save writes churchtools_suite_ct_password via update_option(sanitize_text_field) with no ChurchTools_Suite_Secret_Storage::encrypt, and the settings form echoes that password back in the HTML value attribute. Tokens are encrypted (and migrated from plaintext on next CT client construct), so password storage is an omitted use of the existing helper. Independently, ChurchTools_Suite_CT_Client::login(), test_connection()/whoami, and api_request() all set sslverify => false, so the plaintext password and Authorization/X-ChurchTools-Token headers are sent without validating the peer certificate. A network MITM (captive portal, compromised resolver, broken middlebox) recovers credentials that typically unlock the church's ChurchTools member/calendar database. Session cookies are also stored in option churchtools_suite_ct_cookies. Tenant URL is constrained to https://{tenant}.church.tools, which limits SSRF but does not restore TLS authentication to that host.

  includes/class-churchtools-suite-ct-client.php:51-114

  Recommendation

  Remove sslverify => false (leave WordPress defaults). Encrypt the password with Secret_Storage the same way tokens are encrypted; do not echo it back into the password input (placeholder only). Encrypt or avoid persisting ChurchTools session cookies in options. Call encrypt() at save time for both token and password rather than relying on lazy migration.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.