Make (formerly Integromat Connector) <= 1.5.10 — Authenticated Administrator Arbitrary File Upload (CVE-2025-6085)

Date: 2025-09-03

Author: Hong Kong Security Expert

Summary

CVE-2025-6085 affects Make (previously Integromat Connector) plugin versions up to and including 1.5.10. An authenticated administrator can upload arbitrary files to the site via the plugin’s upload endpoints. Although exploitation requires admin credentials, the consequences can be severe: webshells, remote code execution, persistence and full site compromise.

This advisory provides a technical breakdown, realistic attack scenarios, detection indicators, an incident response playbook and practical mitigations you can apply immediately — with a focus on operational, server-side hardening and virtual patching where appropriate.

Why site owners should care even when administrator privileges are required

• Administrator credentials are commonly reused, leaked or phished; a single compromised admin account enables direct exploitation.
• Many sites have multiple admins (developers, contractors) which increases exposure.
• Attackers can chain other bugs (XSS, CSRF, session fixation) to gain admin sessions and then exploit this upload flaw.
• Once an attacker can place executable files under webroot, they can execute code, persist and pivot across the environment.

Treat this vulnerability as high priority even if it requires admin authentication.

Technical breakdown (what “arbitrary file upload” means here)

Arbitrary file upload vulnerabilities occur when file uploads are stored without sufficient server-side validation of:

• File type and MIME type
• File extension
• Destination directory
• File contents (to prevent executable code)
• File name (to prevent path traversal)
• Authorization checks on the upload endpoint

In Make <= 1.5.10 the upload endpoint allowed an authenticated administrator to place arbitrary files on disk. If the destination is web-accessible (uploads, plugin directory), an attacker may upload a PHP webshell and invoke it via HTTP. Alternatively, uploaded files might be included later by other application logic, leading to remote code execution.

Typical components of such an exploit:

• An upload endpoint accepting file data via POST
• Lack of strict server-side type/extension/content checks
• Upload destination accessible to the webserver
• Permissive file permissions or webserver configuration that allows execution

Realistic attack scenarios

1. Malicious admin or compromised admin account:

   A compromised vendor or contractor admin account is used to upload a PHP webshell via the plugin, then the attacker executes commands to persist and escalate.

2. CSRF / stored XSS chain:

   An attacker induces an admin to perform actions or exploits stored XSS to obtain a privileged session, then uploads a payload.

3. Persistent backdoors / supply-chain abuse:

   Uploaded backdoors survive updates or are used to tamper with other plugins/themes/core files.

CVSS and risk context

The published CVSS score is 7.2. The score reflects high impact (possible remote code execution / site compromise) while attack complexity is moderated by the requirement for admin privileges. In practice small sites are often at higher risk due to weak credential hygiene and limited monitoring.

Detection: signs you may have been exploited

• New or modified PHP files in:
  • /wp-content/uploads/
  • /wp-content/plugins/make-connector/ (or the plugin folder name)
  • Other plugin or theme directories
• Files with odd names or double extensions (e.g., .php.jpg, .phtml)
• Files with timestamps matching suspicious admin logins
• Unrecognized admin users or recent role changes
• Suspicious cron jobs or scheduled tasks
• Outbound connections from the webserver to unusual IPs or domains
• HTTP logs showing access to newly uploaded files or unusual POSTs to plugin endpoints
• Modified .htaccess or server configs enabling execution

Useful detection tools: file integrity monitoring, server access/error logs, malware scanners, and database audits for suspicious users or option changes.

Immediate steps if you run the affected plugin (incident triage)

1. Isolate and contain
   • Place the site into maintenance mode or take it offline to limit attacker operations.
   • If possible, block public HTTP access at the firewall or server while investigating.
2. Preserve evidence
   • Copy logs (web access/error, FTP/SFTP, SSH), database dump and filesystem listings to a secure location for forensics.
   • Do not overwrite logs or reboot critical systems unless necessary for containment.
3. Identify and remove suspicious files

   Search for recently added PHP files and inspect contents. Preserve forensic copies before removal.

   find /var/www/html/wp-content/uploads -type f -mtime -7 -print
   find /var/www/html/wp-content/plugins -type f -name '*.php' -mtime -7 -print

   Look for webshell indicators like base64_decode, eval, preg_replace with /e, system/exec calls.

4. Change credentials
   • Reset all administrator passwords and service accounts (FTP, SSH, DB).
   • Force logout of all users and expire sessions.
   • Rotate API keys and tokens used by the site.
5. Check for persistence
   • Inspect wp-config.php, mu-plugins, .htaccess and theme/plugin PHP files for injected code.
6. Restore from a known-good backup

   If available, restore from a clean backup taken before the compromise. Verify the restored site is patched and clean before reconnecting to production.

7. Update or remove the plugin

   If a patch exists, apply it immediately. If no fix is available and the plugin is non-essential, uninstall and delete its files — deactivation alone can leave files on disk.

8. Harden and monitor
   • Apply server-side hardening and set up continuous monitoring for at least several weeks after remediation.

If you lack confidence to perform the steps safely, engage your hosting provider or a professional incident response team — incomplete cleanup can leave persistent backdoors.

Practical mitigations you can apply immediately (no code-level patch required)

These mitigations reduce attack surface and limit impact even when the vulnerable plugin remains installed.

A. Block upload endpoint(s) at WAF / webserver level

Create rules to block POST requests to the plugin’s upload endpoints except from trusted IPs. If your firewall supports virtual patching, block requests matching exploit patterns (for example POST to admin-ajax.php with a specific action parameter).

Example nginx rule to deny a specific plugin upload URI:

location ~* /wp-admin/admin-ajax.php {
    if ($request_method = POST) {
        if ($args ~* "action=make_upload") {
            return 403;
        }
    }
}

Confirm action names and URIs by inspecting the plugin source and test rules on staging first.

B. Disable PHP execution in upload directories

Prevent executed PHP from uploaded files by configuring the webserver:

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

<IfModule mod_php7.c>
    php_flag engine off
</IfModule>
<FilesMatch "\.(php|php5|phtml|phar)$">
    Require all denied
</FilesMatch>

Nginx (server block):

location ~* ^/wp-content/uploads/.*\.(php|php5|phtml|phar)$ {
    deny all;
    access_log off;
    log_not_found off;
}

This blocks direct execution even if a PHP file is uploaded.

C. Enforce strict file type checks at upload handlers

Where feasible, restrict accepted MIME types and extensions to known-safe types (images, PDFs). For untrusted plugins, rely on server-level controls until the plugin is patched.

D. Harden admin access

• Require two-factor authentication for all administrator accounts.
• Remove unused admin accounts and limit admin count to the minimum.
• Use strong, unique passwords and a password manager.
• Restrict wp-admin access by IP or using HTTP Basic Auth if operationally possible.

E. Least privilege for PHP processes and file permissions

• Ensure the webserver runs with an unprivileged user account.
• Set filesystem permissions so wp-content is writable only where necessary and plugin files are not world- or webserver-writable unless updating.

F. Regular backups & immutable copies

• Keep daily offsite backups and at least one immutable snapshot that the webserver cannot alter.
• Test restores periodically.

G. Monitoring & alerting

• Use file integrity monitoring to alert on new or modified PHP files.
• Monitor outbound connections and abnormal traffic patterns.

WAF & virtual patching: what they do and why they matter here

Virtual patching applies rules at the firewall layer to intercept and block exploitation attempts without modifying application code. When an official patch is not yet applied (or cannot be applied immediately), virtual patches offer immediate protection.

Common virtual patch tactics for this vulnerability:

• Block POSTs to the specific plugin upload action except from trusted admin IPs.
• Block multipart uploads that include PHP opening tags or filenames ending in .php.
• Block requests with suspicious multipart payloads or unexpected parameters.

Virtual patching is valuable for short-term protection while you patch, remove the plugin, or perform a controlled remediation.

Sample WAF signatures (conceptual patterns)

These are illustrative patterns; test carefully on staging to avoid false positives.

• Detect filename ending in .php in multipart upload:

  Condition: multipart/form-data && filename =~ /\.php(\d+)?$/i

• Block uploads containing PHP tags:

  Condition: request_body contains “<?php”

• Block POST to plugin upload action:

  Condition: POST && request_uri contains “/wp-admin/admin-ajax.php” && args contains “action=make_upload”

Long-term security: developer & site owner checklist

• Keep WordPress core, themes and plugins updated; subscribe to vulnerability feeds for fast awareness.
• Limit administrator accounts and audit roles regularly.
• Enforce 2FA for privileged users.
• Use strong, unique passwords and rotate credentials on suspicion.
• Disable file editing in WP admin:

  define('DISALLOW_FILE_EDIT', true);

• Regularly scan for malware and perform file integrity checks.
• Harden PHP: disable dangerous functions (exec, shell_exec, system) if not required.
• Disable directory listing in webserver configuration.
• Use server-side protections such as mod_security or equivalent rulesets and a properly configured WAF.
• Maintain tested backups and restoration plans.
• Limit SSH/FTP access to known IPs and use key-based SSH.

Incident response playbook (detailed workflow)

1. Triage (first 24 hours)
   • Confirm whether the site runs the affected plugin/version.
   • Create forensic snapshots of server and database.
   • Limit access by changing admin passwords and placing the site in maintenance mode.
2. Contain (24–72 hours)
   • Apply firewall/WAF rules to block exploit patterns immediately.
   • Disable or uninstall the plugin if no trusted patch exists.
   • Preserve and remove suspicious files after forensic copies are taken.
   • Rotate admin and system credentials.
3. Eradicate & Recover (72 hours – weeks)
   • Clean or restore compromised files; if uncertain, restore from a clean backup.
   • Patch and update all software components.
   • Rebuild systems if necessary and reissue API keys and secrets.
4. Post-incident
   • Perform root-cause analysis to understand how admin credentials were exposed.
   • Improve logging, monitoring and admin training.
   • Consider regular security assessments and penetration tests.

Indicators of Compromise (IoCs) — quick checklist

• New files with suspicious names in uploads or plugin directories
• Webshell signatures: base64_decode, eval(base64_decode(…)), preg_replace with /e, system/exec/passthru
• HTTP logs showing access to suspicious files or POSTs to plugin endpoints
• Unexpected outbound connections from PHP processes
• Unrecognized admin users or role changes

Example hardening snippets (use carefully)

Disable XML-RPC if not required:

add_filter('xmlrpc_enabled', '__return_false');

Disable plugin/theme file editing in wp-config.php:

define('DISALLOW_FILE_EDIT', true);

If you cannot patch immediately — temporary defensive options

• Uninstall and remove the plugin entirely if it is non-essential.
• Delete plugin files after deactivation to avoid leftover code.
• Block the plugin’s admin endpoints at the webserver or WAF level.
• Restrict wp-admin to known IPs or place HTTP Basic Auth in front of wp-admin.
• Monitor for exploitation indicators continuously.

Closing advice from a Hong Kong security expert

Code paths that accept files and write under webroot must be treated with the highest caution. Admin-level vulnerabilities often lead quickly to complete compromise because they allow attackers to place persistent executable code. If you run the affected plugin and cannot update immediately, take conservative steps: disable or remove the plugin, apply server-level restrictions, enforce 2FA and other admin hardening, and assume compromise until proven otherwise.

When in doubt, involve your hosting provider or a trusted incident response team to ensure a thorough and professional cleanup.

Final checklist — quick actions to perform now

1. Verify plugin version: if <= 1.5.10, act immediately.
2. If a patched version is available, update without delay.
3. If no patch exists, uninstall and delete the plugin files.
4. Enforce 2FA and strong passwords for all admin accounts.
5. Disable PHP execution in uploads and block plugin upload endpoints at the server/WAF level.
6. Scan for suspicious files and preserve evidence for forensics.
7. Rotate all credentials and API keys after cleanup.
8. Enable monitoring: file integrity, outbound traffic and access logs.

References and further reading

• CVE-2025-6085 (public advisory)
• WordPress security hardening guidelines (official documentation)
• PHP and webserver hardening best practices