Urgent: DocoDoco Store Locator (≤ 1.0.1) — Authenticated (Editor+) Arbitrary File Upload Vulnerability and What You Must Do Now

Date: 15 October 2025
Author: Hong Kong Security Expert

This advisory concerns a critical issue (CVE-2025-10754) affecting DocoDoco Store Locator versions ≤ 1.0.1. The flaw permits authenticated users with Editor privileges (or higher) to upload arbitrary files to the site. The vulnerability has a CVSS of 7.2 and, at the time of publication, no vendor patch is available. Read this carefully and act immediately if this plugin is installed on your WordPress site.

Quick summary (for site administrators)

• DocoDoco Store Locator (≤ 1.0.1) contains an authenticated arbitrary file upload vulnerability requiring Editor role or above.
• An attacker with Editor access can upload PHP backdoors/webshells, leading to remote code execution, persistent presence, and data theft.
• No official patch is available yet. Immediate mitigation is necessary: remove or disable the plugin, restrict Editor upload capability, scan uploads for malicious files, rotate credentials, and apply virtual patching through your host or security appliance where possible.
• If you operate multiple sites or manage clients, prioritise the highest-risk sites first (high-traffic, multiple editors, user-generated content).

Why this is serious

Arbitrary file upload vulnerabilities are high-impact for content management systems:

• Attackers can plant PHP backdoors or webshells that allow command execution and full site compromise.
• Uploads can be disguised (double extensions, renamed files) and later executed directly or via local file inclusion flaws.
• Editor privileges often grant content creation and media manipulation, which is sufficient in practice to achieve full takeover if uploads are abused.
• Known, unpatched vulnerabilities attract automated scanning and mass exploitation. Prompt mitigation reduces exposure time significantly.

High-level exploitation flow

1. Attacker obtains Editor-level access (compromised account, credential theft, social engineering).
2. Attacker uploads a malicious file via the plugin’s upload endpoint or admin screen.
3. Insufficient validation/storage allows PHP or executable content to be stored in a web-accessible location.
4. Attacker triggers the file to execute commands, pivot or establish persistent backdoors.

Immediate steps you must take (incident response checklist)

If your site uses DocoDoco Store Locator (≤ 1.0.1), perform the following immediately:

1. Place the site in maintenance or limited mode to reduce attacker impact where possible.
2. Deactivate or remove the DocoDoco Store Locator plugin. If you cannot remove it immediately, rename the plugin folder via SFTP/SSH to prevent the plugin code from loading:

   sudo mv wp-content/plugins/docodoco-store-locator wp-content/plugins/docodoco-store-locator.disabled

3. Force password resets for all Administrators and Editors. Force password resets for any users with upload, edit or publish permissions.
4. Revoke and reissue any API keys, integration credentials, or external tokens related to the site.
5. Rotate WordPress salts and keys in wp-config.php to invalidate existing sessions.
6. Scan wp-content/uploads and other writable directories for recent or suspicious files (see Hunting and detection).
7. Audit user accounts created after the disclosure date; remove unfamiliar accounts promptly.
8. Inspect scheduled tasks (wp-cron), theme/plugin file modifications, .htaccess and wp-config.php for unauthorized changes.
9. If compromise indicators are present (webshells, unknown processes, backdoors), isolate the site and engage a professional incident responder or your host immediately.
10. If you cannot ensure a clean state, restore from a known-good backup made before the compromise.

Where possible, coordinate these steps with your hosting provider or security operations team so they can assist with network-level containment and virtual patching.

Hunting and detection: commands and checks to run now

Use the following checks to detect suspicious uploads or modifications. Adapt commands for your environment.

Search uploads for recent or suspicious files

find wp-content/uploads -type f -mtime -30 -printf '%TY-%Tm-%Td %TT %p
' | sort -r

find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.php5' -o -iname '*.php7' \) -print

grep -R --line-number --exclude-dir=cache --exclude-dir=logs '<?php' wp-content/uploads || true

find wp-content/uploads -type f -regextype posix-extended -regex '.*\.(php|phtml|php5|php7|phar|pl|py)$' -print

Check for modified core/plugin/theme files

find . -type f -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %TT %p
' | sort -r

Inspect users and options (WP-CLI recommended)

wp user list --fields=ID,user_login,user_email,roles,user_registered

wp option get active_plugins

Inspect .htaccess

tail -n 200 .htaccess

Use malware scanners to detect webshell patterns. Quarantine suspicious files and investigate their creation timestamps and uploader accounts.

Short-term mitigations you can apply now

1. Disable or remove the plugin — this is the most reliable immediate mitigation.
2. Prevent execution of PHP in the uploads directory:

   Apache (.htaccess under wp-content/uploads):

   <FilesMatch "\.(php|phtml|php5|php7|phar)$">
     Deny from all
   </FilesMatch>

   Nginx: add location rules to deny execution in uploads or ask your host to implement the change.

3. Temporarily remove the upload_files capability from the Editor role until the plugin is patched:

   wp role remove-cap editor upload_files

   Note: this reduces Editor functionality. Communicate changes to content teams.

4. Harden upload handling: limit accepted MIME types and inspect content at the upload boundary.
5. Apply virtual patching rules on your WAF or ask your host to block plugin-specific endpoints and suspicious upload patterns.
6. Monitor logs for POST requests to plugin endpoints, unexpected file uploads, or content-type mismatches.

Recommended WAF rules / signatures (conceptual)

These are high-level rule ideas for operators; test in detection mode first to avoid false positives.

• Block uploads to the plugin’s upload endpoint unless the authenticated user is an Administrator or request originates from a trusted IP set. Condition: request path matches /wp-content/plugins/docodoco-store-locator/*upload* or admin-ajax action equals plugin upload action.
• Deny multipart/form-data uploads where file part contains PHP open tags (e.g., <?php or common obfuscations).
• Reject filenames with double extensions (e.g., image.php.jpg) or executable extensions. Use a regex to match disallowed extensions.
• Enforce MIME sniffing: block when declared MIME is image/* but file header indicates text/php.
• Block suspicious user agents and repeated automated upload attempts to plugin paths.

Coordinate rule deployment with your host to avoid disruption.

Long-term developer remediations (for plugin authors)

Developer must implement code-level fixes and secure upload handling:

1. Strict capability checks: always use current_user_can() with appropriate capabilities (do not rely on role names).
2. Nonce verification: verify WordPress nonces for state-changing actions.
3. Use core upload handling: wp_handle_upload() and wp_check_filetype_and_ext() for MIME and extension checks.
4. Restrict accepted file types to the minimum required set and verify file content, not just extension.
5. Where possible, store uploads outside the web root and serve via a controlled proxy that enforces access rules.
6. Sanitise filenames (sanitize_file_name()) and prevent directory traversal.
7. Ensure server is configured to prevent execution of uploaded files in writable directories.
8. Log upload activity with user context for auditing and incident response.
9. Rate limit upload endpoints and implement anti-automation protections.
10. Add security-focused unit tests and continuous security reviews.

Post-incident cleanup: how to be sure you’re clean

1. Place the site into maintenance mode and take a full file + database backup for forensic analysis.
2. Quarantine or block public access if possible.
3. Follow the hunting checklist to identify suspicious files, unknown admin users, and modified code.
4. Replace modified core, theme and plugin files with clean copies from trusted sources or reinstall WordPress core.
5. Remove suspicious users and destroy active sessions:

   wp user session destroy <user-id>

6. Reset all admin/editor passwords and update external credentials (FTP, hosting panel, API keys).
7. Rotate WordPress salts and keys in wp-config.php.
8. Re-scan the site and uploads after cleaning.
9. Restore from a clean backup made before any compromise if necessary, then harden the restored site.
10. Monitor logs and traffic closely for recurrence.

If you are not confident in cleanup, engage a professional incident response provider or your hosting provider’s security team.

Detection and monitoring recommendations

• Enable audit logging for user actions (logins, role changes, uploads).
• Monitor filesystem changes to catch unexpected modifications in plugins, themes and uploads.
• Alert on creation of PHP files in uploads or other writable directories.
• Watch for unusual outbound connections from the webserver that may indicate command-and-control activity.
• Maintain a clean baseline and run periodic integrity checks against it.

Why virtual patching matters now

When a vulnerability is public and no official patch exists, a virtual patch (via your WAF, CDN, or host) can immediately reduce risk by blocking known attack vectors. It is a temporary measure — not a substitute for applying an upstream vendor patch when it becomes available. Test rules in detection mode before enabling blocking.

Practical hardening checklist (defense-in-depth)

1. Remove or deactivate the vulnerable plugin if it is not essential.
2. Apply virtual patching via your host, WAF or security appliance to block suspicious uploads and plugin-specific endpoints.
3. Harden the uploads directory to prevent PHP execution.
4. Remove upload capability from Editor role until the plugin is updated.
5. Force password resets for Editors and Admins and enable MFA where available.
6. Rotate salts, keys and all credentials associated with the site.
7. Enable audit logs and file integrity monitoring.
8. Ensure themes and plugins are from trusted sources and kept up to date.
9. Maintain regular, tested offsite backups.

Prioritise response based on exposure

• High exposure: user-generated content sites, many Editor accounts, or high traffic — act immediately: remove plugin, virtual patch, and scan.
• Medium exposure: few trusted editors — follow the same steps with coordination to minimise disruption.
• Low exposure: single-admin sites should still remove or mitigate the plugin; do not rely on perceived low risk.

Example: safer upload handling (developer reference)

The following is a simplified PHP pattern illustrating safer upload handling. It is for developer reference only.

// Example: safe handling pattern (simplified)
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'admin_post_my_plugin_upload', 'my_plugin_handle_upload' );

function my_plugin_handle_upload() {
    if ( ! current_user_can( 'upload_files' ) ) {
        wp_die( 'Insufficient privileges', '403' );
    }

    if ( ! isset( $_POST['my_plugin_nonce'] ) || ! wp_verify_nonce( $_POST['my_plugin_nonce'], 'my_plugin_upload' ) ) {
        wp_die( 'Invalid nonce', '403' );
    }

    if ( empty( $_FILES['file'] ) ) {
        wp_redirect( wp_get_referer() );
        exit;
    }

    $file = $_FILES['file'];

    // Allow only images in this example
    $allowed_mime_types = array( 'image/jpeg', 'image/png', 'image/gif' );
    $finfo = wp_check_filetype_and_ext( $file['tmp_name'], $file['name'] );
    if ( ! in_array( $finfo['type'], $allowed_mime_types, true ) ) {
        wp_die( 'Invalid file type', '403' );
    }

    $overrides = array( 'test_form' => false );
    $movefile = wp_handle_upload( $file, $overrides );

    if ( isset( $movefile['error'] ) ) {
        wp_die( esc_html( $movefile['error'] ), '500' );
    }

    // Optional: create attachment or custom record
    // ...
    wp_redirect( wp_get_referer() );
    exit;
}

Communication plan for teams

• Notify content teams and editors of temporary changes (upload capability removed or restricted).
• Coordinate maintenance windows for plugin removal or updates to minimise operational disruption.
• Keep stakeholders informed about remediation progress and any evidence of compromise.

Final priority recommendations

1. If you run the vulnerable plugin, remove or disable it immediately.
2. Apply virtual patching (WAF/host rules) to block upload attempts targeting the plugin endpoints.
3. Scan the uploads directory for PHP or suspicious content and remediate any findings.
4. Rotate credentials and enforce strong passwords plus multi-factor authentication for admin/editor accounts.
5. Only reintroduce Editor upload capability after removing vulnerable code and validating site integrity.

Time is critical — automated scanners and attackers will test known, unpatched vulnerabilities quickly. If you need assistance, contact a trusted incident response provider or your hosting provider’s security team for immediate support.

— Hong Kong Security Expert