Zip Attachments <= 1.6 — Missing Authorization to Limited File Deletion (CVE-2025-11692)

Author: Hong Kong Security Expert — Date: 2025-10-15 — Tags: WordPress, vulnerability, access control

On 15 October 2025 a vulnerability affecting the WordPress plugin “Zip Attachments” (versions ≤ 1.6) was published as CVE-2025-11692. The issue is a broken access control problem: an endpoint or action that deletes plugin-managed files lacks proper authorization, enabling unauthenticated requests to trigger deletions. This advisory explains the technical details, realistic impact, detection steps and practical mitigations from a Hong Kong security research perspective. No exploit code or attack payloads are provided.

Executive summary (TL;DR)

• CVE: CVE-2025-11692
• Affected plugin: Zip Attachments (≤ 1.6)
• Vulnerability class: Broken Access Control (missing authorization)
• Privilege required: Unauthenticated
• CVSS: 5.3 (Medium / Low depending on context)
• Impact: Limited file deletion — plugin-managed temporary zip files or archives. Potential denial-of-service for features and data loss if backups are not present.
• Official vendor fix status: N/A at time of writing
• Immediate mitigations: deactivate plugin, virtual patch endpoints via WAF rules, tighten filesystem permissions, monitor logs, restore from backups where needed.

What exactly is the vulnerability?

High level: the plugin exposes functionality that deletes files but fails to enforce an appropriate authorization check. An unauthenticated actor can invoke this functionality and request deletion of files the plugin is willing to delete.

Key points:

• The functionality is intended for cleaning temporary or plugin-generated zip files after operations complete.
• No proper nonce or capability verification is performed server-side in the deletion handler.
• The deletion scope appears limited to plugin-managed files and directories, but insufficient path validation can widen the impact.

Why this matters (practical impact)

While not an immediate remote code execution, the issue is meaningful for several reasons:

1. Data loss: deletion of plugin-generated archives or temporary assets may be permanent without backups.
2. Service disruption: features relying on ZIP generation can break, affecting users and workflows.
3. Chaining risk: in environments with improper filesystem permissions or other vulnerabilities, deletion could aid further exploitation.
4. Automation: unauthenticated triggers make large-scale scanning and automated abuse trivial.
5. Public disclosure risk: availability of exploit details narrows time to mass exploitation.

Typical attack surface and likely endpoints

Deletion handlers in plugins are often reachable via:

• admin-ajax.php action endpoints
• custom REST API routes
• direct GET/POST endpoints in plugin files

Common request patterns to watch in logs:

• /wp-admin/admin-ajax.php?action=zip_attachments_delete&file=<file>
• /wp-json/zip-attachments/v1/delete?file=<file>
• /wp-content/plugins/zip-attachments/handlers.php with a delete parameter

How an attacker might (safely described) exploit this

We will not provide exploit code. The likely steps an attacker would take:

1. Discover sites running the vulnerable plugin via scanning.
2. Probe suspected deletion endpoints and observe responses.
3. Identify parameters specifying files or IDs.
4. Send deletion requests for plugin-managed files.
5. Automate across multiple targets.

Detection — what to look for in logs and monitoring

Check these indicators:

• Access logs: requests to admin-ajax.php or plugin files with “action”, “delete” or “file” parameters; repeated calls from same IPs.
• Plugin logs: deletion calls logged with no authenticated user context.
• Filesystem checks: missing expected ZIP files in upload or plugin temp directories.
• Security tooling: IDS/WAF alerts for suspicious admin-ajax or REST deletion requests.

Immediate mitigations you can apply right now

Apply layered mitigations while awaiting a vendor patch or validated fix:

1. Deactivate the plugin — the fastest and safest immediate step if the plugin is not critical.
2. Harden filesystem permissions — restrict the web server user to necessary upload/cache directories and avoid broad delete permissions.
3. Virtual patching via WAF — create rules to block requests matching deletion endpoints and parameters coming from unauthenticated contexts.
4. Webserver-level controls — use .htaccess or Nginx rules to restrict direct access to plugin handler files; consider IP whitelisting for admin-only operations.
5. Monitor and restore — check plugin-managed directories for missing files and restore from backups where required.
6. Contact hosting support — for deeper logs and forensic assistance if active exploitation is suspected.

Virtual patching: how a WAF can protect you immediately

A WAF can provide rapid virtual patching by blocking exploitation patterns at the edge. Recommended defensive approaches:

• Block requests invoking known deletion actions unless authenticated (presence of admin cookie or valid nonce).
• Rate-limit admin-ajax.php and plugin endpoints to reduce automated abuse.
• Apply nonce and referer heuristics: challenge or block requests that attempt destructive actions without expected headers or cookies.
• Log full headers and request bodies for any blocked attempts to support incident response.

Conceptual mod_security-style rule (example only — test before deploying):

# Block unauthenticated attempts to call plugin deletion action
SecRule REQUEST_URI "@rx /wp-admin/admin-ajax.php" "id:1005001,phase:1,deny,log,msg:'Block potential Zip Attachments unauthenticated delete action',chain"
  SecRule ARGS:action "@rx (?i:zip.*delete|zip_attachments_delete|zip-delete)" "t:none"
  SecRule &REQUEST_COOKIES:wordpress_logged_in@gt 0 "nolog,skipAfter:END_RULE_1005001"
END_RULE_1005001

Adjust patterns to match the plugin’s actual parameter names. Combine rule sets and rate-limiting to reduce false negatives.

Developer guidance — how the plugin should be patched

Recommended fixes for plugin authors:

1. Enforce capability checks — require appropriate capability (e.g., manage_options or upload_files).
2. Use nonces for state-changing actions — create and verify nonces server-side (e.g., check_admin_referer() or wp_verify_nonce()).
3. Validate and canonicalize file paths — restrict deletions to an explicit allowed directory; use realpath() and ensure the result is under the allowed root. Reject traversal attempts.
4. Delete by ID, not by path — map file IDs in the database to canonical paths and validate before deletion.
5. Rate-limit destructive operations — server-side counters to slow or block automated deletion attempts.
6. Comprehensive logging — log user ID (when available), IP, user-agent, timestamp and file path for each deletion action.
7. Unit and integration tests — add tests to ensure only authorized roles can trigger deletion code paths.

Simple conceptual server-side check:

// Early in delete handler
if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
    wp_send_json_error( array( 'message' => 'Unauthorized' ), 403 );
}
check_admin_referer( 'zip_attachments_delete_action', '_zip_nonce' );

// Map ID to canonical path in DB, then validate realpath() is inside allowed dir...

Incident response checklist if you were affected

1. Deactivate the vulnerable plugin immediately.
2. Inspect plugin-managed directories for missing files.
3. Restore deleted files from backups if available.
4. Collect logs: webserver access logs, plugin logs, WAF/IDS logs — record timestamps, IPs and user-agents.
5. Rotate administrative credentials as a precaution.
6. If evidence of broader compromise exists (unauthorised admin changes, web shell files, unexpected outbound connections), engage professional incident response or your hosting provider for deeper analysis.
7. Apply long-term fixes: update plugin when a vendor patch is available, or implement safe code changes in a controlled environment.

Why this is classified as “Low/Medium” severity (context matters)

The CVSS 5.3 reflects that:

• Attack is unauthenticated (raises severity); and
• Impact is limited to plugin-managed file deletion rather than arbitrary filesystem access or RCE (reduces severity).

Sites that depend on the plugin-generated files as unique copies (no backups) may experience effectively high impact. Assess severity based on your environment and recovery capability.

Practical detection queries (examples)

Server-side checks to run:

# Search access logs for admin-ajax deletion attempts
grep -i "admin-ajax.php" access.log | grep -i "action=zip" | less

# Look for REST deletions
grep -i "wp-json/zip-attachments" access.log

# Identify repeated calls from same IP
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head

# Find recently modified/removed files in plugin storage
find /path/to/wp-content/uploads/zip-attachments -type f -mtime -7 -ls

Longer-term hardening recommendations

• Maintain tested backups and restore procedures.
• Protect admin endpoints and admin-ajax.php with layered controls (rate-limiting, request filtering, authentication).
• Enforce least privilege on upload and plugin directories.
• Monitor security advisories for plugins you run and apply updates promptly.
• Consider staging plugin upgrades and vulnerability tests before deploying to production.

FAQs

Q: Does this vulnerability allow deletion of any file on my server?
A: Not typically. The deletion is usually scoped to plugin-managed directories. However, poorly implemented path validation or overly permissive filesystem permissions could widen the impact.

Q: Should I uninstall the plugin?
A: If the plugin is non-essential, deactivation and removal until a validated patch is available is the safest option. If you must keep it, apply the mitigations above and monitor closely.

Q: Is virtual patching safe?
A: Virtual patching (via WAF) is a valid stop-gap when properly tested for false positives. It reduces exposure while you implement a proper server-side fix.

Final words — Hong Kong security perspective

Broken access control remains a frequent source of issues in WordPress plugins, often caused by absent nonce checks or improper capability verification. Although CVE-2025-11692 does not appear to permit remote code execution, unauthorized deletion of plugin-managed files is disruptive and can contribute to larger incident chains.

If you run the vulnerable plugin: treat the issue seriously, prioritise containment (deactivation, permission hardening, request filtering), ensure backups are available and monitored, and apply a vendor or developer patch as soon as one is validated. If you need help analysing logs or hardening your environment, consider engaging a qualified security professional.

References: CVE-2025-11692 public record and vendor advisories where available. This advisory is intended for defensive purposes and does not include exploit code.