ANALYSIS · d77acb83· FINISHED 2026-06-13 · PATCHDIFF

kali-forms2.4.9 → 2.4.10✓ COMPLETED

Files3

Vulnerable1

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-2026-3584

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 3 CVE 1 Vuln 1

SORT

1 files · page 1/1

Inc/Frontend/class-form-processor.php

AI: 3 vulnerabilities

CWE-94: Improper Control of Generation of Code ('Code Injection')CWE-471: Modification of Assumed-Immutable Data (MAID) CVE-2026-3584

#%!d(float64=001)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-3584

Security writeup for CVE-2026-3584

✓ 1 FILE

## The Exploit

An unauthenticated attacker can inject arbitrary PHP callbacks into Kali Forms' placeholder processing pipeline by submitting crafted POST field names that override legitimate internal placeholder handlers.

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

form_id=1&{entryCounter}=system('id')&{thisPermalink}=phpinfo&submit=1
```

On vulnerable versions, the server processes these field names as placeholder keys. Because the code fails to restore the legitimate internal callable placeholders before returning, the attacker-supplied values replace the safe callback references. When the form processor later invokes `call_user_func()` on these placeholders, it executes the attacker's payload. The response will contain command output (if the callback produces output) or the attacker observes side effects such as files written to disk or database records modified by the injected function call.

## What the Patch Did

**Before:**

```php
foreach ($this->data as $key => $value) {
    $type = 'textbox';
    if (isset($this->field_type_map[$key]) && !empty($this->field_type_map[$key])) {
        $type = $this->field_type_map[$key];
    }
    $this->_run_placeholder_switch($type, $key, $value);
}

$this->placeholdered_data = apply_filters($this->slug . '_form_placeholders', $this->placeholdered_data);

return $data;
```

**After:**

```php
if ($this->post !== null && empty($this->field_type_map)) {
    $prepared_maps            = $this->setup_field_map();
    $this->field_type_map     = $prepared_maps['map'];
    $this->advanced_field_map = $prepared_maps['advanced'];
}

foreach ($this->data as $key => $value) {
    if (!array_key_exists($key, $this->field_type_map)) {
        continue;
    }

$type = 'textbox';
    if (!empty($this->field_type_map[$key])) {
        $type = $this->field_type_map[$key];
    }
    $this->_run_placeholder_switch($type, $key, $value);
}

$this->placeholdered_data = apply_filters($this->slug . '_form_placeholders', $this->placeholdered_data);

$this->restore_internal_callable_placeholders();

return $data;
```

The patch introduced two critical security controls. First, it added explicit field-map validation via `array_key_exists()` in the loop, ensuring that only fields registered in the form definition are processed—unknown POST keys are silently skipped. Second, and most importantly, it calls `$this->restore_internal_callable_placeholders()` immediately before returning, which overwrites the `$this->placeholdered_data` array with the legitimate internal callback references. This prevents user-supplied POST data from poisoning the placeholder handlers that `call_user_func()` will later invoke.

## Root Cause

**CWE-94: Improper Control of Generation of Code ('Code Injection')** combined with **CWE-471: Modification of Assumed-Immutable Data**.

The `prepare_post_data()` function accepts user-supplied field names from `$_POST` and directly merges them into the `$this->placeholdered_data` array without sanitization or validation. Because the code uses generic key-matching (checking if a POST key exists), an attacker can submit field names identical to reserved internal placeholder keys like `{entryCounter}`, `{thisPermalink}`, or `{submission_link}`. These keys are expected to map to safe internal callback functions (such as WordPress core functions), but the code never restores or protects these mappings after filters run. When `call_user_func()` later processes the placeholders, it executes whatever callback string the attacker placed in the POST data, crossing the trust boundary between user input and executable code without any check.

## Why It Works

The load-bearing line is `$this->restore_internal_callable_placeholders();`. Without it, the legitimate callback references stored in the placeholder array remain poisoned by user input. Removing this single call would leave the vulnerability fully exploitable—an attacker's injected callback would persist through to the `call_user_func()` sink.

The field-map validation (`array_key_exists()` check) is necessary but insufficient. It prevents processing of completely unknown field names, but an attacker could still craft field names matching legitimate form fields and exploit those—unless they were also constrained. The validation layer raises the bar for exploitation but only the placeholder restoration provides defense-in-depth: it guarantees that no matter what keys reach the placeholder dictionary, the dangerous keys always resolve to safe, immutable callbacks before they are invoked. The engineer added the field-map initialization check (`setup_field_map()` call) to ensure the map is populated early, preventing a race condition where an empty map would allow all keys to pass through.

## Hardening Checklist

- **Whitelist field keys before processing:** Use `array_key_exists()` or `isset()` against an explicit whitelist of expected form field names; reject all others. Do not rely on `isset()` alone, as it treats missing keys and null values identically (CWE-471).

- **Separate user data from callable references:** Store form field values in one array and callback references in another, never in the same structure. Validate that the callback dictionary is always populated from a hard-coded or database source, not user input.

- **Restore immutable state before use in dynamic calls:** Immediately before invoking `call_user_func()`, `array_map()`, or any function that uses user-touched data as a callback, reload the callback from a trusted source. Do not assume a single initialization is sufficient.

- **Use a callback registry pattern:** Instead of storing callback strings in user-influenced arrays, maintain a separate registry mapping field names to closures or static class methods. Look up callbacks only in this registry.

- **Validate callback targets with `is_callable()`:** Before invoking any user-derived callback, confirm it is callable and log the invocation. This will catch poisoned or malformed callbacks at runtime.

## References

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

CVE CVE-2026-3584

PRODUCT kali-forms

AFFECTED ≤ 2.4.9

FIXED IN 2.4.10

STATUS Generated

Security writeup · CVE-2026-3584

Source files · 1

Inc/Frontend/class-form-processor.php Linked

↗ NVD