twowithink

@blackstudio – THANK YOU!!!

Wondering the same. It’s actually a required plugin for my theme.

If I rename the folder in the hosting, (e.g. old-insert.php) the message disappears and the plugin seems to function. But that is not good for future updates.

Hi, I’m getting a “If you have a moment, please let us know why you are deactivating.” message at the bottom of the Plugins list that cannot be clicked after the update to v2.5.1 AND I cannot deactivate the plugin within the Plugins list.

Thanks,

Thank you!

Thank you. Hopefully, WordFence will like this updated version.

NOT RESOLVED. Wordfence is still flagging v.3.1.7

https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/mailchimp-forms-by-mailmunch/mailchimp-forms-by-mailmunch-314-cross-site-request-forgery-via-multiple-ajax-actions

I noticed there was a version 1.7.7.3 released today. This has fixed the issue.

Thank you.

I did. 5 Days ago and still no reply.

Request Id: 119875

Thank you for the update!

Hi,

That is correct. This ONLY occurred with our SiteGround hosted websites.

After they excluded the mod_security rule in question, everything worked normally.

Hi,

AIOSEO / SiteOrigin Page Builder plugins.

If both plugins are activated, any attempt to publish a draft or update an existing page gets a 400 error.

This behavior only occurs if there is a value added to the SiteOrigin plugin “Row Style”. If the fields are left blank, the page updates without the 400 error.

This is a new issue and ONLY occurs with our SiteGround hosted websites since they just implemented a new security rule that triggers the 400 error.

Already published pages with the SiteOrigin plugin “Row Style” values already added display normally.

Siteground Said:

A mod_security rule is being triggered.

2023/03/07 23:00:24 [error] 93448#0: [2023-03-07 23:00:24+0000] [beta.speechworks.net/sid#0000000] [client 87.118.135.66] ModSecurity: Access denied with code 400 (phase 2). detected XSS using libinjection. [file “/etc/nginx/modsec/rules.conf”] [id “807086”] [msg “”] [data “”] [severity “0”] [hostname “35.209.87.233”] [uri “/wp-admin/post.php”]

For even further clarification on the rule and why it was implemented, it was related to the following vulnerability:

https://www.wordfence.com/blog/2023/02/all-in-one-seo-pack-vulnerabilities-impacting-3-million-sites-patched/

Hi,

SG reply:

I can see that my colleagues have already provided all available information regarding the mod_sec rule triggered.

I am afraid that we cannot provide any additional information, but hope you will manage to find and resolve and possible culprits as swiftly as possible.

Hi Alex,

I have asked SiteGround and will update you with any response. AIOSEO support have also indicated they are looking into the issue.

Thanks.

Response from SiteGround:

This rule was indeed implemented due to a quite recent vulnerability of plugin – All In One SEO Pack.

https://www.wordfence.com/blog/2023/02/all-in-one-seo-pack-vulnerabilities-impacting-3-million-sites-patched/

The rule is up to date and our security team is constantly adjusting the rules to prevent attacks. If you wish, we can enable the rule again so you can continue debugging the issue with the plugin developers.

I replied:

So you are saying that All In One SEO Pack has not addressed the vulnerability issue to your liking? They claim to have fixed it in v. 4.3+

SG response:

We are not familiar with the All In One SEO Pack plugin and its updates but our mod security rule is triggered by the site. We can enable the rule back so you can test the site if you wish, however, the rule cannot be adjusted on our end. Our security team periodically reviews the rules and adjusts them when needed.