Photo Gallery by 10Web – Mobile-Friendly Image Gallery <= 1.8.38 - Authenticated (Editor+) Stored Cross-Site Scripting

I cannot fulfill the request to generate a detailed exploitation plan, specific payloads, or actionable attack instructions for this vulnerability. I can, however, explain the mechanics of Stored Cross-Site Scripting (XSS) in WordPress from a defensive and educational perspective, and discuss how such vulnerabilities are typically identified and remediated.

Understanding Stored XSS in WordPress

Stored Cross-Site Scripting (XSS) occurs when a web application receives data from a user, stores it in a persistent database without proper validation or sanitization, and then later renders that data in a web page without adequate escaping.

In the context of WordPress plugins, this often happens when plugin settings, post metadata, or user profile information are handled insecurely.

1. Vulnerability Mechanics

The vulnerability typically follows this lifecycle:

1. Injection: An authenticated user (e.g., an Editor or Author) submits data through a plugin’s interface (like a settings page or a gallery management screen).
2. Storage: The plugin receives this input and uses functions like update_option(), update_post_meta(), or direct SQL queries to store the raw, uncleaned input in the WordPress database (wp_options or wp_postmeta tables).
3. Rendering: When another user (often an Administrator) views the affected page, the plugin retrieves the stored data using get_option() or get_post_meta() and echoes it directly into the HTML output.
4. Execution: Because the output is not escaped (e.g., using esc_html() or esc_attr()), the browser interprets any embedded <script> tags or malicious attributes (like onerror) as executable code in the context of the viewing user’s session.

2. Key Defensive Controls

WordPress provides several mechanisms to prevent these issues:

• Sanitization (Input): Before saving data, plugins should use sanitization functions to strip or encode dangerous characters.
  • sanitize_text_field(): Removes tags and extra whitespace.
  • wp_kses(): Allows only specific, safe HTML tags and attributes.
• Escaping (Output): This is the most critical defense. Data must be escaped at the moment of output, based on the HTML context.
  • esc_html(): For data rendered between HTML tags.
  • esc_attr(): For data rendered inside HTML attributes.
  • esc_url(): For links and image sources.
• Authorization and Intent Verification:
  • Capability Checks: Functions like current_user_can('manage_options') ensure only authorized users can modify settings.
  • Nonces: Cryptographic-like tokens (wp_create_nonce() and check_admin_referer()) verify that the request was intentionally made by the user and not via a Cross-Site Request Forgery (CSRF) attack.

Vulnerability Analysis Methodology

Security researchers often identify these issues by:

1. Auditing Input Sinks: Identifying where $_POST or $_GET data is processed.
2. Tracing Data Flow: Following that data to see if it reaches a storage function without being sanitized.
3. Auditing Output Sinks: Identifying where stored data is retrieved and rendered.
4. Verifying Context: Checking if the output is correctly escaped for its specific HTML context (e.g., if it's inside an attribute but only esc_html() was used, it may still be vulnerable).

For developers looking to secure their plugins, the WordPress Plugin Handbook provides comprehensive guides on sanitizing, escaping, and validating data.