Executive summary

On 13 Feb 2026 a vulnerability in the WordPress plugin “Media Library Folders” (versions ≤ 8.3.6) was disclosed and assigned CVE-2026-2312. The issue is an insecure direct object reference (IDOR) that allows authenticated users with Author-level privileges (or higher) to delete or rename arbitrary attachments across a site. The plugin author has released version 8.3.7 to address the issue.

The CVSS 3.1 score is 4.3 (Low), but the real-world impact can be significant: deleted images, broken pages, lost downloadable assets and reputational harm. If you run this plugin and you have Authors on the site, patch without delay. If you cannot patch immediately, apply temporary mitigations as described below and monitor for suspicious activity.

Why this matters (plain language)

WordPress stores uploads (images, PDFs, etc.) as attachment objects. When code that modifies or deletes attachments fails to check ownership or proper permissions, an authenticated user can manipulate an attachment identifier and perform actions against objects they shouldn’t control.

In this case, Authors were able to invoke delete/rename actions by ID without the plugin verifying ownership. That allows an Author to remove or rename assets belonging to other users. Consequences include missing media in posts/pages, broken layouts, and potential loss of critical assets if backups are insufficient.

Technical overview of the vulnerability (IDOR)

• Vulnerability type: Insecure Direct Object Reference (IDOR) / Broken Access Control
• Affected component: Media Library Folders plugin for WordPress, versions ≤ 8.3.6
• Fixed in: 8.3.7
• CVE: CVE-2026-2312
• CVSS: 3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N (score 4.3)
• Required privilege: Author (authenticated)
• Attack vector: Authenticated HTTP request to the plugin’s management endpoint
• Impact: Arbitrary deletion or rename of attachments (integrity loss of media assets)

How it works:

• The plugin exposes an action (e.g., an admin AJAX endpoint or POST handler) that accepts an attachment ID and performs delete/rename operations.
• The code does not verify that the current user owns the attachment or has site-wide permission to modify it.
• An authenticated Author can supply arbitrary attachment IDs and cause deletion or renaming of those attachments.

Note: Authors already have some upload-related privileges; this bug expands those privileges improperly to other users’ attachments.

How an attacker could exploit this (high-level, non-exploitable PoC)

Below is a conceptual flow to illustrate the risk. I do not publish working exploits—this is for defenders to understand detection signals.

1. An attacker signs in as an Author (or compromises an Author account).
2. The attacker makes authenticated requests to the plugin endpoint that handles delete/rename operations.
3. Each request includes an attachment identifier that belongs to another user or a critical site asset.
4. The plugin processes the request without confirming ownership and performs the delete/rename.
5. The attacker repeats for multiple assets to cause widespread content removal.

Because authentication is required, anonymous visitors cannot trigger this directly; however, compromised Author accounts or credential theft remain realistic attack paths.

Real-world impact scenarios

• Product images deleted on an e-commerce site, causing broken listings and lost sales.
• Marketing materials (press images, PDFs) removed, affecting reputation and campaigns.
• Blog headers and visual assets removed, producing a degraded user experience.
• Permanent loss where backups are infrequent or incomplete.

Immediate actions (step-by-step)

1. Update now: Update the Media Library Folders plugin to version 8.3.7 or later. Test in staging first for high-traffic sites, then update production.
2. If you cannot update immediately:
   • Deactivate the plugin on production until you can patch. This removes the vulnerable functionality.
   • Temporarily restrict Author privileges (see below) to limit the attack surface.
3. Use perimeter protections: Put the site behind a web application firewall (WAF) or equivalent rule engine if available. Configure rules to block suspicious POSTs against plugin endpoints.
4. Monitor logs: Examine server, application and audit logs for delete/rename requests targeting media endpoints, especially those originating from Author sessions.
5. Backups: Ensure you have current file + database backups before making further changes. Prepare to restore media assets if deletions have already occurred.

Detection guidance — what to look for

1. WordPress audit logs

   Look for attachment deletion events where the actor is an Author and the deleted items were uploaded by other users.

2. Server access logs

   Search for POST/GET requests to admin-ajax.php or plugin admin endpoints containing parameters like attachment_id, file_id, or actions with “delete” / “rename”. Correlate these with authenticated sessions.

3. Database checks

   Query wp_posts for attachments and spot sudden drops in counts or missing entries.

4. Broken pages

   Use crawlers to detect missing images (404s for files under wp-content/uploads) and monitor front-end errors.

5. File system checks

   Compare uploads directory contents with attachment records in the database to find unexpectedly removed files.

Example conceptual log pattern to search for:

POST /wp-admin/admin-ajax.php?action=mlplus_delete_attachment&id=12345 — performed by user ID 28

Recovery and incident response

If you detect unauthorized deletions, act quickly and methodically:

1. Patch the plugin to 8.3.7+ or deactivate it immediately.
2. Revoke or reset credentials for offending accounts. Rotate passwords and enforce MFA.
3. Restore deleted attachments from recent backups (files + DB). Re-associate files with WordPress attachment records if needed.
4. If backups are incomplete, search CDN caches, web archives and any external mirrors for recoverable assets.
5. Perform a root-cause analysis: how was Author-level access obtained? Review accounts, credential hygiene and authentication policies.

Important: Restoring files to the uploads directory alone may not recreate associated wp_posts attachment records. Re-import or re-upload as necessary to restore metadata.

Temporary mitigation options (if you cannot immediately update)

Choose one or more of the following temporary measures. Each has trade-offs and should be followed by a full patch as soon as possible.

• Deactivate the plugin

  Completely removes the attack surface. Drawback: loss of folder-organization UI and related features.

• Restrict Authors

  Remove upload_files or deletion-related capabilities from Author accounts using a site-specific plugin, mu-plugin, or role editor. Alternatively, temporarily downgrade Authors to Contributors if practical.

• Disable vulnerable endpoints via server rules

  Use web server configuration (.htaccess, Nginx rules) to block access to known plugin admin endpoints from non-admin users. This can keep the plugin active while stopping abuse, but requires accurate endpoint identification.

• WAF / request filtering

  Apply rules to block suspicious POSTs to the plugin endpoints that contain delete/rename parameters unless the request is from an administrator session. This is a rapid, non-invasive mitigation if you have an effective rule engine available.

• Change file permissions (careful)

  Make wp-content/uploads temporarily read-only to prevent deletions. This breaks uploads and is disruptive—use only with full understanding of side effects.

Hardening recommendations (long-term)

• Apply the principle of least privilege: review roles and capabilities regularly and avoid unnecessary Author-level accounts.
• Enforce multi-factor authentication (MFA) for all accounts with elevated privileges.
• Limit the number of Author-level accounts and centralise publishing where possible.
• Keep plugins and WordPress core up to date on a scheduled cadence.
• Use perimeter inspection (WAF) or request-filtering where feasible to provide temporary protection while patching.
• Implement logging and alerting for admin actions; alert on large numbers of deletions or unusual patterns.
• Maintain reliable, tested backups of both files and database. Verify restores periodically.
• Perform periodic security reviews and vulnerability scanning of plugins, especially those that manage files or media.

Detection templates and queries (for administrators)

Replace table prefixes and paths as needed.

1. List recent attachments:

SELECT ID, post_title, post_date, post_author
FROM wp_posts
WHERE post_type = 'attachment'
ORDER BY post_date DESC
LIMIT 100;

2. Detect attachments deleted between timestamps:

Compare two exports of wp_posts attachment rows or use an audit log to identify missing rows. If you have auditing enabled, search for operations like delete_attachment by user accounts.

3. Web server log search (conceptual):

# Search for admin-ajax or plugin endpoint with "delete" or "rename"
grep -E "admin-ajax.php.*(delete|rename|attachment|file_id)" /var/log/apache2/access.log

4. Find a single user performing multiple delete operations (pseudocode):

SELECT user_id, COUNT(*) as deletions
FROM audit_log
WHERE action LIKE '%delete_attachment%' AND timestamp >= '2026-02-01'
GROUP BY user_id
HAVING deletions > 5;

Safe code snippet: temporarily remove Author deletion capability

Caution: This reduces Author functionality. Test in staging before deploying.

<?php
// mu-plugin: disable-author-delete.php
add_action('init', function() {
    $role = get_role('author');
    if ($role) {
        // Remove the ability to delete posts (and therefore attachments they own)
        // Reversible by removing this file or code.
        $role->remove_cap('delete_posts');
        $role->remove_cap('delete_published_posts');
    }
});

Alternative: remove upload_files capability:

$role = get_role('author');
if ($role) {
    $role->remove_cap('upload_files');
}

Both are blunt instruments and will affect editorial workflow. Use only temporarily.

After you patch: validate and harden

1. Confirm the plugin is upgraded to 8.3.7 or later.
2. Gradually re-enable any temporarily disabled functionality and monitor impact.
3. Review logs for suspicious activity after the patch to ensure there was no post-exploitation.
4. Rotate credentials for compromised/affected users and enforce MFA.
5. Run a full site integrity check (files + DB) to detect any remaining tampering.

Frequently asked questions

Q: If a site has no Authors, am I safe?

If there are no Author-level (or higher) accounts on the site, the direct attack path is mitigated. However, consider other site instances (staging, multisite) and the possibility of account changes or privilege escalation; update the plugin regardless.

Q: Will deactivating the plugin break my site?

Deactivation disables the folder-organization features. Your media files remain under wp-content/uploads, but the plugin UI and organization will be unavailable until you reactivate the patched version.

Q: Are deleted files gone forever?

Not necessarily. If you have recent backups you can restore. Otherwise check CDN caches, search engine caches, and any external storage or mirrors for recoverable copies.

How to prioritise this risk

• Sites with many Authors and heavy reliance on media should update immediately and monitor closely.
• Sites with a single admin and no lower-privileged editors are lower risk but should still patch promptly.
• E-commerce, membership and high-traffic editorial sites should prioritise mitigation, backups and log monitoring.