CVE-2026-15248: Meta Box Contributor+ Arbitrary Attachment Deletion

CVE-2026-15248: Meta Box Contributor+ Arbitrary Attachment Deletion

Overview

Meta Box versions before 5.13.1 contain a missing-authorization vulnerability in the file-field attachment deletion workflow.

An authenticated user with Contributor-level access or higher can submit identifiers for an attachment and object they do not control. The vulnerable workflow processes the deletion without confirming that the current user is authorized to manage either the supplied object or the referenced attachment.

The issue is tracked as CVE-2026-15248 and WPVDB ID a101136d-606f-4529-ae78-a4fff7724e2c.

Summary

The affected AJAX workflow accepts attacker-controlled object_id and attachment_id values. A valid nonce can be obtained from a file field rendered for an object the attacker is permitted to access, but that nonce is not bound to the target object or attachment.

As a result, a lower-privileged authenticated user can reuse a valid field nonce while replacing the object and attachment identifiers with values belonging to another user.

Affected Versions

• Affected: Meta Box versions before 5.13.1, including 5.12.1
• Fixed: Meta Box 5.13.1
• Required access: Contributor or higher
• Vulnerability class: Missing Authorization / IDOR
• CWE: CWE-862 — Missing Authorization
• CVSS: 5.5 (Medium)

Expected Behavior

A user should only be able to delete attachments associated with objects they are authorized to manage.

The deletion workflow should verify both:

1. that the current user may modify the supplied object; and
2. that the current user may delete the supplied attachment.

Actual Behavior

The vulnerable workflow verifies the request nonce but does not enforce authorization over the supplied object_id and attachment_id before deleting the referenced attachment.

A nonce obtained from an attacker-controlled object can therefore be reused in a request that targets a foreign object and foreign attachment.

Vulnerability Chain

1. A lower-privileged authenticated user accesses an object containing a Meta Box file field.
2. The workflow provides a valid field-level deletion nonce.
3. The request includes attacker-selected object and attachment identifiers.
4. The server processes the referenced attachment without validating object-level or attachment-level authorization.
5. The foreign attachment record is deleted.

Required Conditions / Attack Preconditions

The following conditions are relevant:

• Meta Box is running a vulnerable version.
• A file field is available to the attacker role.
• The field is configured so that attachment deletion is performed by the affected workflow.
• The attacker can obtain a valid nonce from an object they are permitted to access.
• The attacker knows or can otherwise supply the identifier of a target attachment.

The public advisory classifies the required role as Contributor or higher. The original runtime validation used an Author account.

Trust-Boundary Analysis

The nonce establishes that the request originated from a rendered Meta Box file field. It does not establish that the requester is authorized to act on every object or attachment identifier supplied with that request.

The security boundary is therefore not the possession of the nonce alone. The application must separately authorize the requested state change against the specific target object and attachment.

The vulnerable implementation treats a valid field nonce as sufficient authority for attacker-selected identifiers, allowing authorization from one object context to be incorrectly reused against another user’s object.

Impact

Successful exploitation can permanently remove media attachments belonging to other users.

Because WordPress attachment records may be referenced by multiple content workflows, deletion can also affect:

• featured images;
• gallery items;
• downloadable document links;
• file fields on victim-controlled posts; and
• Media Library management surfaces.

In runtime testing, native WordPress denied the same attachment deletion attempt for the attacker account, while the Meta Box workflow accepted it. This demonstrates an authorization bypass specific to the plugin workflow.

Technical Validation

The issue was validated in an isolated WordPress environment using:

• WordPress 7.0
• Meta Box 5.12.1
• PHP 8.1.22
• MariaDB 11.8.6

The tested configuration used a Meta Box file field attached to posts with forced attachment deletion enabled.

An attacker-controlled Author account obtained a valid field nonce from its own post and then supplied identifiers belonging to a second author’s post and attachment. Native WordPress rejected direct deletion of the attachment with an authorization error, while the affected Meta Box deletion workflow returned success and removed the foreign attachment record.

Remediation

Update Meta Box to version 5.13.1 or later.

Administrators should also review sites running vulnerable versions for unexpected attachment deletion or unexplained loss of featured images, gallery items, and file-field records.

Secure Design Recommendations

Attachment deletion handlers should:

1. validate the request nonce;
2. verify that the current user can edit the supplied object;
3. verify that the current user can delete the supplied attachment;
4. confirm that the attachment is associated with the expected field and object context; and
5. reject requests where ownership or capability checks fail.

A nonce should be treated as CSRF protection, not as a substitute for authorization.

Disclosure Timeline

• 2026-07-20: Vulnerability publicly listed by WPScan/WPVDB
• 2026-07-20: CVE-2026-15248 assigned and public references added

Research Credit

• Original researcher: Duy Tran
• WPScan submitter: Duy
• Verification status: Verified

References

• CVE-2026-15248 — CVE.org
• WPScan / WPVDB advisory
• Meta Box plugin page
• Meta Box file field documentation
• Meta Box file advanced documentation
• Meta Box image advanced documentation
• Affected file-field implementation
• Affected client-side file workflow

Responsible Disclosure Notice

This research was conducted in an isolated environment against software the researcher was authorized to test. No proof-of-concept payload or step-by-step reproduction instructions are published in this write-up.