Plugin Name	DocoDoco Store Locator
Type of Vulnerability	Authenticated file upload vulnerability
CVE Number	CVE-2025-10754
Urgency	High
CVE Publish Date	2025-10-15
Source URL	CVE-2025-10754

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

Date: 15 October 2025
Author: WP-Firewall Security Team

---

We’re writing to every WordPress site owner, agency, and developer that may be using the DocoDoco Store Locator plugin. A critical security issue (CVE-2025-10754) affecting versions ≤ 1.0.1 has been publicly disclosed: an authenticated arbitrary file upload vulnerability requiring Editor privileges. The vulnerability carries a CVSS score of 7.2 and — importantly — the vendor has not released an official fix at the time of writing.

As a WordPress Web Application Firewall vendor and security team, we want to explain the technical risk, exploitation scenarios, detection and hunting techniques, remediation options (short-term and long-term), and hardening recommendations you can implement today. We’ll also show how a WAF can protect you while a patch is prepared and why defense-in-depth is essential.

This is written in plain English by security practitioners — not marketing copy. Read it carefully and follow the immediate actions if you run this plugin.

---

Quick summary (for site administrators)

• A vulnerability in DocoDoco Store Locator (≤ 1.0.1) allows authenticated users with Editor role (or higher) to upload arbitrary files to the site.
• Attackers who gain Editor access — or who already have an Editor account — can upload webshells or backdoors and achieve remote code execution, persistent access or data theft.
• No official fix is available yet. This means site owners must mitigate now: remove the plugin if possible, restrict Editor upload capabilities, scan for malicious uploads, rotate credentials, and deploy virtual patching / WAF rules until an official update is released.
• WP-Firewall customers can enable a virtual patch (WAF rule) we provide to block suspicious upload requests targeting the vulnerable endpoints.

---

Why this is serious

Arbitrary file upload vulnerabilities are among the most dangerous issues for CMS platforms:

• They can be used to upload PHP backdoors or webshells which allow remote command execution and full site compromise.
• Uploaded files can be obfuscated (double extensions, renamed to benign-looking files) and later invoked directly or via local file inclusion bugs.
• An attacker with Editor privileges is often able to create and edit content, manipulate media and sometimes modify theme files — giving them significant attack surface.
• Automated exploit scanning and mass attacks will run against known, unpatched vulnerabilities. If your site uses the affected plugin and is not mitigated, it will likely be scanned and targeted.

Even though the required privilege is "Editor", this is frequently sufficient to cause a complete site takeover once combined with file upload abuse.

---

How the vulnerability is typically exploited (high-level)

1. Attacker obtains Editor-level access (e.g., compromised account, stolen credentials, vulnerable third-party system, or social engineering).
2. Attacker interacts with the plugin’s upload endpoint (or the plugin’s admin screen) to upload a malicious file.
3. The plugin fails to properly validate file type, content, or enforce safe storage paths — allowing PHP or other executable content to be uploaded to a web-accessible location.
4. The attacker visits the uploaded file (or triggers it indirectly) to execute commands, pivot, or drop persistent backdoors.

We will not publish exploit payloads here. Instead we focus on detection and defense.

---

Immediate steps you must take (incident response checklist)

If you run the DocoDoco Store Locator plugin (≤ 1.0.1), perform these actions immediately:

1. Put the site into maintenance/limited mode (if possible) to reduce attacker impact.
2. Temporarily deactivate or remove the DocoDoco Store Locator plugin. If removal is not possible right away, disable plugin access by renaming the plugin folder (via SFTP/SSH) to block plugin code from executing.
   Example (ssh):
   sudo mv wp-content/plugins/docodoco-store-locator wp-content/plugins/docodoco-store-locator.disabled
3. Force a password reset for all Administrators and Editors. Force password reset for all users with upload, edit or publish permissions.
4. Revoke and reissue any API keys or integration credentials that may be present on the site.
5. Rotate WordPress salts and keys in wp-config.php (this forces cookie invalidation).
6. Run a thorough scan of wp-content/uploads and other writable directories for suspicious files (see "Hunting and detection" below).
7. Check for new users created since the disclosure date and remove any unfamiliar ones.
8. Check for scheduled tasks (wp-cron) and unauthorized modifications to theme/plugin files, .htaccess, and wp-config.php.
9. If you find evidence of compromise (webshells, unknown processes, backdoors), isolate the site and engage a professional incident response service or your host immediately.
10. Restore from a known-good backup if you cannot confidently cleanse the site.

If you’re using a managed WAF or security plugin (like WP-Firewall), enable the provided virtual patching rules now while the plugin is removed or being updated.

---

Hunting and detection: commands and checks you should run now

Use these checks to quickly identify signs of malicious uploads or compromise. Adjust for your hosting environment.

Search the uploads directory for recently modified files:

• Using SSH:
  • List files modified in last 30 days:
    find wp-content/uploads -type f -mtime -30 -printf '%TY-%Tm-%Td %TT %p
' | sort -r
  • Look for PHP or suspicious file types:
    find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.php5' -o -iname '*.php7' \) -print
  • Scan for files containing PHP opening tags:
    grep -R --line-number --exclude-dir=cache --exclude-dir=logs '<?php' wp-content/uploads || true
  • Identify files with double extensions or suspicious names:
    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:

• Using git (if you have repo) or file modification timestamps:
  find . -type f -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %TT %p
' | sort -r

Search WordPress users for anomalies (WP-CLI recommended):

• List users with roles:
  wp user list --fields=ID,user_login,user_email,roles,user_registered

Check WP options for unfamiliar modifications (e.g., active_plugins):

• wp option get active_plugins

Inspect .htaccess for strange redirects or handlers:

• tail -n 200 .htaccess

If you prefer automated scanning, run a malware scanner that checks PHP files for webshell patterns and unusual code. If you find suspicious items, quarantine them and restore from a clean backup when available.

---

Short-term mitigations you can apply now

These measures reduce risk immediately while you wait for an official plugin update:

1. Disable or remove the plugin. This is the safest immediate step.
2. Prevent execution of PHP files inside uploads directory:
   • Add a .htaccess (Apache) under wp-content/uploads with:

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

   • Nginx: add location rules to deny execution in uploads; ask host to help if you don’t manage Nginx config directly.
3. Restrict Editor role file upload capability temporarily:
   • Remove the upload_files capability from Editor role until patch is available. Example using WP-CLI:
     wp role remove-cap editor upload_files
   • Note: Removing capability reduces Editor functionality; communicate with content teams.
4. Harden uploads: limit accepted MIME types and block dubious content at the WAF layer (see WAF rules below).
5. Block access to plugin-specific endpoints with the WAF: if the plugin exposes a predictable URL or admin AJAX action, create a rule to deny requests except from valid admin IPs.
6. Enable strict file inspection and scanning on any file upload functionality.
7. Monitor logs for requests that contain file upload attempts, unexpected POSTs to plugin endpoints, or content-type mismatches.

---

Recommended WAF rules / signatures (conceptual)

Below are conceptual WAF rules that a security team or WAF operator can implement. They’re intentionally high-level and avoid disclosing exploit signatures.

1. 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-specific upload action.
   • Action: Block or require CAPTCHA / additional verification.
2. Deny POST multipart/form-data where file part contains PHP open tags:
   • If multipart payload contains "<?php" (or common obfuscations), block and log.
3. Reject files whose filename contains double extensions (like image.php.jpg) or executable extensions:
   • Regex example (pseudo): filename matches /\.(php|phtml|phar|pl|py|exe|sh)$/i
4. Enforce MIME sniffing: block where MIME type doesn't match the expected extension:
   • If declared MIME is image/* but file header indicates text/php, block.
5. Block suspicious user agents / automated scanners making repeated upload attempts to plugin paths.
6. Log and block requests with unusual content-type headers (e.g., application/octet-stream posted to image endpoints).

Note: WAF rules should be tested in detection mode first to avoid false positives. For hosted sites, coordinate with host before applying aggressive rules.

---

Long-term developer remediations (what the plugin author must do)

If you are a developer or plugin maintainer, here are code-level fixes and best practices to remediate an arbitrary file upload issue:

1. Capability checks:
   • Always use current_user_can() with the correct capability (e.g., 'manage_options' for admin-only actions). Do not rely on assumptions about role names.
   • Example:

     if ( ! current_user_can( 'upload_files' ) ) {
         wp_die( 'Insufficient privileges', 'Permission Denied', array( 'response' => 403 ) );
     }

2. Nonce verification:
   • Every action that changes state or uploads must verify a WordPress nonce with wp_verify_nonce().
3. Use core upload handling:
   • Use wp_handle_upload() and wp_check_filetype_and_ext() for robust, WordPress-native file handling and MIME checks.
4. Strict file type validation:
   • Restrict accepted types to the smallest possible set (e.g., images only if only images are needed).
   • Do not rely solely on file extension; verify file content.
5. Store outside web root when possible:
   • Store uploaded files outside a publicly-executable directory and serve them through a controlled proxy that enforces whitelists.
6. Sanitize filenames:
   • Remove suspicious characters and prevent directory traversal (e.g., sanitize_file_name()).
7. Prevent execution:
   • For files stored under web root, ensure server is configured to prevent execution of PHP in those directories (via .htaccess or server config).
8. Logging and auditing:
   • Log who uploaded which file and when. This helps incident response.
9. Rate limiting and anti-automation:
   • Enforce rate limits on upload endpoints, and implement anti-bot measures for admin screens.
10. Security review and unit tests:
    • Include automated tests to assert that malicious payloads are rejected and log expectations for security regressions.

---

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

If you discovered indicators of compromise (IoCs), follow these steps in order:

1. Put the site into maintenance mode and take a full file + DB backup for forensic analysis.
2. Quarantine the site (remove network access / block public access) if possible.
3. Walk through the hunting checklist above to identify suspicious files, unknown admin accounts, 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 revoke inactive sessions: wp user session destroy <user-id> (WP-CLI).
6. Reset all admin/editor passwords and update external credentials (FTP, hosting panel, API keys).
7. Change salts and keys in wp-config.php.
8. Re-scan the site and uploads after cleaning.
9. If you used backups, ensure you restore to a backup from before the compromise and then harden the restored site.
10. Monitor logs and traffic closely for recurrence.

If you’re unsure about a proper 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, file uploads).
• Monitor file system changes (tripwire-style checks) to catch unexpected changes in plugin, theme and uploads directories.
• Watch for unusual outbound connections from the site server (possible command-and-control).
• Set up alerts for the creation of PHP files inside uploads or other writable directories.
• Periodically run content integrity checks comparing current files to a clean baseline.

---

Why virtual patching (WAF) matters now

When a vulnerability is public and no official patch exists, virtual patching via a WAF provides critical time and protection:

• It blocks the attack vectors in transit and reduces the immediate risk of compromise.
• It is deployable immediately (rules can be applied quickly to block known exploit patterns).
• It avoids needing to alter the vulnerable plugin code directly (useful when waiting for a vendor patch).

We recommend running WAF rules that specifically target upload request patterns, content-type mismatches, and plugin-specific endpoints. Keep these rules in monitoring mode first to tune for false positives, then enable blocking once tuned.

---

Practical hardening checklist (defense-in-depth)

1. Remove or deactivate the plugin if not absolutely required.
2. Apply WAF rules to block suspicious uploads and plugin-specific endpoints.
3. Harden uploads directory (deny PHP execution).
4. Remove upload capability from Editor role until plugin is updated.
5. Force-password reset for Editors and Admins.
6. Rotate salts, keys, and credentials.
7. Review audit logs and enable them if disabled.
8. Ensure themes and plugins are from trusted sources and up-to-date.
9. Maintain regular, tested backups stored offsite.
10. Consider multi-factor authentication for all admin/editor accounts.

---

Message to site owners: prioritize risk based on exposure

• High exposure: sites that allow user-generated content, frequently have Editor role accounts, or are high-traffic should act immediately: remove plugin, enable WAF rule and scan the site.
• Medium exposure: sites with only a few trusted editors should still follow the same steps but can coordinate with content teams while minimizing disruption.
• Low exposure: if you are certain there are no Editor-level accounts (e.g., single-admin site), you still must patch / remove or mitigate the plugin — don’t rely on low perceived risk.

---

Developer guidance: secure upload code example (simplified)

Below is a minimal pattern demonstrating safer upload handling. This is illustrative, not a full patch.

<?php
// 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: explain why Editor upload capability may be temporarily disabled.
• Coordinate maintenance windows if removing or updating plugins will disrupt content workflows.
• Keep stakeholders informed about remediation progress and any discovered compromises.

---

Stronger Protection Starts with a Free Layer of Defense

If you want immediate, hands-off protection while you perform the technical remediation steps above, consider signing up for our WP-Firewall Basic (Free) plan. It provides essential managed firewall protection, a Web Application Firewall (WAF) that can block suspicious upload attempts, unlimited bandwidth, a malware scanner, and built-in mitigation for OWASP Top 10 threats — all at no cost. Enabling this free layer gives you virtual patching coverage and continuous monitoring while you remove or update the vulnerable plugin. Sign up here: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(For teams needing automated malware removal, advanced IP controls or monthly security reports, our paid plans provide those extended capabilities.)

---

Final recommendations — prioritized

1. If you run the vulnerable plugin, remove or disable it immediately.
2. Turn on WAF-based protections (virtual patching) to block upload attempts targeting the plugin endpoints.
3. Scan your uploads directory for PHP or suspicious content and remediate any findings.
4. Rotate credentials and enforce strong passwords + MFA for all admin/editor accounts.
5. Reintroduce Editor upload capability only after you’ve removed the vulnerable code and validated your site integrity.
6. Subscribe to vulnerability and patch notifications so you can act fast when official fixes are released.

---

We're here to help

If you’re a WP-Firewall customer, we can deploy a tuned virtual patch to block exploit attempts against this plugin for you. If you haven’t yet, sign up for the free plan to add an immediate layer of automated protection while you follow the remediation steps above: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Protect your site quickly — attackers automate exploits for known vulnerabilities, and time is your most valuable defense.

— WP-Firewall Security Team