Description

The Hostel plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'custom_currency' parameter and the 'locale_url' setting in all versions up to, and including, 1.1.8 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Administrator-level access, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.4",
  "pubDate": "2026-09-22T08:16:39.230Z",
  "pubdate": "2026-09-22T08:16:39.230Z",
  "executiveSummary": "The Hostel plugin for WordPress, in versions up to and including 1.1.8, contains a Stored Cross-Site Scripting (XSS) vulnerability.\nThe flaw originates from the improper sanitization and escaping of user-supplied input within the 'custom_currency' parameter and the 'locale_url' settings configuration.\nThis vulnerability allows authenticated users with Administrator-level privileges to inject malicious JavaScript into the application, which is then stored and executed in the browser of any user who accesses the compromised page.\nThe scope of this vulnerability is limited to multi-site installations or environments where the 'unfiltered_html' capability has been restricted.\nSuccessful exploitation results in arbitrary script execution, potentially leading to unauthorized administrative actions, session hijacking, or defacement.\nBecause the vulnerability requires administrative access, the primary risk involves privilege escalation or lateral movement within the WordPress administrative environment, particularly in multi-site contexts where cross-site script execution could affect multiple network sites.",
  "technicalDetails": "The vulnerability is a classic Stored XSS flaw stemming from the insufficient validation of input parameters processed by the Hostel plugin's administrative settings interface.\nSpecifically, the application fails to adequately sanitize the 'custom_currency' input field and the 'locale_url' configuration setting before persisting these values to the WordPress database.\nThe absence of context-aware output escaping when these values are later retrieved and rendered in the administrative dashboard or front-end pages allows for the injection of arbitrary HTML or JavaScript tags.\nThe exploitation flow proceeds as follows: First, an authenticated attacker with Administrator-level access navigates to the plugin's settings page. Second, the attacker inserts a malicious payload (e.g., <script>alert(document.cookie);</script>) into either the 'custom_currency' field or the 'locale_url' input field.\nUpon saving the configuration, the plugin executes a database update query without sanitizing the input, effectively storing the malicious script in the database.\nThird, when a user—who may also have administrative privileges—loads an affected page, the plugin retrieves the unsanitized data and reflects it directly into the HTML response stream.\nBecause the application fails to use WordPress-native escaping functions such as esc_html(), esc_attr(), or esc_js(), the browser interprets the injected script as legitimate code and executes it within the security context of the victim's session.\nThe requirement for Administrator-level access suggests that the threat model is primarily focused on 'insider threats' or compromised administrative accounts; however, in a WordPress Multi-site environment, a site administrator might inject a payload that executes in the context of a Network Administrator, leading to a broader compromise of the entire network installation.\nThe impact includes the execution of arbitrary JavaScript, which can be utilized to steal session cookies, perform unauthorized administrative requests via CSRF (Cross-Site Request Forgery), redirect users to malicious domains, or modify the DOM to present fraudulent information.\nThe vulnerability is constrained by the 'unfiltered_html' capability check; in standard WordPress installations, administrators typically possess this capability, allowing them to bypass filter mechanisms. If 'unfiltered_html' is explicitly disabled, the application's failure to perform its own manual input sanitization remains the root cause of the persistence of these malicious scripts."
}