WP Toolkit extension causing significant server-wide ongoing issues

[magestyx]

Server operating system version

Almalinux 10

Plesk version and microupdate number

18.0.78 Update #4

We recently setup all new servers and migrated WP sites to them (up to date WP installs). Seeing the new WP Toolkit extension, we thought that looked like a good integration, so we connected it to all sites and installed the plugin onto all sites.
Immediately we started having issues. Every day we'd check on the sites and the WP Toolkit would be connected to a DIFFERENT site on the server than the hosting account we were viewing in Plesk. Almost every site on the server would do this. We'd try to re-scan/re-connect, but WP toolkit would often take 3-4 attempts before it'd find the right site. Then the next day, they'd be scrambled again.
We did flush the WP Toolkit cache - multiple times.
The biggest problem is that the plugin will overwrite the login page on these sites, so clients are locked out. We have hidden login links set using the Admin and Site Enhancement plugin on most sites, and WP Toolkit would change them on all or most of these sites on the server to the login of one of the other sites on the server (not necessarily the wrong site that it's connected to, either).
We finally disconnected WP Toolkit from all sites, and removed the plugin from all sites and even uninstalled the extension from all servers, and yet the login page overwrite is STILL happening. It's actually changing the value in the database. It's happened on multiple new servers - all Plesk Web Pro Edition, Almalinux 10.
It's like an annoying virus we can't get rid of and we regret ever installing this accursed thing. BEWARE of this extension.
Please help.

This morning, per another thread here that likely isn't related, we added the following lines to: /usr/local/psa/admin/conf/panel.ini
[ext-wp-toolkit]
installIntegrationPluginToNewSites = false
rolloutIntegrationPluginToExistingSites = false
integrationPluginApi = false
integrationPluginUiModuleEnabled = false
integrationPluginEventModuleEnabled = false

We won't know of results for a bit, but we're just trying anything we can.

 

[Sebahat.hadzhi]

Hi, @magestyx . Just so I can make sure I have a clear picture of the issue you are experiencing - do you mean that when you are logged with a Subscription user A, under WP Toolkit you see websites that belong to a Subscription user B?

I am afraid, I am not familiar with the Admin and Site Enhancements plugin and what it does exactly. Do you have a custom login URL configured through it that's then being overridden to the default wp-login.php value?

Would it be possible to provide me with steps to reproduce the issue, i.e. the following details:

• STEPS TO REPRODUCE
• ACTUAL RESULT
• EXPECTED RESULT

so I can file an internal bug report for our team to further investigate.

 

[magestyx]

Hi, Sebahat.

That is correct. When looking at Subscription A, under the Wordpress tab that is added before the Dashboard, Hosting & DNS, etc. tabs, it'll show that the site is Subscription B, or F, or G, etc. And it would change some days when we'd check (or just a few hours later). At first we tried clicking the refresh/rescan button, and it would keep randomly showing some other subscription/site name. Usually after about 3-4 re-scans, it'd find the right one. So we'd leave it and go to the next site on the server to correct. Still, that correct linkage would only last a matter of hours, then it'd reconnect to some other site.
But the login page that it'd find would never auto-correct or change it seems. It would almost always grab the login URL from a specific site on the server. Correcting that would also only last a few hours, and then it'd actually change BACK in the wordpress database.
For example
https://www.sitea.com/login-secret-link-from-site-D (says it's connected to site C)
https://www.siteb.com/login-secret-link-from-site-D (says it's connected to site D)
https://www.sitec.com/login-secret-link-from-site-D (says it's connected to site A)
https://www.sited.com/login-secret-link-from-site-D (says it's connected to site B)

Crazy, right?

All of the 'login-secret-link's simply take the place of the default login page so that it keeps the login URL hidden from public. A number of plugins do that, and we happen to use ASE for all of them. ASE has an 'admin_and_enhancements' field in wp_options that holds serialized data like many WP fields do. The plugin also has an option to edit the robots.txt file, and that setting in ASE is also being overwritten each time, like for site A it'll have: https://www.sited.com/sitemap.xml

We've used Plesk for all of our servers for 20+ years now, and there have been occasional glitches, but this is one of the biggest we've ever seen - ESPECIALLY since after getting rid of the extension it's still doing the overwrites. And plus overall it seems very random.

All we did is setup new Plesk AlmaLinux 10 servers and use the Plesk Migrator extension to migrate over the sites.
Everything was fine for days as we were doing that process, plus applying a few new standard PHP and nginx settings here and there to the hosting accounts.
There were no issues at all until, as basically the last step in the whole migration process, we decided to enable the WP Toolkit and have it scan for sites to connect.
Since then, we've had this recurring issue, but as far as we know there are no other problems.
This is a big one, though - it's confused the heck out of clients and ourselves trying to login to sites anymore.
We confirmed this issue affected more than one server, but some are dedicated so they didn't have more than one site.
To be on the safe side we've removed it from all sites and servers.

Any help would be greatly appreciated.

 

[Sebahat.hadzhi]

Thanks for the clarification. I configured a test server with several customers/websites, but I am unable to replicate the behavior from a first glance. I have also configured the Admin and Site Enhancements and will continue monitoring the server for a day or so.

In the meantime, my thoughts are that's also possible that something went wrong during the migration. Could you please try disabling the ASE plugin on couple of the websites known to be automatically updating?

Lastly, if you have the option to open a ticket with Plesk support or have your Plesk reseller forward the case to them, I trust it will be easier to find the culprit of the issue with direct server access.

 

[magestyx]

Like I said, though, the sites were fine for days after they were migrated. It wasn't until we integrated WP Toolkit that any of this started happening, and we didn't do that until a few days after all sites had been moved over.
I tried to submit a Plesk ticket, but they said our licenses are through a reseller so they won't let the form submit.
I'll talk to our reseller again to see if they can relay a ticket somehow.

Thanks for looking into it.

 

[magestyx]

(the above message submitted before I meant for it to)
Like I said, though, the sites were fine for days after they were migrated. It wasn't until we integrated WP Toolkit that any of this started happening, and we didn't do that until a few days after all sites had been moved over. I don't remember the exact timeframe, but I think it was a full week until we got to that final step of adding the toolkit.
I tried to submit a Plesk ticket, but they said our licenses are through a reseller so they won't let the form submit.
I'll talk to our reseller again to see if they can relay a ticket somehow.

We've disabled ASE on one site after correcting the login link in it this morning, so we'll see if the plugin is disabled if its setting still gets overwritten somehow.
We did do a test last week where we added a wordpress filter that would detect any wordpress-initiated changing of the 'admin_and_enhancements' field in the wp_options database, then undo it and log it as a PHP error. It indeed caught changes that we tried to do through wordpress. However, the database field was changed a few hours later, and since there was no logging it seems to indicate further that it's not wordpress doing this change in the database - it's something on the server.

Thanks for looking into it.

 

[magestyx]

Note - I've tried to submit a support ticket to Plesk as we've done before with purchased extensions, but since this plugin is 'free' there is no separate license for it. If I try to setup the ticket with the Plesk license, they won't allow the ticket to be submitted - they say we have to contact our reseller. I just spoke with our reseller and they said there's nothing they can do as it's a Plesk extension.
We did confirm on the server via SSH that the WP Toolkit directory is no longer in /usr/local/psa/var/modules/wp-toolkit/ , so it was likely correctly removed last week when we uninstalled the extension via Plesk.

So we're not sure where to go from here...

 

[Sebahat.hadzhi]

Thank you for the update. What's strange is that you are saying the behavior continues even after the WP Toolkit extension is removed. There shouldn't be anything left that triggers specific WP Toolkit behavior. Could you please temporarily enable Plesk debug mode and monitor what's being logged into /var/log/plesk/panel.log at the time the changes of the WordPress instances occur?

FWIW, on my test server I am not observing none of the behaviors - the websites remain attached to the correct user and the custom admin URLs I configured through the ASE plugin remain intact.

 

[magestyx]

Yes - this is totally baffling. With the extension gone, what the heck could still be changing the database?
We confirmed this morning that with the ASE extension off, its values in the database are still being overwritten to the login page for another site.
We've enabled plesk's debug mode now and will watch for another site to have this happen and see if there's any info surrounding it in the logs.