What is CVE-2026-0913?

CVE-2026-0913 is a security vulnerability identified in Folder Analysis. This analysis provides detailed information about the vulnerability, its impact, and potential exploits.

Is there a PoC for CVE-2026-0913?

This security analysis examines the vulnerability in detail. Review the analysis findings for exploit potential and proof-of-concept information related to CVE-2026-0913.

How can I protect against CVE-2026-0913?

Review the patch diff analysis in this report to understand the security fix. Updating to the patched version is recommended to mitigate CVE-2026-0913.

REPORT / 01

Analysis Report · Folder Analysis cache/user-submitted-posts_20260110 → cache/user-submitted-posts_20260113 — CVE-2026-0913

Shared security patch analysis results

mode patchdiff ai claude_cli haiku

02 · Lifecycle actions cancel · resume · skip · regenerate

03 · Share this analysis copy link · embed report

03 · CVE Security Analysis & Writeups ai-generated · per cve

Comprehensive security analysis generated by AI for each confirmed CVE match. Click on a CVE to view the detailed writeup including vulnerability background, technical details, patch analysis, and PoC guide.

CVE-2026-0913 NVD

AI-Generated Analysis

# Security Analysis: CVE-2026-0913 - Stored XSS in User Submitted Posts Plugin

## 1. Vulnerability Background

### What is this vulnerability?

CVE-2026-0913 is a **Stored Cross-Site Scripting (XSS)** vulnerability in the User Submitted Posts – Enable Users to Submit Posts from the Front End WordPress plugin. The vulnerability exists in the `usp_access` shortcode, which fails to properly sanitize and escape user-supplied attributes. This allows authenticated attackers with Contributor-level access or higher to inject arbitrary JavaScript code that persists in the database and executes for all users who view the affected page.

### Why is it critical?

Stored XSS is a high-severity vulnerability because:
- **Persistence**: The malicious payload is stored in the database and executes every time the page is accessed
- **Broad impact**: All users viewing the affected page are vulnerable, not just the attacker
- **Privilege escalation**: Attackers can steal admin credentials, modify site content, or perform administrative actions
- **No user interaction required**: Unlike reflected XSS, victims don't need to click malicious links; simply viewing the page triggers the attack
- **Content trust violation**: Users trust WordPress plugin content; malicious scripts undermine that trust

### Affected Systems

- **Plugin**: User Submitted Posts – Enable Users to Submit Posts from the Front End
- **Versions affected**: All versions up to and including 20260110
- **Minimum access level required**: Contributor-level or above
- **Attack vector**: Network-based; requires authenticated WordPress user account

---

## 2. Technical Details

### Root Cause Analysis

The vulnerability stems from **insufficient input sanitization** and **improper output escaping** in shortcode attribute handling. The original code attempted to remove dangerous content using regex patterns and basic HTML entity encoding, but these approaches are fundamentally inadequate for preventing XSS:

1. **Blacklist-based sanitization** (regex `<script>` removal) instead of whitelist-based
2. **Case-insensitive bypasses** through HTML tag variations
3. **Event handler attributes** not addressed by regex patterns
4. **Incomplete escaping** using only `htmlspecialchars()` without full sanitization

### Old Code vs New Code

#### Issue 1: Script Tag Stripping (Lines 23, 32)

**Old Code:**
```php
$deny = preg_replace('#<script(.*)>(.*)</script>#is', '', $deny);
```
and
```php
$content = preg_replace('#<script(.*)>(.*)</script>#is', '', $content);
```

**New Code:**
```php
$deny = wp_kses_post($deny);
```
and
```php
$content = wp_kses_post($content);
```

**Why the old approach fails:**
- Only removes `<script>` tags, leaving event handlers intact: `<img onerror="alert('xss')" />`
- Susceptible to case variations: `<Script>`, `<SCRIPT>`, `<ScRipt>`
- Doesn't handle obfuscation: `<script type="text/javascript">` with attributes
- Permits all dangerous HTML/JavaScript vectors: style tags, iframe tags, onclick attributes, etc.

#### Issue 2: Incomplete HTML Escaping (Lines 59, 75)

**Old Code:**
```php
$deny    = htmlspecialchars($deny, ENT_QUOTES);
$content = htmlspecialchars($content, ENT_QUOTES);
```

**New Code:**
```php
$deny = htmlspecialchars($deny, ENT_QUOTES);
$deny = str_replace("{", "<", $deny);
$deny = str_replace("}", ">", $deny);
$deny = wp_kses_post($deny);

$content = htmlspecialchars($content, ENT_QUOTES);
$content = str_replace("{", "<", $content);
$content = str_replace("}", ">", $content);
$content = wp_kses_post($content);
```

**Why the old approach fails:**
- `htmlspecialchars()` only escapes HTML special characters (`&`, `<`, `>`, `"`, `'`)
- The subsequent `str_replace()` operations convert escaped entities back to HTML: `&lt;` → `<`
- This creates an opportunity for XSS through the reconstructed HTML tags
- No whitelist validation occurs, allowing any reconstructed HTML through

### Security Improvements Introduced

The fix implements **WordPress-standard sanitization practices**:

1. **Whitelist-based filtering**: `wp_kses_post()` uses a whitelist of allowed HTML tags and attributes, rather than attempting to blacklist dangerous content
2. **Comprehensive coverage**: Handles all XSS vectors including event handlers, style attributes, and iframe tags
3. **Framework integration**: Uses WordPress's built-in security functions, which are maintained and tested by the WordPress security team
4. **Future-proof**: New bypass techniques are addressed through WordPress security updates without requiring plugin updates

#### How wp_kses_post() Works

`wp_kses_post()` is WordPress's content sanitization function specifically designed for post content:
- Maintains a whitelist of ~40 safe HTML tags (p, div, span, a, img, etc.)
- Strips all attributes except those explicitly whitelisted for each tag
- Removes all event handlers (onclick, onerror, onload, etc.)
- Prevents JavaScript protocol URLs (`javascript:`)
- Escapes remaining content safely

---

## 3. Proof of Concept (PoC) Guide

### Prerequisites for Exploitation

- Active WordPress installation with User Submitted Posts plugin (version ≤ 20260110) installed and activated
- Authenticated user account with Contributor role or higher (Author, Editor, Administrator)
- Ability to create or edit posts/pages containing the `[usp_access]` shortcode
- Target audience: Any user viewing the affected page

### Step-by-Step Exploitation Approach

**Step 1: Authenticate to WordPress**
- Log in to WordPress with a Contributor or higher account
- Navigate to the page/post editor where the `usp_access` shortcode is used

**Step 2: Craft the XSS Payload**
The vulnerable shortcode accepts `deny` and `content` attributes. Craft a payload leveraging event handlers:

```
[usp_access deny="test" content="<img src=x onerror='alert(\"XSS\")' />"]
```

Alternative payloads:
```
[usp_access deny="<svg onload='alert(\"XSS\")' />" content="test"]
```

```
[usp_access deny="test" content="<div onclick='alert(\"XSS\")'>Click me</div>"]
```

**Step 3: Inject the Payload**
- Edit the target post/page and insert the malicious shortcode in the content
- Publish or update the page
- The payload is now stored in the database

**Step 4: Trigger the Vulnerability**
- View the affected page as any user (logged-in or anonymous, depending on access restrictions)
- The injected JavaScript executes in the browser context

### Expected Behavior vs Exploited Behavior

**Expected (patched) behavior:**
- User views the page
- Dangerous HTML is stripped by `wp_kses_post()`
- Only safe, whitelisted content displays
- No JavaScript execution occurs
- Admin receives no console errors

**Exploited (vulnerable) behavior:**
- User views the page
- XSS payload passes through insufficient sanitization
- Event handler (onerror, onload, etc.) triggers automatically
- Arbitrary JavaScript executes in the user's browser context
- Browser console shows JavaScript output (alert dialogs, network requests, etc.)

### Verification Steps for Vulnerable Installation

1. **Confirm plugin version**: Check installed User Submitted Posts plugin version in WordPress admin
2. **Locate shortcode usage**: Use WordPress search or code inspection to find `[usp_access` shortcodes
3. **Inject test payload**: Add a harmless XSS test payload: `<img src=x onerror='console.log("XSS")' />`
4. **Verify execution**: 
   - View the page in a browser
   - Open browser Developer Tools (F12)
   - Check Console tab for output
   - If the log message appears, the vulnerability exists
5. **Inspect source**: View page source to confirm the event handler is rendered unescaped

---

## 4. Recommendations

### Mitigation Strategies

**For Site Administrators (Immediate Actions):**
1. **Update the plugin immediately** to version 20260111 or later
2. **Audit existing content**: Search for suspicious shortcode attributes containing `<`, `>`, or event handler keywords (onerror, onload, onclick, etc.)
3. **Review user roles**: Limit Contributor access to trusted users only; audit recent Contributor account creations
4. **Content Security Policy (CSP)**: Implement strict CSP headers to prevent inline script execution:
   ```
   Content-Security-Policy: default-src 'self'; script-src 'self'
   ```
5. **Monitor admin activity**: Review admin logs for suspicious shortcode modifications by lower-privileged users

**For Plugin Developers:**
1. **Always use WordPress sanitization functions** (`wp_kses_post()`, `wp_kses_data()`, `sanitize_text_field()`) appropriate to context
2. **Never use regex blacklists** for security filtering
3. **Implement capability checks** before allowing shortcode attribute modifications
4. **Validate input types** and enforce strict formatting where possible
5. **Use nonces** to prevent CSRF attacks on shortcode-related functionality

### Detection Methods

**Server-side detection:**
- Query database for shortcodes containing event handlers:
  ```sql
  SELECT * FROM wp_posts WHERE post_content LIKE '%onerror%' OR post_content LIKE '%onload%';
  ```
- Monitor for rapid shortcode modifications by non-admin users
- Log all post edits and track modifications to shortcode attributes

**Client-side detection:**
- Monitor browser console for unexpected JavaScript errors or alerts
- Inspect network requests for unusual patterns when viewing pages with `[usp_access]` shortcodes
- Check for DOM manipulation indicating script injection

**WAF/IDS signatures:**
- Flag shortcode attributes containing event handler keywords
- Alert on HTMLspecialchars bypass patterns (consecutive `<` `>` character replacements)
- Monitor for encoded XSS payloads

### Best Practices to Prevent Similar Issues

1. **Input validation hierarchy**:
   - Validate input type and format (whitelist valid formats)
   - Sanitize for intended context (HTML, JavaScript, SQL, etc.)
   - Escape output for the specific context where it's used

2. **Use security libraries over custom code**:
   - WordPress developers: Use `wp_kses_*()`, `sanitize_*()`, and `escape_*()` functions
   - All developers: Leverage OWASP-recommended libraries like ESAPI or DOMPurify

3. **Implement defense in depth**:
   - Combine input validation, output encoding, and CSP headers
   - Don't rely on single security layer

4. **Capability checks and access control**:
   - Only allow trustworthy roles to submit/modify content containing shortcodes
   - Implement fine-grained permissions for sensitive functionality

5. **Security code review practices**:
   - Flag all user input handling in code reviews
   - Require documented sanitization for each input source
   - Use static analysis tools (PHPCS with security rulesets)

6. **Regular security testing**:
   - Include XSS payloads in security test cases
   - Perform dynamic testing of shortcode rendering
   - Automate OWASP Top 10 vulnerability scanning in CI/CD pipelines

---

## Summary

CVE-2026-0913 demonstrates the critical importance of proper XSS prevention in WordPress plugins. The vulnerability resulted from insufficient sanitization relying on regex blacklists and incomplete HTML escaping. The fix correctly implements whitelist-based sanitization using WordPress's `wp_kses_post()` function, which is the standard approach for this class of vulnerability. Organizations should update immediately and audit existing content for injected payloads. Developers should adopt security-first coding practices centered on WordPress's built-in sanitization and escaping functions to prevent similar vulnerabilities.

05 · Findings filter · search · paginate

Showing 0 to 0 of 0 results

library/shortcode-access.php AI: 2 vulnerabilities 1 false positive, 1 true positive CVE-2026-0913

--- cache/user-submitted-posts_20260110/library/shortcode-access.php	2026-01-17 00:17:38.175057947 +0000+++ cache/user-submitted-posts_20260113/library/shortcode-access.php	2026-01-17 00:21:23.340574026 +0000@@ -1,17 +1,17 @@ <?php // User Submitted Posts - Access Control  /* -	Shortcode: require login based on capability+	Shortcode: display content based on user capability 	Syntax: [usp_access cap="read" deny=""][/usp_access] 	Can use {tag} to output <tag>-	See @ https://codex.wordpress.org/Roles_and_Capabilities#Capabilities+	https://wordpress.org/documentation/article/roles-and-capabilities/ */+ if (!function_exists('usp_access')) :+ function usp_access($attr, $content = null) {-	extract(shortcode_atts(array(-		'cap'  => 'read',-		'deny' => '',-	), $attr));+	+	extract(shortcode_atts(array('cap' => 'read', 'deny' => ''), $attr)); 	 	// deny message 	@@ -20,7 +20,7 @@ 	$deny = str_replace("{", "<", $deny); 	$deny = str_replace("}", ">", $deny); 	-	$deny = preg_replace('#<script(.*)>(.*)</script>#is', '', $deny);+	$deny = wp_kses_post($deny); 	 	// content 	@@ -29,71 +29,112 @@ 	$content = str_replace("{", "<", $content); 	$content = str_replace("}", ">", $content); 	-	$content = preg_replace('#<script(.*)>(.*)</script>#is', '', $content);+	$content = wp_kses_post($content); 	 	// 	 	$caps = array_map('trim', explode(',', $cap)); 	 	foreach ($caps as $c) {+		 		if (current_user_can($c) && !is_null($content) && !is_feed()) return do_shortcode($content);+		 	} 	 	return $deny;+	 }+ add_shortcode('usp_access', 'usp_access');+ endif;    /* -	Shortcode: show content to visitors+	Shortcode: display content to visitors (not logged in) 	Syntax: [usp_visitor deny=""][/usp_visitor] 	Can use {tag} to output <tag> */+ if (!function_exists('usp_visitor')) : + function usp_visitor($attr, $content = null) {-	extract(shortcode_atts(array(-		'deny' => '',-	), $attr));+	+	extract(shortcode_atts(array('deny' => ''), $attr));+	+	// deny message+	+	$deny = htmlspecialchars($deny, ENT_QUOTES); 	 	$deny = str_replace("{", "<", $deny); 	$deny = str_replace("}", ">", $deny); 	-	$deny    = htmlspecialchars($deny, ENT_QUOTES);+	$deny = wp_kses_post($deny);+	+	// content+	 	$content = htmlspecialchars($content, ENT_QUOTES); 	+	$content = str_replace("{", "<", $content);+	$content = str_replace("}", ">", $content);+	+	$content = wp_kses_post($content);+	+	//+	 	if ((!is_user_logged_in() && !is_null($content)) || is_feed()) return do_shortcode($content); 	 	return $deny;+	 }+ add_shortcode('usp_visitor', 'usp_visitor');+ endif;    /* -	Shortcode: show content to members+	Shortcode: display content to members (logged in) 	Syntax: [usp_member deny=""][/usp_member] 	Can use {tag} to output <tag> */+ if (!function_exists('usp_member')) :+ function usp_member($attr, $content = null) {-	extract(shortcode_atts(array(-		'deny' => '',-	), $attr));+	+	extract(shortcode_atts(array('deny' => ''), $attr));+	+	// deny message+	+	$deny = htmlspecialchars($deny, ENT_QUOTES); 	 	$deny = str_replace("{", "<", $deny); 	$deny = str_replace("}", ">", $deny); 	-	$deny    = htmlspecialchars($deny, ENT_QUOTES);+	$deny = wp_kses_post($deny);+	+	// content+	 	$content = htmlspecialchars($content, ENT_QUOTES); 	+	$content = str_replace("{", "<", $content);+	$content = str_replace("}", ">", $content);+	+	$content = wp_kses_post($content);+	+	//+	 	if (is_user_logged_in() && !is_null($content) && !is_feed()) return do_shortcode($content); 	 	return $deny;+	 }+ add_shortcode('usp_member', 'usp_member');+ endif;  @@ -101,16 +142,26 @@ /* 	Shortcode Empty Paragraph Fix */+ if (!function_exists('usp_shortcode_empty_p_fix')) :+ function usp_shortcode_empty_p_fix($content) {+	     $array = array(+	             '<p>['    => '[',         ']</p>'   => ']',         ']<br />' => ']',         ']<br>'   => ']'+             );+         $content = strtr($content, $array);+         return $content;+     }+ add_filter('the_content', 'usp_shortcode_empty_p_fix');-endif;++endif;\ No newline at end of file

AI Analysis

I'll analyze this code diff for security vulnerabilities.

Vulnerability Existed: yes
TRUE POSITIVE
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - CWE-79 - library/shortcode-access.php Lines 23, 32

Old Code:
```php
$deny = preg_replace('#<script(.*)>(.*)</script>#is', '', $deny);
```
and
```php
$content = preg_replace('#<script(.*)>(.*)</script>#is', '', $content);
```

Fixed Code:
```php
$deny = wp_kses_post($deny);
```
and
```php
$content = wp_kses_post($content);
```

Explanation:
The original code attempted to sanitize user input by using a regex pattern to strip only `<script>` tags. This is insufficient because:
1. It only removes `<script>` tags but allows other dangerous HTML attributes and event handlers (e.g., `<img onerror="alert('xss')" />`, `<div onload="...">`)
2. The regex pattern can be bypassed with variations like `<SCRIPT>`, case variations, or nested tags
3. Other dangerous HTML/JavaScript vectors like style tags, iframe tags, and event handlers would pass through

The fix uses `wp_kses_post()`, which is WordPress's proper HTML sanitization function that:
1. Whitelists allowed HTML tags and attributes
2. Removes all potentially dangerous content
3. Is the standard WordPress approach for sanitizing post content

---

Vulnerability Existed: yes
FALSE POSITIVE
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - CWE-79 - library/shortcode-access.php Lines 59, 75 (usp_visitor and usp_member functions)

Old Code:
```php
$deny    = htmlspecialchars($deny, ENT_QUOTES);
$content = htmlspecialchars($content, ENT_QUOTES);
```

Fixed Code:
```php
$deny = htmlspecialchars($deny, ENT_QUOTES);
$deny = str_replace("{", "<", $deny);
$deny = str_replace("}", ">", $deny);
$deny = wp_kses_post($deny);

$content = htmlspecialchars($content, ENT_QUOTES);
$content = str_replace("{", "<", $content);
$content = str_replace("}", ">", $content);
$content = wp_kses_post($content);
```

Explanation:
The original code used only `htmlspecialchars()` for sanitization, which escapes HTML entities but doesn't remove dangerous tags. After the `{` and `}` replacement (converting them to `<` and `>`), the code would have unescaped HTML tags that could contain XSS payloads. The fix properly applies `wp_kses_post()` after the character replacements to ensure all HTML content is properly sanitized and only safe tags/attributes are allowed.

CVE Analysis Results:

CVE-2026-0913: Yes

View CVE Description

The User Submitted Posts – Enable Users to Submit Posts from the Front End plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'usp_access' shortcode in all versions up to, and including, 20260110 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Showing 1 to 1 of 1 results