Urgent: Zip Attachments (≤ 1.6) — Broken Access Control Allows Unauthenticated Disclosure of Private & Password‑Protected Attachments (CVE‑2025‑11701)

Summary — A broken access control vulnerability (CVE‑2025‑11701) affecting the “Zip Attachments” WordPress plugin (versions ≤ 1.6) allows unauthenticated retrieval of files associated with private or password‑protected posts. At the time of publication no official vendor patch is available. This post explains the issue, likely impact, detection and mitigations you can apply immediately, plus developer guidance for a permanent fix. Written in the voice of a Hong Kong security practitioner with practical, no‑nonsense advice.

What happened (plain-English overview)

On 15 October 2025 a vulnerability (CVE‑2025‑11701) was published for the WordPress plugin “Zip Attachments” affecting versions up to and including 1.6. The plugin builds and serves ZIP archives of attachments associated with posts. The vulnerable code path fails to verify whether the requester is authorised to access the files before packaging or serving them.

Consequently, an unauthenticated visitor can request attachments that should be restricted to logged‑in users or those who know a post password. With no vendor patch available at publication, site owners must act to prevent data disclosure.

Why this is serious: impact and realistic attack scenarios

Broken access control is among the most damaging vulnerability classes because it circumvents intended permissions. Practical consequences include:

• Disclosure of private attachments: internal documents, drafts, invoices or staff images can be downloaded.
• Disclosure of password‑protected attachments: attackers may retrieve files without knowing the post password.
• Data leakage: attachments often contain sensitive information (contracts, IDs, spreadsheets, client data).
• Reputation, legal and compliance risk: exposed personal data can trigger breach notifications or regulatory action in various jurisdictions, including Hong Kong.
• Targeted reconnaissance and mass harvesting: automated scans can enumerate post IDs and download attachments at scale.

Automated scanning is trivial because the vulnerability is unauthenticated; attackers can script requests to plugin endpoints and harvest files quickly.

How the vulnerability works (technical summary)

The plugin exposes an endpoint or AJAX action that builds and returns a ZIP containing attachments for a given post ID. The vulnerable handler omits robust authorization checks and trusts the incoming post identifier. Typical missing checks include:

• No verification of capabilities (for example, current_user_can(‘read_post’, $post_id)).
• No verification of post password via post_password_required() and associated token checks.
• Not checking post status (private/draft) or whether the requester is authenticated and permitted to view it.

Because the endpoint builds archives based solely on a supplied post ID, an attacker can request arbitrary IDs and receive attachments even when posts are private or password‑protected. We do not publish weaponised exploit steps here, but the logic flaw enables mass extraction once discovered.

How to detect exploitation attempts in your logs

Search access and application logs for unusual or repetitive requests to plugin endpoints or WordPress AJAX with patterns like:

• Requests to admin-ajax.php with ZIP‑related actions, e.g. admin-ajax.php.*action=.*zip.*attach|zip_attachments.
• Requests containing “zip” or “attachments” with post IDs, e.g. /?zip_attachments=1&post=123 or /wp-admin/admin-ajax.php?action=zip_attachments&post=123.
• Requests to /wp-content/plugins/zip-attachments/ or similar plugin paths.
• Multiple requests for sequential or varied post IDs from the same IP or range (enumeration behaviour).
• Requests returning 200 with binary ZIP content where the requester is not authenticated.
• Traffic spikes on endpoints used for ZIP generation.

If you find matching activity, treat it as a potential data disclosure and follow the incident response checklist below.

Immediate mitigations (what site owners should do now)

If your site runs Zip Attachments ≤ 1.6, do not wait for a vendor update. Prioritise actions below based on impact and operational constraints.

Priority 1 — Quick, high‑impact protections

1. Deactivate the plugin immediately if you can tolerate losing the ZIP feature. This fully removes the exposed code path.
2. If deactivation is impossible, block access at the web server or proxy level so unauthenticated requests cannot reach the plugin endpoints (sample rules below).
3. Use a Web Application Firewall (WAF) or ask your hosting provider to apply blocking rules that deny unauthenticated access to ZIP endpoints.

Priority 2 — Hardening and detection

1. Enable/expand logging and set alerts for the detection patterns described above.
2. Rate‑limit suspicious endpoints to slow enumeration and automated harvesters.
3. Search historical logs for prior access to ZIP endpoints and review recently downloaded attachments for sensitive content.

Priority 3 — Longer term

1. Replace the plugin with a secure alternative or apply a patched version when available.
2. Where a vendor fix is not forthcoming, add server‑level or application‑level checks to enforce authorization (developer guidance below).

Virtual patching via WAF / hosting provider

Virtual patching (blocking attacks at the HTTP layer) is an effective short‑term control while you test and deploy a permanent fix. If you use a hosted WAF or your hosting provider offers rule management, ask them to block the patterns below. If you self‑manage, you can implement the sample rules directly.

What a virtual patch should do:

• Block requests matching vulnerable endpoint patterns (e.g. admin-ajax.php with ZIP actions or direct plugin file access).
• Deny requests to those endpoints unless a valid authenticated session cookie is present.
• Rate‑limit and log matching requests to detect scanning activity.

Conceptual rule logic:

IF request URI matches ^/wp-admin/admin-ajax.php$
AND query string contains action=zip_attachments (or similar)
AND request does NOT include wordpress_logged_in_ cookie
THEN block with HTTP 403 and log

Example Nginx snippet (place in your site config):

location = /wp-admin/admin-ajax.php {
    if ($arg_action ~* "(zip_attachments|zip_attach|zipDownload)") {
        if ($http_cookie !~* "wordpress_logged_in_") {
            return 403;
        }
    }
    # existing PHP handling here
}

Example Apache (mod_rewrite) conceptual snippet:

RewriteCond %{REQUEST_URI} ^/wp-admin/admin-ajax.php$
RewriteCond %{QUERY_STRING} action=(zip_attachments|zip_attach|zipDownload) [NC]
RewriteCond %{HTTP:Cookie} !wordpress_logged_in_ [NC]
RewriteRule .* - [F]

Example ModSecurity-style rule (illustrative — adapt to your engine):

SecRule REQUEST_URI "@rx /wp-admin/admin-ajax.php" "phase:1,chain,deny,log,msg:'Block Zip Attachments unauthenticated access',id:1000010"
  SecRule ARGS_NAMES|ARGS|REQUEST_HEADERS:Cookie "@contains zip_attachments|zip_attach" "chain"
  SecRule REQUEST_HEADERS:Cookie "!@rx wordpress_logged_in_" "t:none"

Important: test rules in “simulate” mode first to avoid blocking legitimate users. If you are unsure, ask your hosting or security provider to apply and validate rules.

Temporary hardening: sample WordPress mu-plugin to block unauthenticated ZIP requests

If you cannot deactivate the plugin and cannot immediately apply WAF rules, a small must‑use plugin (mu-plugin) can block likely attack vectors at PHP level. This is a short‑term mitigation — implement only until a proper patch is applied.

<?php
/*
Plugin Name: Block Unauthenticated Zip Attachments Access
Description: Temporary mitigation - deny unauthenticated access to zip attachment endpoints.
Version: 1.0
Author: Hong Kong Security Expert
*/

add_action('init', function() {
    // Protect admin-ajax.php based requests early
    if (defined('DOING_AJAX') && DOING_AJAX) {
        $action = isset($_REQUEST['action']) ? sanitize_text_field($_REQUEST['action']) : '';
        $suspicious_actions = array('zip_attachments', 'zip_attach', 'zipDownload'); // adapt names as needed
        if (in_array($action, $suspicious_actions, true)) {
            if (!is_user_logged_in()) {
                // Log attempt for investigation
                error_log(sprintf(
                    '[hk-sec] Blocked unauthenticated zip action="%s" from %s, UA="%s"',
                    $action,
                    $_SERVER['REMOTE_ADDR'] ?? 'unknown',
                    $_SERVER['HTTP_USER_AGENT'] ?? 'unknown'
                ));
                wp_die('Forbidden', 'Forbidden', 403);
                exit;
            }
        }
    }

    // Protect direct plugin endpoints if present
    $request_uri = $_SERVER['REQUEST_URI'] ?? '';
    if (strpos($request_uri, '/wp-content/plugins/zip-attachments/') !== false) {
        if (!is_user_logged_in()) {
            status_header(403);
            exit;
        }
    }
});

Notes:

• This mu-plugin denies unauthenticated requests to likely plugin endpoints and logs the events. It is intentionally conservative.
• Adjust $suspicious_actions based on the plugin’s real action names if known.
• Remove this mu-plugin when you have a verified, permanent fix in place.

Developer guidance: how plugin authors should fix this

Plugin maintainers should prioritise a proper patch that enforces authorization checks in the ZIP generation and serving paths. Recommended measures:

1. Strong authorization checks

• Before packaging attachments, verify the requester can view the post and its attachments. Use capability checks such as current_user_can('read_post', $post_id) where available.
• For private posts, verify the requester has the appropriate capability or is the post author.
• For password‑protected posts, require and validate the post password/token via WordPress native mechanisms.
• Deny requests unless checks pass; avoid relying on obscurity of endpoints.

2. Respect post_password_required()

If a post requires a password, ensure the password is provided and correctly validated before serving attachments.

3. Nonce protection for AJAX

Require and verify nonces (using wp_verify_nonce()) for AJAX actions that originate from authenticated UI to protect against CSRF and misuse.

4. Avoid exposing raw file paths

Do not return direct file system paths or unauthorised URLs. Stream files only after authorization and consider signed, short‑lived URLs if external storage is used.

5. Rate limiting & logging

Implement server‑side rate limiting for ZIP generation to prevent enumeration and log attempts with IP and user/token context.

6. Add unit and integration tests

Create tests ensuring private and password‑protected posts cannot have their attachments bundled for unauthenticated callers.

Example pseudo code to run early in the handler:

$post = get_post( $post_id );
if ( ! $post ) {
    wp_send_json_error('Invalid post', 400);
}

if ( post_password_required( $post ) ) {
    // require password verification
    if ( ! isset($_REQUEST['post_password']) || ! my_verify_post_password($post, $_REQUEST['post_password']) ) {
        wp_send_json_error('Unauthorized', 403);
    }
}

if ( 'private' === $post->post_status ) {
    if ( ! is_user_logged_in() || ! current_user_can( 'read_post', $post_id ) ) {
        wp_send_json_error('Forbidden', 403);
    }
}

Hardening your WordPress site beyond this specific issue

This incident highlights the risk plugins introduce when serving user files. Recommended general controls:

• Principle of least privilege: only grant plugins the capabilities they need.
• Host sensitive attachments off the web root or behind authenticated handlers where possible.
• Use signed, time‑limited URLs for object storage instead of direct public links.
• Deploy WAF protections and keep rules updated to provide virtual patches during disclosures.
• Use must‑use plugins for critical hardening so protection is independent of third‑party plugin updates.
• Regularly review how plugins handle file downloads and whether they implement authorization checks.

Incident response checklist (if you discovered exploitation)

1. Immediately apply mitigation: deactivate plugin or block unauthenticated ZIP requests (WAF/mu-plugin/server rules).
2. Preserve logs: collect access, application, and server logs covering the relevant timeframe.
3. Identify exposed files: determine which post IDs and attachments were served.
4. Assess sensitivity: check for PHI/PII or regulated data and follow legal/regulatory obligations in your jurisdiction (including Hong Kong PDPO considerations).
5. Notify stakeholders and follow your internal disclosure process.
6. Rotate credentials or tokens that may have been exposed in attachments.
7. Apply a permanent patch or replace the plugin, then verify and test.
8. Consider a forensic review if sensitive data was exposed or if signs indicate deeper compromise.

Frequently asked questions

Q — Is this only a problem if I use private posts?

A — The issue affects attachments associated with private and password‑protected posts. If your site never uses those features, your immediate risk is lower, but many sites contain hidden drafts or internal files that could be affected.

Q — Will disabling the plugin stop the risk?

A — Yes. Deactivating the plugin removes the vulnerable code path. If you cannot deactivate it, server‑level blocks or an mu-plugin can mitigate risk until a patch is applied.

Q — Can attackers access other files on my server?

A — This flaw concerns attachments managed by WordPress and served through the plugin. It does not necessarily indicate arbitrary file access beyond attachments, but any disclosure of sensitive files should be treated seriously.

How to get professional help

If you need assistance implementing mitigations, ask your hosting provider or engage a security consultant experienced in WordPress and web application firewalls. Provide them with the detection patterns and example rules above so they can act quickly. For organisations in Hong Kong, consider local security firms with incident response expertise and an understanding of relevant regulatory obligations.

Final recommendations and next steps

1. If you run Zip Attachments ≤ 1.6: assume you are vulnerable. Deactivate the plugin or apply the mitigations described here immediately.
2. Deploy a WAF rule or server block to deny unauthenticated requests to the plugin endpoints and stop automated harvesting.
3. Review logs for evidence of data access and follow the incident response checklist if you find signs of exploitation.
4. Apply a permanent fix — either an official plugin update that implements the authorization checks described above, or replace the plugin with an alternative that properly protects protected content.
5. Implement longer‑term hardening (signed URLs, host files off the web root, mu-plugins to enforce policy).