• We’ve noticed that there appears to be a website compromise/hack affecting one of our sites that starts with Forminator. The steps we’ve identified that this compromise takes is that someone accesses the wpmudev-hub= query string on the homepage, for example from our access.log:

    "POST /?wpmudev-hub=34d20c002dbd1084-178623507923291 HTTP/2.0"

    The exact value given may change with different calls to this query string key. That key is found inside the following files in Forminator, making us suspect a flaw in Forminator is the root cause:

    • ./library/lib/hub-connector/inc/class-admin.php
    • ./library/lib/hub-connector/inc/class-remote.php

    Immediately following that request is this:

    "GET /wp-content/plugins/background-image-cropper/accesson.php HTTP/2.0" 200 11 "https://example.com/?wpmudev-hub=34d20c002dbd1084-1786235079232913"

    The background-image-cropper plugin was not on our site until the moment of the request with wpmudev-hub=.

    The second request will place the accession.php file, which appears to be a shell, at the root of our website. From there, the compromise can do basically anything.

    We’ve just blocked the wpmudev-hub= in Cloudflare to aim to nip this in its rear end (since we’re just using the free version of Forminator there is no need for that query string we believe), but the code that enabled it is still in Forminator.

    Before that latest attempt to block this, which we just did so not much data about success, we had instructed nginx to disallow access to the accession.php file, as well as stuff inside the background-image-cropper plugin using config such as:

    location ~* /wp-content/plugins/background-image-cropper/.*\.php$ {
    deny all;
    return 403;
    }
    location ~* /accesson\.php$ {
    deny all;
    return 403;
    }

    Our server also has the following in its php.ini that would have helped limit the damage the shell could do:

    disable_functions = disk_free_space,disk_total_space,diskfreespace,dl,exec,opcache_get_configuration,opcache_get_status,passthru,pclose,pcntl_alarm,pcntl_exec,pcntl_fork,pcntl_get_last_error,pcntl_getpriority,pcntl_setpriority,pcntl_signal,pcntl_signal_dispatch,pcntl_sigprocmask,pcntl_sigtimedwait,pcntl_sigwaitinfo,pcntl_strerror,pcntl_waitpid,pcntl_wait,pcntl_wexitstatus,pcntl_wifcontinued,pcntl_wifexited,pcntl_wifsignaled,pcntl_wifstopped,pcntl_wstopsig,pcntl_wtermsig,popen,posix_getpwuid,posix_kill,posix_mkfifo,posix_setpgid,posix_setsid,posix_setuid,posix_uname,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,show_source,system

    Still, we believe Forminator’s code related to the hub connector is the original backdoor, and so wanted to report this here both to WPMU Dev, and so that other users can see it. We strongly encourage this compromise path get fixed ASAP.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support Amin – WPMU DEV Support

    (@wpmudev-support2)

    Hello @alexclst

    Hope you are doing well today.

    Thank you for your detailed report. I will inform our Forminator team about this for further investigation.

    We still cannot be certain if Forminator has a security vulnerability. We will double-check the files to ensure they are safe and that there are no security issues.

    Kind Regards,
    Amin

    Thread Starter Alexander Celeste

    (@alexclst)

    An update: I don’t remember installing the WPMU Dev Dashboard plugin on this client’s site (use it another client who uses the Pro version of the plugin). But last night I did see it in the Plugins list. Removed it. There are still attempts at the query string as seen in Cloudflare security logs. But they’re entirely dormant and not causing further compromise as Cloudflare is returning 403 on them. I notice that when installed properly the dashboard plugin hides itself completely. Kind of bad behavior if you ask me. That’s neither here nor there for now. Perhaps this compromise was triggering that behavior, and indeed I wasn’t missing seeing that plugin in my plugins list, but the compromise was hiding its tracks when I first wrote here, only for me to see it after writing this and finishing cleaning everything out further? So maybe this is related to CVE-2026-15459 regarding the WPMU Dashboard plugin after all?

    Plugin Support Fida – WPMU DEV Support

    (@fidawpmudev)

    Hello @alexclst ,

    I hope you are doing well, and thank you for the update.

    I have forwarded your message to the Forminator team. They will check and take the necessary actions to fix the issue as soon as possible.

    If you are using the WPMU DEV Dashboard plugin now, please make sure you are using the latest version, 5.0.1. Please remove any unknown plugins or plugins with major vulnerabilities.

    And lastly, please reset your WPMU DEV API Key from the WPMU DEV Hub > My Account > Details & API Key.
    Note that resetting the API key will disconnect all your sites from the Hub. You will need to re-log in with your WPMU DEV Account on those sites to reconnect them with the Hub.
    Learn more: https://wpmudev.com/docs/hub-2-0/your-wpmu-dev-account/#details-key

    I notice that when installed properly the dashboard plugin hides itself completely.

    The WPMU DEV Dashboard plugin is only visible to the admin who activated/connected the plugin. There should be other admin users, and one of them should have access to it. Please try to log in with other Admin users.

    Kind Regards,
    Fida Al Hasan

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.