Subscriber-level users can escalate to admin via Custom Role Manager

TL;DR - Highland Software Custom Role Manager <= 1.0.0: hscrm_save_user_roles() is hooked to personal_options_update with no meaningful authorisation check. Any Subscriber-level account can trigger a profile update and rewrite user roles - including granting themselves administrator. Patched in 1.0.1.

What happened

Highland Software Custom Role Manager is a WordPress plugin that adds role-management UI inside the normal profile update flow.

Versions up to and including 1.0.0 contain a privilege escalation flaw. The function hscrm_save_user_roles() fires on the personal_options_update action but performs no sufficient authorisation check. Any authenticated user - a Subscriber, a customer, a forum member - can submit the profile update form and alter role assignments.

This is a familiar and dangerous WordPress failure mode. Once a low-privilege user can assign roles, the natural next step is self-promotion to administrator, followed by arbitrary code execution via plugin or theme installation. Full site takeover from a single compromised Subscriber account.

Who is impacted

• WordPress sites running Highland Software Custom Role Manager at versions <= 1.0.0.
• Sites where attackers can obtain any authenticated session - through self-registration, credential stuffing, or a pre-existing low-privilege account.
• Highest risk: multi-user sites where non-admin accounts exist legitimately - membership platforms, WooCommerce stores, forums, editorial workflows.

What to do now

• Update immediately to 1.0.1 or any newer patched release.

  "Remediation Update to version 1.0.1, or a newer patched version"

• Inventory production WordPress instances for the plugin slug highland-software-custom-role-manager and confirm the installed version.
• Audit for abuse - assume exploitation is possible during the window the vulnerable version was running:
  • Review recently changed user roles, especially unexpected new administrator assignments.
  • Review profile update activity logs around and before the disclosure date for suspicious patterns.
• If your site allows open self-registration, consider tightening that temporarily while you patch - fewer Subscriber accounts means a smaller attack surface.
• If you suspect compromise, rotate credentials accessible to the WordPress runtime: database password, SMTP credentials, third-party API keys. Validate plugin and theme file integrity before trusting the site as clean.