ANALYSIS · 9b697fa3 · PATCHDIFF

Folder Analysisdokan-lite_4.3.1 → dokan-lite_4.3.2✓ COMPLETED

Started2026-08-05 16:30:20Z Finished2026-08-05 16:31:32Z Elapsed1m 11s

Vulnerabilities 4

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

CVE-2026-3504

FILTERS 0

STATUS

JUDGE

CVE MATCH

EXTENSION · 1

CWE · 0

OPTIONS

Hide “No vulnerability” Hide unjudged

3/5

All 5 CVE 3 Vuln files 3

SORT

dokan.php

Not sure

FUNCTIONS · SOURCE GONE CVE-2026-3504 1 TP

#003

includes/REST/StoreController.php

AI: 1 vulnerabilities

FUNCTIONS · SOURCE GONE CVE-2026-3504 1 TP

#004

templates/whats-new.php

AI: 1 vulnerabilities

FUNCTIONS · SOURCE GONE CVE-2026-3504 1 TP

#005

1–3 of 3

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-3504

Security writeup for CVE-2026-3504

✓ 3 FILES

## The Exploit

No authentication is required. The Pro version of Dokan must be active, and store reviews must be enabled.

```bash
curl -s 'https://example.com/wp-json/dokan/v1/stores/1/reviews' | jq '.reviews[] | {id: .id, name: .reviewer.name, email: .reviewer.email, username: .reviewer.username, user_id: .reviewer.user_id}'
```

The response will include `reviewer.email` (the reviewer's email address), `reviewer.username` (their WordPress username), and `reviewer.user_id` (their numeric user ID) for every review on the store. An attacker can iterate through numeric store IDs (`/stores/{id}/reviews`) to harvest email addresses and usernames across all vendors.

## What the Patch Did

**Before** (in `includes/REST/StoreController.php`, lines 831-856):

```php
'name'   => $user->user_login,
'email'  => $user->user_email,
```
and
```php
'name'   => $item->comment_author,
'email'  => $item->comment_author_email,
```

**After** (same file):

```php
'name'   => $user->display_name,
```
and
```php
'name'   => $item->comment_author,
```

The patch removes the `email` field from the API response entirely and replaces the `user_login` field with `display_name`. No capability check or additional permission gate was added — the vulnerability was purely an over-disclosure of data that exists in the response object. The developer chose to prune the response content rather than gate access to the endpoint.

## Root Cause

**CWE-200: Exposure of Sensitive Information to an Unauthorized Actor**. The dataflow begins at the REST API endpoint `/dokan/v1/stores/{id}/reviews`, which is registered by the Dokan plugin with no authentication requirement. When an unauthenticated request arrives, the `prepare_reviews_for_response` method (called from the `get_items` method of `StoreController`) builds a response array for each review. For reviews authored by registered WordPress users, it populates `reviewer.email` with `$user->user_email` and `reviewer.username` with `$user->user_login`. For anonymous reviews (those left by unregistered users), it populates `reviewer.email` with the raw `$item->comment_author_email` from the database. The trust boundary is crossed when this internal user data — available only to the WordPress user database — is serialized into a REST API response accessible to any HTTP client without a valid nonce or authentication cookie.

## Why It Works

The single load-bearing line removed from the patch is:

```
'email'  => $user->user_email,
```

If an attacker were to simply undo that one deletion in the patched code, the full vulnerability would be restored — the API would again expose reviewer email addresses and usernames. The other changes (`$user->display_name` instead of `$user->user_login`, and the removal of `$item->comment_author_email` for anonymous reviews) are complementary but not individually decisive: keeping `user_login` would still expose a username, but the most damaging data — the email address — was the primary target. The engineer likely removed `user_login` and `comment_author_email` as defence-in-depth to prevent any secondary information leakage (e.g., email confirmation phishes or username enumeration for brute-force attacks), but the email field alone is the critical vector.

## Hardening Checklist

- **Audit all REST API response schemas for `user_email`, `comment_author_email`, or any `user_login` fields** that are not explicitly needed by the frontend. Use `rest_prepare_{post_type}` or `rest_prepare_comment` filters to strip sensitive fields before the response is sent.
- **Implement a capability check on every endpoint that returns user data**, even if the frontend appears to require Pro features. Use `current_user_can('read')` or a custom capability like `dokan_view_store_reviews` to gate access.
- **Add a `__return_false` on `rest_authentication_errors` for unauthenticated requests** if you must keep the endpoint public, then explicitly check for `is_user_logged_in()` inside the endpoint handler before returning sensitive fields. Do not rely on the permission callback alone — check each field at serialization time.
- **Replace `user_login` with `display_name` in all REST API responses** unless the username is required for a specific feature (e.g., mentioning a user in a notification). The display name cannot be used for brute-force login attempts.
- **Add `rest_prepare_dokan_store_review` filter documentation** so future maintainers understand which fields are intentionally public and which are internal. Use `register_rest_field()` or `rest_register_field()` with an explicit `get_callback` that performs a permission check.

## References

- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-3504
- Wordfence Threat Intelligence: https://www.wordfence.com/threat-intel/vulnerabilities/id/cve-2026-3504
- Vendor changelog (not publicly confirmed; see patch evidence in `templates/whats-new.php`)

CVE CVE-2026-3504

PRODUCT Folder Analysis

AFFECTED ≤ dokan-lite_4.3.1

FIXED IN dokan-lite_4.3.2

STATUS Generated

Security writeup · CVE-2026-3504

Source files · 3

dokan.php Linked

includes/REST/StoreController.php Linked

templates/whats-new.php Linked

↗ NVD