Description

The HireZoot WordPress plugin before 4.0.0 does not sanitise and escape one of its job specification settings before it is reflected back into an admin-area settings page, allowing users with the HireZoot WordPress plugin before 4.0.0's management capability (Administrator by default) to store a payload that is executed in the browser of any administrator who later opens that page. As the unfiltered_html capability is not available to administrators on multisite (or where DISALLOW_UNFILTERED_HTML is set), this leads to Stored Cross-Site Scripting.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.5",
  "pubDate": "2026-10-12T06:16:58.173Z",
  "pubdate": "2026-10-12T06:16:58.173Z",
  "executiveSummary": "The HireZoot WordPress plugin, specifically in versions prior to 4.0.0, contains a Stored Cross-Site Scripting (XSS) vulnerability within its job specification settings.\nThe vulnerability arises due to the failure of the application to properly sanitize and escape user-supplied input before rendering it in the administrative interface.\nAn authenticated attacker possessing the plugin's management capability—typically assigned to the Administrator role—can inject malicious JavaScript payloads into the settings configuration.\nWhen a subsequent administrator accesses the affected settings page, the stored payload is executed within the context of their browser session.\nThis vulnerability poses a significant risk as it allows for unauthorized actions performed on behalf of the victim administrator, potentially leading to privilege escalation, session hijacking, or administrative account takeover.\nThe exploit is restricted to authenticated users with specific plugin management permissions and is particularly relevant in environments where unfiltered_html capabilities are restricted, such as WordPress Multisite installations.",
  "technicalDetails": "The root cause of this vulnerability is an improper input validation and output encoding flaw located within the HireZoot plugin's settings management module. The application fails to implement adequate sanitization routines for user-supplied data intended for storage within the plugin's configuration schema.\nWhen a user with the required management capability modifies the job specification settings, the plugin stores the raw input directly into the WordPress database without validation. Consequently, the stored data lacks the necessary output escaping (e.g., HTML entity encoding) when retrieved and rendered on the administrative dashboard.\nThe attack flow proceeds as follows: First, an authenticated attacker with administrative privileges accesses the HireZoot settings interface. Second, the attacker injects a crafted malicious script—such as a document.cookie exfiltration payload—into one of the job specification fields. Third, the application saves this payload as part of the plugin configuration. Finally, when another administrator navigates to the administrative page where these settings are reflected, the browser interprets the stored input as executable code, triggering the XSS.\nBecause the vulnerability executes in the context of an administrator's browser, the attacker can perform any action the administrator is authorized to perform. This includes creating new administrative accounts, modifying site configuration, or deploying further malicious artifacts. The impact is elevated because the script executes every time the affected page is rendered, ensuring persistence until the malicious entry is manually removed from the database.\nThis vulnerability is especially critical in multisite environments or instances where 'DISALLOW_UNFILTERED_HTML' is defined, as these configurations typically prevent administrators from executing arbitrary code via standard content fields. By exploiting a plugin-specific settings field, an attacker bypasses these standard WordPress security posture controls.\nThe attack is characterized as Stored XSS, meaning the payload resides permanently on the server-side storage medium and does not require social engineering to trigger, as it relies on the internal administrative workflow of the plugin's management page."
}