ANALYSIS · b461f8e5· FINISHED 2026-08-28 · PATCHDIFF

fluentformcache/fluentform_6.1.14 → cache/fluentform_6.1.15✓ COMPLETED

Files26

Vulnerable14

True positives8

CVE matched2

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

CVE-2026-0996

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 26 CVE 2 Vuln 14

SORT

2 files · page 1/1

app/Modules/Ai/AiFormBuilder.php

AI: 2 vulnerabilities

CVE-2026-0996 2 TP

#%!d(float64=007)

app/Services/GlobalSettings/GlobalSettingsHelper.php

AI: 1 vulnerabilities

CVE-2026-0996 1 TP

#%!d(float64=018)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-0996

Security writeup for CVE-2026-0996

✓ 2 FILES

## The Exploit

**A Subscriber-level user can inject arbitrary JavaScript into form definitions by calling the AI Form Builder endpoint without proper capability verification, then trigger code execution when any visitor renders the generated form.**

```http
POST /wp-json/fluentform/v1/ai-form-builder HTTP/1.1
Host: vulnerable-site.local
Authorization: Bearer <subscriber-token>
Content-Type: application/json

{
  "title": "Newsletter Signup",
  "prompt": "Create a form",
  "custom_js": "alert('XSS'); fetch('/wp-admin/?evil=1')"
}
```

The attacker receives a 200 response with `success: true` and the form ID. The `custom_js` payload is stored in the `_custom_form_js` form meta without sanitization. When any user (including admins) visits the page embedding this form, the injected JavaScript executes in their browser context, potentially stealing session cookies or CSRF tokens.

---

## What the Patch Did

**Before:**
```php
Acl::verifyNonce();
```

**After:**
```php
Acl::verify('fluentform_forms_manager');
```

**Before:**
```php
if ($customJs = fluentform_kses_js($customJs)) {
    Helper::setFormMeta($form->id, '_custom_form_js', $customJs);
}
```

**After:**
```php
// Entire custom_js storage pipeline removed
```

The patch replaced the nonce-only verification gate (`verifyNonce()`) with an explicit WordPress capability check (`Acl::verify('fluentform_forms_manager')`), which denies Subscriber-level access. Critically, it also removed the entire `$customJs` parameter and its storage logic — even though `fluentform_kses_js()` attempted sanitization, the patch took the defense-in-depth approach of eliminating the attack surface entirely rather than trusting a single sanitization function.

---

## Root Cause

**CWE-862 (Missing Authorization) + CWE-79 (Improper Neutralization of Input During Web Page Generation).**

The `POST /wp-json/fluentform/v1/ai-form-builder` endpoint in `AiFormBuilder.php` line 30 performed nonce verification but skipped capability checks. The nonce alone did not restrict the caller to users with the `fluentform_forms_manager` capability; any authenticated user (including Subscribers) could forge a valid nonce. The attacker's `custom_js` parameter flowed directly from the HTTP request body (line 59: `Arr::get($form, 'custom_js')`) into the `saveForm()` method (line 86), then into `Helper::setFormMeta()` where it was stored with only `fluentform_kses_js()` filtering — a function designed to whitelist specific JavaScript patterns, not block all arbitrary code injection. When the form rendered on the front-end, the stored `_custom_form_js` meta value executed without re-escaping, crossing the trust boundary from stored data to executable context.

---

## Why It Works

The load-bearing line is `Acl::verify('fluentform_forms_manager')`. Without it, any Subscriber can still send the `custom_js` parameter. If you removed that line but kept the removal of the `custom_js` parameter itself, the vulnerability would close — but the engineer added the capability check anyway for defense-in-depth, because a future maintainer might reintroduce the JavaScript feature and forget to add the authorization gate. The removal of the `$customJs` pipeline (lines 306, 334–336) is the kill shot: even if a bug hunter bypasses the capability check via some other route, there is no `setFormMeta()` call left to accept the payload. This is layered security — authorization failure is caught at ingress; if that fails, the sink no longer exists.

---

## Hardening Checklist

- **Use `current_user_can()` or explicit capability objects before storing user input.** Never rely on nonce verification alone; nonces protect against CSRF but do not enforce role-based access. Always pair `wp_verify_nonce()` with `current_user_can('capability_slug')`.

- **Apply `sanitize_text_field()` to array values in bulk operations.** The patch to `GlobalSettingsHelper.php` line 407 shows this: `array_map('sanitize_text_field', $stylerStyles)`. Never skip array elements in a bulk storage loop.

- **Remove code-execution parameters if they cannot be safely validated.** If a feature like `custom_js` is rarely used or difficult to sanitize, delete the parameter and feature entirely rather than relying on a whitelist function like `fluentform_kses_js()`. Dead code is secure code.

- **Audit AI-generated or user-supplied code endpoints.** AI form builders and template systems are high-risk because they generate HTML/CSS/JS output. Run `WP_DEBUG` and log all calls to `setFormMeta()`, `update_post_meta()`, and output escaping functions to detect silent sanitization failures.

- **Test your authorization gates with low-privilege roles (Subscriber, Contributor).** Use a secondary test account with minimal permissions to confirm that endpoints reject requests before processing payloads.

---

## References

- [CVE-2026-0996 on NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-0996)

CVE CVE-2026-0996

PRODUCT fluentform

AFFECTED ≤ cache/fluentform_6.1.14

FIXED IN cache/fluentform_6.1.15

STATUS Generated

Security writeup · CVE-2026-0996

Source files · 2

app/Modules/Ai/AiFormBuilder.php Linked

app/Services/GlobalSettings/GlobalSettingsHelper.php Linked

↗ NVD