Description

The 12 Step Meeting List WordPress plugin before 3.19.17 does not sanitise and escape a value submitted by unauthenticated users before storing it in its activity log and outputting it back in an admin area page, leading to a Stored Cross-Site Scripting issue which could be used against high privilege users such as admin.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-27T06:17:29.897Z",
  "pubdate": "2026-08-27T06:17:29.897Z",
  "executiveSummary": "The 12 Step Meeting List WordPress plugin prior to version 3.19.17 contains a Stored Cross-Site Scripting (XSS) vulnerability.\nThis flaw arises from the improper handling of user-supplied input that is stored within the plugin's activity logs without adequate sanitization or output escaping.\nThe vulnerability poses a significant risk to administrative users, as malicious payloads injected by unauthenticated attackers are executed within the context of the WordPress admin dashboard.\nSuccessful exploitation allows an attacker to execute arbitrary JavaScript in the browser of a high-privilege user.\nThis can lead to unauthorized actions, session hijacking, or the extraction of sensitive information from the administrative interface.\nBecause the input is processed and stored by the plugin, it does not require authentication to initiate the injection, making it a critical concern for site integrity and security.",
  "technicalDetails": "The vulnerability is a Stored Cross-Site Scripting (XSS) flaw located in the data handling logic of the 12 Step Meeting List WordPress plugin. The root cause is the failure of the application to sanitize input submitted by end-users or apply output encoding when rendering log data in the administrative backend.\nIn the affected versions (prior to 3.19.17), the plugin records interactions within an activity log. Attackers can leverage public-facing input fields—such as search parameters or form submissions—to inject malicious JavaScript payloads. Because the application fails to validate this input, the payload is persisted directly into the WordPress database.\nThe attack flow follows a predictable sequence: First, an unauthenticated attacker identifies an input vector that contributes to the plugin's activity log. Second, the attacker crafts an XSS payload, such as a script tag, and submits it through the identified vector. Third, the plugin, acting as a blind trustor of the input, stores the unsanitized string into the database. Finally, when a high-privilege user, such as an administrator, accesses the plugin's activity log page in the WordPress dashboard, the browser renders the malicious script.\nThe impact is significant because the payload executes with the privileges of the authenticated administrator. This enables a range of post-exploitation activities, including stealing session cookies via document.cookie, performing unauthorized administrative operations (e.g., creating new users, modifying plugin settings, or installing malicious software), and redirecting the administrator to external, malicious sites. Since the rendering occurs in the admin area, the attacker effectively circumvents standard perimeter defenses by hijacking an authorized, trusted session."
}