ANALYSIS · 9f4b490d · PATCHDIFF

Folder Analysisnelio-content_4.5.0 → nelio-content_4.5.1✓ COMPLETED

Started2026-10-07 00:22:36Z Finished2026-10-07 00:23:10Z Elapsed34s

Vulnerabilities 7

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

CVE-2026-94505

FILTERS 0

STATUS

JUDGE

CVE MATCH

EXTENSION · 1

CWE · 4

OPTIONS

Hide “No vulnerability” Hide unjudged

1/7

All 7 CVE 1 Vuln files 4

SORT

includes/post-types/reusable-messages/class-nelio-content-reusable-message-rest-controller.php

AI: 4 vulnerabilities

CWE-639: Authorization Bypass Through User-Controlled KeyNelio_Content_Reusable_Message_REST_Controller::register_routesNelio_Content_Reusable_Message_REST_Controller::can_current_user_update_reusable_message_from_request+6 MORE CVE-2026-94505 4 TP

#002

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-94505

Security writeup for CVE-2026-94505

✓ 1 FILE

## The Exploit

An authenticated WordPress user with contributor-level access can permanently delete any reusable social message, including those authored by administrators, by sending a DELETE request to the REST API endpoint without ownership or capability verification.

```http
DELETE /wp-json/nelia-content/v1/reusable-messages/42 HTTP/1.1
Host: target.local
Authorization: Bearer <contributor_token>
Cookie: wordpress_logged_in=<contributor_session>
Content-Type: application/json
```

The server responds with HTTP 200 and the message is permanently deleted from the database. An attacker with contributor credentials observes the message disappears from the editorial calendar UI immediately, and subsequent requests to fetch that message ID return 404. No audit log or capability error is raised; the deletion appears legitimate.

## What the Patch Did

**Before:**
```php
'permission_callback' => 'nelio_content_can_current_user_use_plugin',
```

**After:**
```php
'permission_callback' => array( $this, 'can_current_user_delete_reusable_message_from_request' ),
```

And within the endpoint handler:

**Before:**
```php
public function remove_reusable_message( $request ) {
	$message = $request->get_param( 'message' );
	assert( $message instanceof Nelio_Content_Reusable_Message );
	$message->delete();
	return new WP_REST_Response( array( 'deleted' => true ), 200 );
}
```

**After:**
```php
public function remove_reusable_message( $request ) {
	$message = $request->get_param( 'message' );
	assert( $message instanceof Nelio_Content_Reusable_Message );
	if ( ! empty( $message->ID ) && ! $this->can_current_user_delete_reusable_message( $message->ID ) ) {
		return new WP_Error(
			'rest_forbidden',
			_x( 'You are not allowed to delete this message.', 'text', 'nelio-content' ),
			array( 'status' => 403 )
		);
	}
	$message->delete();
	return new WP_REST_Response( array( 'deleted' => true ), 200 );
}
```

The patch replaced a generic plugin-access check (`nelio_content_can_current_user_use_plugin`) with a granular, message-aware authorization function (`can_current_user_delete_reusable_message_from_request`) that verifies both the route-level permission callback *and* a second guard inside the handler itself. The handler now invokes `can_current_user_delete_reusable_message()` to validate that the requesting user either owns the message, is a plugin manager, or holds the `delete_post` capability scoped to that post ID.

## Root Cause

**CWE-639: Authorization Bypass Through User-Controlled Key** — The `DELETE /wp-json/nelia-content/v1/reusable-messages/{id}` endpoint accepted a `message` request parameter containing a `Nelio_Content_Reusable_Message` object. The route's permission callback only checked whether the current user had general plugin access via `nelio_content_can_current_user_use_plugin()`, which returns true for any authenticated user with contributor role or above. This callback did not examine the specific message being deleted — only the user's global permissions. The handler then unconditionally called `$message->delete()` without re-validating that the user owned the message or held explicit delete authority over that post. An attacker could craft a DELETE request targeting any message ID in the database; as long as they were authenticated with a contributor account, the permission callback would pass and the deletion would succeed.

## Why It Works

The load-bearing line is the authorization check inside `remove_reusable_message()`:

```php
if ( ! empty( $message->ID ) && ! $this->can_current_user_delete_reusable_message( $message->ID ) ) {
```

Without this, the old code reaches `$message->delete()` unchecked. The permission callback alone is insufficient because REST permission callbacks execute *before* the handler sees the request body or route parameters — they cannot evaluate the specific post ID being deleted. The callback upgrade to `can_current_user_delete_reusable_message_from_request()` acts as a secondary gate at the route level, but the real gatekeeper is the check *inside* the handler, which has access to the hydrated `Nelio_Content_Reusable_Message` object and can call `can_current_user_delete_reusable_message( $message->ID )` with the actual post ID. If the engineer had removed only the route callback change and left the handler unguarded, the vulnerability would persist; if they had added only the route callback without the handler check, a bypass might still be possible if the callback failed to fully validate the message ID parameter. Defence-in-depth: the callback validates early; the handler validates late with full context.

## Hardening Checklist

- **Separate route callbacks from handler logic.** Do not assume a route-level permission callback (`permission_callback` in REST registration) can evaluate request-specific resources like post IDs. Always re-validate inside the handler using `get_post( $id )` or `$post->ID` and call `current_user_can( 'delete_post', $id )` with the post as a second argument to scope the capability check.

- **Use `current_user_can()` with resource IDs.** Never call `current_user_can( 'manage_options' )` or `current_user_can( 'delete_post' )` without passing the post ID as a second parameter. WordPress capability checks that omit the resource ID may return true for users who should not have access to that specific post.

- **Audit all REST endpoints that mutate state.** Search for `register_rest_route()` calls with `'methods' => 'POST|PUT|DELETE'` and verify that each endpoint callback contains an explicit capability or ownership check that references the resource ID from the request, not just the global user role.

- **Log authorization failures.** Wrap capability denials in `error_log()` or a dedicated audit table so privilege-escalation attempts are visible to site administrators monitoring the error log or audit trail.

- **Test with contributor-level roles.** Reproduce all CRUD operations as a contributor, subscriber, and unauthenticated user; verify that delete and edit operations return 403 when the user does not own the resource or hold an admin role.

## References

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

CVE CVE-2026-94505

PRODUCT Folder Analysis

AFFECTED ≤ nelio-content_4.5.0

FIXED IN nelio-content_4.5.1

STATUS Generated

Security writeup · CVE-2026-94505

Source files · 1

includes/post-types/reusable-messages/class-nelio-content-reusable-message-rest-controller.php Linked

↗ NVD