Hi there, as mentioned there:
Fully Patched Version: 4.3.0
All in One SEO is currently version 4.3.2: https://wordpress.org/plugins/all-in-one-seo-pack/
Please make sure that you’re using the latest version of the plugin.
Hi, I’m using v4.3.2 and SiteGround is saying a mod_security rule is being triggered and referenced the Wordfence link above.
Ah, you might want to talk to SiteGround about that, it’s possible they haven’t updated their mod_security rules.
If not, please hang in there and someone from All in One SEO will reply as soon as they can.
Thanks. I did have SG modify the rule for one client, but I can do that for everyone hosted there. LOL.
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.
Hi @twowithink ,
Thanks for reaching out and reporting this.
I’ve informed our Development team and they are actively looking into it.
We’ll let you know as soon as we have an update.
Hey @twowithink,
Are you able to provide us with any steps to reproduce this issue? I’ve created a site with Siteground and everything seems to be working fine with our latest version at first glance.
From what I understand, they enable mod_security by default on all their servers so there’s no security setting that I need to enable, right?
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/
@twowithink is this the “Row Style” section you’re referring to?
https://prnt.sc/ZPHB3vjloLVH. If so, I’ can’t reproduce the error yet.
Hi,
That is correct. This ONLY occurred with our SiteGround hosted websites.
After they excluded the mod_security rule in question, everything worked normally.
@twowithink I tried it out on a Siteground hosted site but couldn’t reproduce it.
We’ve had some other users report similar issues with their sites that are hosted by Siteground so we’ve reached out to them directly and will try to resolve it together with them.
Thank you for the update!
@twowithink I’m going to close this forum thread while we work with Siteground. However, feel free to keep the conversation going by updating this thread with any questions you may have.
