ANALYSIS · 8bc2dec3 · PATCHDIFF

Folder Analysisforminator_1.57.2 → forminator_1.57.2.1✓ COMPLETED

Started2026-10-09 00:22:57Z Finished2026-10-09 00:24:25Z Elapsed1m 28s

Vulnerabilities 26

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2026-85235

FILTERS 0

STATUS

JUDGE

CVE MATCH

EXTENSION · 1

CWE · 16

OPTIONS

Hide “No vulnerability” Hide unjudged

2/17

All 17 CVE 2 Vuln files 13

SORT

library/class-core.php

AI: 2 vulnerabilities

CWE-502: Deserialization of Untrusted DataCWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')Forminator_Core::allow_xmlrpc_for_registration_formsForminator_Core::sanitize_array+1 MORE CVE-2026-85235 2 TP

#007

library/helpers/helper-forms.php

AI: 1 vulnerabilities

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')forminator_get_rich_textarea_allowed_htmlforminator_is_allowed_rich_textarea_url_attribute CVE-2026-85235 1 TP

#013

1–2 of 2

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2026-85235

Security writeup for CVE-2026-85235

✓ 2 FILES

## The Exploit

An unauthenticated attacker can inject a stored XSS payload into a Rich-Text Textarea field; when a site administrator opens the submission in the Forminator Entries view and clicks a crafted link embedded in the stored data, the payload executes in the administrator's session.

**Step 1: Store the XSS payload via form submission**

```http
POST /index.php?action=forminator_submit_form HTTP/1.1
Host: target.wordpress.local
Content-Type: application/x-www-form-urlencoded

form_id=1&forminator_uid=abc123&forminator_timestamp=1234567890&forminator_nonce=nonce_value&fields[rich_textarea_field]=<a href="&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;alert('XSS')">click me</a>&submit=Submit
```

The attacker URL-encodes a hyperlink with an entity-encoded `javascript:` protocol in the `href` attribute. The form stores this in the database as a Rich-Text Textarea entry. No authentication is required; the form accepts public submissions.

**Step 2: Trigger the payload**

An administrator logs into `wp-admin`, navigates to **Forminator → Entries**, and opens the stored submission containing the injected link. When the admin clicks the link—either intentionally or via social engineering—the entity-encoded `href` is decoded by the browser's HTML parser and by WordPress jQuery-based click handlers, executing the JavaScript in the admin's authenticated context.

The attacker observes the alert box fire in the administrator's browser, confirming code execution. From there, the attacker can steal session cookies, create backdoor admin accounts, or exfiltrate sensitive form data.

---

## What the Patch Did

**Before**

```php
function forminator_get_rich_textarea_allowed_html() {
	$allowed_html = wp_kses_allowed_html( 'post' );

foreach ( $allowed_html as $tag => $attributes ) {
		if ( ! is_array( $attributes ) ) {
			continue;
		}

if ( isset( $allowed_html[ $tag ]['class'] ) ) {
			$allowed_html[ $tag ]['class'] = array(
				'value_callback' => 'forminator_is_allowed_rich_textarea_class_attribute',
			);
		}
	}

return $allowed_html;
}
```

**After**

```php
function forminator_get_rich_textarea_allowed_html() {
	$allowed_html = wp_kses_allowed_html( 'post' );

// Validate URL attributes so entity-encoded markup cannot ride in them.
	$url_attributes = wp_kses_uri_attributes();

foreach ( $allowed_html as $tag => $attributes ) {
		if ( ! is_array( $attributes ) ) {
			continue;
		}

if ( isset( $allowed_html[ $tag ]['class'] ) ) {
			$allowed_html[ $tag ]['class'] = array(
				'value_callback' => 'forminator_is_allowed_rich_textarea_class_attribute',
			);
		}

foreach ( $url_attributes as $url_attribute ) {
			if ( isset( $allowed_html[ $tag ][ $url_attribute ] ) ) {
				$allowed_html[ $tag ][ $url_attribute ] = array(
					'value_callback' => 'forminator_is_allowed_rich_textarea_url_attribute',
				);
			}
		}
	}

return $allowed_html;
}

function forminator_is_allowed_rich_textarea_url_attribute( $url_value ) {
	$decoded = (string) $url_value;

do {
		$previous = $decoded;
		$decoded  = html_entity_decode( $previous, ENT_QUOTES | ENT_HTML5, 'UTF-8' );
	} while ( $decoded !== $previous );

if ( preg_match( '/[<>"\'`]/', $decoded ) ) {
		return false;
	}

return true;
}
```

The patch introduces a new validation callback function `forminator_is_allowed_rich_textarea_url_attribute()` and applies it via `wp_kses` value callbacks to all URL-bearing attributes (`href`, `src`, `data`, etc.) across all HTML tags. The callback decodes entity-encoded characters iteratively (to catch multi-encoded payloads) and rejects any value containing unencoded angle brackets, quotes, or backticks—characters that can break out of HTML and JavaScript sinks.

---

## Root Cause

**CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')**

User-supplied content from public form submissions flows into the Rich-Text Textarea field. The plugin's sanitization pipeline uses `wp_kses()` to allow safe HTML tags and attributes—but `wp_kses()` preserves HTML entities verbatim. An attacker can entity-encode a malicious protocol (`&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;` = `javascript:`), and it will pass `wp_kses()` validation. When the stored data is later rendered in the WordPress admin Entries view, client-side code (jQuery, the browser's HTML parser, or inline event handlers) decodes the entities back into a live `javascript:` link, crossing the trust boundary from a sanitized stored string into executable code.

---

## Why It Works

The load-bearing line is the regex match in `forminator_is_allowed_rich_textarea_url_attribute()`:

```php
if ( preg_match( '/[<>"\'`]/', $decoded ) ) {
    return false;
}
```

Without this check, entity-encoded dangerous characters would still pass validation. The surrounding `while` loop that decodes iteratively is equally critical—it ensures that multi-encoded payloads (e.g., `&#38;#106;` = `&#106;` = `j` when double-decoded) cannot bypass the check by encoding the encoded characters themselves. If you removed just the regex line, an attacker could still inject `&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;` and execute it. The iteration loop prevents a second encoding layer from slipping through. Together, they form a gating function: only URL attribute values that decode to safe, literal text are allowed; anything decoding to HTML syntax is rejected before storage, not just before display.

---

## Hardening Checklist

- Use `wp_kses()` with explicit `value_callback` validators for all user-controlled URL-bearing attributes (not just `class`). Do not rely on `wp_kses()` alone to reject entity-encoded attack vectors; it preserves entities by design.
- Implement iterative entity decoding in validators (`html_entity_decode()` in a loop until the string stabilizes) to catch multi-encoded payloads that single-pass decoding would miss.
- Test form storage endpoints with entity-encoded XSS payloads (e.g., `&#60;script&#62;`) and verify they are either rejected at input validation or stripped from the allowlist before the entry is saved.
- Do not perform `wp_unslash()` at each recursion level when recursively sanitizing nested arrays; unslash once at the entry point, then call `wp_kses()` before storage to avoid encoding-layer bypasses.
- Audit all rich-text and WYSIWYG fields for similar whitelist gaps; apply URL attribute validation consistently across the codebase.

---

## References

- https://nvd.nist.gov/vuln/detail/CVE-2026-85235

CVE CVE-2026-85235

PRODUCT Folder Analysis

AFFECTED ≤ forminator_1.57.2

FIXED IN forminator_1.57.2.1

STATUS Generated

Security writeup · CVE-2026-85235

Source files · 2

library/class-core.php Linked

library/helpers/helper-forms.php Linked

↗ NVD