Improper output filtering in Drupal Plausible tracking enables Cross-Site Scripting

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Drupal Plausible tracking allows Cross-Site Scripting (XSS).This issue affects Plausible tracking: from 0.0.0 before 1.0.2.

• Vendor: Drupal. Product: Plausible tracking, machine name plausible_tracking.
• Versions from 0.0.0 before 1.0.2 are identified as affected under semver.
• The Drupal advisory identifies 1.0.2 as the fixed release. No separate parallel branch or status for other release lines is confirmed by the available evidence.

Drupal Plausible tracking did not properly filter output in certain cases, creating a CWE-79 Cross-Site Scripting vulnerability. The vendor states that exploitation is mitigated because an attacker must have permission to add raw HTML to the website, such as through an unfiltered WYSIWYG field on a public-facing comment. When affected content is rendered for another user, insufficiently neutralized data may be processed by the browser as script. The advisory does not identify the specific endpoint, template, output sink, or encoding context, so those implementation details remain unknown. The affected scope is the Drupal Plausible tracking module.

The vulnerability is reachable over the network through web pages generated by Drupal. The Drupal advisory states that the attacker must have permission to add raw HTML, but the supplied scoring metadata models the privileges requirement as none; operational assessment should therefore use the actual Drupal permissions and content workflow in the deployment. A user must interact with or render affected content for the XSS to execute. The record characterizes attack complexity as low and does not identify an additional authentication requirement beyond the content-permission condition described by the vendor. The supplied record does not identify a public exploit or known exploitation campaign; returned enrichment records exploitation as none, but that status is not proof that exploitation is impossible.

Successful XSS may execute JavaScript in the browser context of a user who views affected content. Depending on that user's permissions, the script could read data available to the user or perform actions allowed by the active session. The record describes limited confidentiality and integrity consequences and does not establish an availability consequence. Actual impact depends on the rendered content, victim permissions, CSP, and browser protections. The evidence does not show that the vulnerability by itself provides server-side code execution or affects every user of a site.

Drupal sites using Plausible tracking may allow untrusted script to execute in a user's browser when affected content is displayed. Depending on the victim's permissions and browser protections, the result could include access to data visible to that user or actions performed within the user's active site context. The risk is more relevant to sites with public comments, unfiltered WYSIWYG fields, or workflows that allow multiple accounts to insert raw HTML. The available evidence does not confirm data theft, account takeover, server compromise, or service disruption.

1. Upgrade the Drupal Plausible tracking module to exactly version 1.0.2, which the Drupal advisory identifies as the fixed release.
2. Check the site's inventory and lockfile or manifest to confirm that the deployed package was actually replaced, then verify the version in production.
3. Until the upgrade is complete, review and restrict permission to add raw HTML, especially in public-facing comments and unfiltered WYSIWYG fields. This is exposure reduction based on the vendor's stated precondition and is not a substitute for the fix.
4. Review content created by accounts with that capability and inspect public pages that render the content.
5. Do not assume that every later or parallel release branch is unaffected without separate vendor confirmation.

1. Inventory Drupal sites that install the module with machine name plausible_tracking, then check the deployed version against the affected boundary.
2. Review roles and permissions that can add raw HTML, especially workflows involving public-facing comments or unfiltered WYSIWYG fields.
3. Inspect public content created or edited by accounts with that capability, focusing on locations rendered by the module.
4. Consider CSP violation reports, browser alerts, and unusual content changes as supplementary monitoring. These are precautionary signals, not vendor-confirmed indicators.
5. The advisory does not provide a specific IOC or log signature. The absence of matching log evidence does not demonstrate that a site is safe.