ANALYSIS · 69bb2be6· FINISHED 2026-01-10 · PATCHDIFF

Folder Analysiscache/wedocs_2.1.15 → cache/wedocs_2.1.16✓ COMPLETED

Files8

Vulnerable2

True positives2

CVE matched1

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

CVE-2025-14574

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 8 CVE 1 Vuln 2

SORT

1 files · page 1/1

includes/API/SettingsApi.php

AI: 1 vulnerabilities

CWE-284: Improper Access Control CVE-2025-14574 1 TP

#%!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-2025-14574

Security writeup for CVE-2025-14574

✓ 1 FILE

## The Exploit

An unauthenticated attacker can read the plugin settings JSON directly.

```bash
curl -i -H "Accept: application/json" \
  http://target.example/wp-json/wp/v2/docs/settings
```

The request returns HTTP 200 and a JSON body containing plugin settings, including third-party service credentials and API keys. There is no login prompt, and the attack works without any cookies or bearer tokens.

## What the Patch Did

Before
```php
'permission_callback' => '__return_true',
```

After
```php
'permission_callback' => array( $this, 'get_items_permissions_check' ),
```

The patch replaces a blanket allow-all callback with a real REST permission filter. The fix delegates authorization to the plugin's `get_items_permissions_check()` method, which enforces a WordPress capability check before exposing settings.

## Root Cause

This is CWE-284: Improper Access Control. The REST route registration for `/wp-json/wp/v2/docs/settings` used `__return_true` as its `permission_callback`, so any request bypassed authentication entirely and reached the settings serializer. The attacker-controlled value is simply the request itself to that endpoint; the trust boundary crossed unchecked is the boundary between anonymous HTTP clients and sensitive plugin configuration data.

## Why It Works

The load-bearing change is the permission callback line. If you remove or revert that single line, the endpoint returns to accepting anonymous requests. The rest of the route registration merely defines how the settings are served; the critical defense is the callback that decides whether the caller is allowed to invoke the route. The engineer added the object callback to replace the insecure always-true stub with WordPress's proper REST permission machinery.

## Hardening Checklist

- When registering REST routes with `register_rest_route()`, never use `'permission_callback' => '__return_true'` for sensitive data.
- Enforce admin-level access with `current_user_can('manage_options')` or an equivalent capability inside your permission callback.
- Restrict settings endpoints to authenticated users only; use `rest_authentication_errors` for global REST auth hardening if needed.
- Keep endpoints that return configuration separate from public API routes and validate that only expected user roles can call them.
- Audit any REST route exposing plugin or site settings for authorization and avoid exposing secrets through public JSON endpoints.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-14574

CVE CVE-2025-14574

PRODUCT Folder Analysis

AFFECTED ≤ cache/wedocs_2.1.15

FIXED IN cache/wedocs_2.1.16

STATUS Generated

Security writeup · CVE-2025-14574

Source files · 1

includes/API/SettingsApi.php Linked

↗ NVD