Description

The Media Library Assistant plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the bulk edit preset export/import mechanism in versions up to and including 3.35. This is due to insufficient output escaping on preset field values when they are rendered in HTML attribute contexts in the mla_generate_bulk_edit_form_fieldsets() function and mla-bulk-edit-fieldsets.tpl template. While wp_kses() filtering is applied during preset export for users without unfiltered_html capability, this does not prevent attribute injection attacks since the malicious payload consists of quotes and HTML attributes rather than HTML tags. When preset values are retrieved and rendered, they are directly assigned to template variables without esc_attr() escaping and then inserted into input element value attributes via simple string replacement. This makes it possible for authenticated attackers, with Author-level access and above (upload_files capability), to inject arbitrary web scripts that execute when an administrator imports the poisoned preset and the targeted input field receives focus.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-09-11T08:16:48.007Z",
  "pubdate": "2026-09-11T08:16:48.007Z",
  "executiveSummary": "The Media Library Assistant plugin for WordPress, in versions up to and including 3.35, is susceptible to a Stored Cross-Site Scripting (XSS) vulnerability. This flaw resides within the bulk edit preset export/import mechanism, allowing authenticated users with the 'upload_files' capability (Author-level and above) to inject arbitrary malicious scripts.\nThe vulnerability arises from improper handling of preset field values during the rendering process in HTML attribute contexts. By crafting a poisoned preset file containing specific HTML attributes and quotes, an attacker can bypass existing sanitization mechanisms, as current filtering logic targets HTML tags rather than attribute-based injections.\nThe primary risk involves the execution of unauthorized scripts in the context of an administrator's browser session. When an administrator imports a manipulated preset and interacts with the affected input fields, the stored payload executes. This could lead to account takeover, unauthorized administrative actions, or unauthorized data access, significantly compromising the security integrity of the WordPress environment.\nSuccessful exploitation requires authenticated access to the plugin's interface. Given the impact, users are urged to treat preset files from untrusted sources with extreme caution until official remediation is implemented.",
  "technicalDetails": "The root cause of this vulnerability is the failure to apply context-aware output escaping within the 'mla_generate_bulk_edit_form_fieldsets()' function and the 'mla-bulk-edit-fieldsets.tpl' template. While the plugin utilizes 'wp_kses()' during the export process to filter malicious input, this function is primarily designed to strip or sanitize HTML tags. It does not effectively neutralize payloads designed for attribute injection, such as those utilizing nested quotes or malicious event handlers within input field attributes.\nThe vulnerability manifests when the plugin processes these presets. The data is retrieved and directly injected into template variables. These variables are subsequently placed into the 'value' attribute of HTML input elements via basic string replacement without passing through 'esc_attr()'. Consequently, an attacker can escape the 'value' attribute context by injecting double quotes followed by malicious event handlers, such as 'onfocus' or 'onmouseover', accompanied by JavaScript payloads.\nThe attack flow follows a specific progression: First, an authenticated attacker with 'upload_files' permissions modifies the structure of a preset file to include an attribute-based XSS payload. Second, this poisoned preset is exported or staged for import. Third, a privileged user, typically an administrator, imports the malicious preset into their WordPress instance. Finally, the payload remains stored within the plugin settings until the administrator navigates to the affected bulk edit interface. When the administrator interacts with the specific input field rendered via 'mla-bulk-edit-fieldsets.tpl', the browser interprets the injected attributes, triggering the execution of the arbitrary JavaScript within the administrator's session context.\nBecause the payload is stored persistently in the database, the execution is not immediate upon import but occurs upon user interaction. This persistence allows for a delayed-execution attack vector that circumvents simple signature-based network defenses. The lack of proper output sanitization at the sink point (the template rendering phase) renders the application incapable of distinguishing between legitimate configuration data and malicious executable code injected within the attribute space. The impact is escalated significantly due to the high-privilege context of the targeted administrators, enabling the potential for full site compromise or session hijacking."
}