More infos about a possible attack

Hi @islp, thanks for dropping us a message regarding this.

That looks like it may be a bot just dumping spam in every text field it can find, to see what kind of data can be submitted to your pages.

Fixing the collation of the posts table would clear this error, although you may wish to restrict which user levels (if any) can post comments on your pages to prevent these from potentially showing on your pages. For the record, Wordfence doesn’t change database collations and observes the defaults currently set on your server when making changes or plugin updates. WordPress switched to using utf8mb4 quite a while ago, so seeing that there’s a clash between some utf8_general_ci suggests it’s possible a WordPress update didn’t finish changing your tables back then, or perhaps a migration or restore from backup used the wrong collation so now you could have a mixture.

Ultimately, fixing the database collation is something to fix outside of Wordfence, but we do not believe this to be an actual security compromise of your site.

Thanks,

Peter.

Hi Peter, and thanks for your kind reply.

Comments are completely disabled: no user can post a comment.

There are currently three public facing forms (not every public form has a captcha).

Anyway, what I don’t understand is:

• Can WF protect the website against this kind of bot activity?
• Why I couldn’t find any trace of this bot request in the logs and the live traffic report?

I never noticed my collation issues, anyway (THANKS!).

The default db character set is latin1 (COLLATE latin1_swedish_ci).

The default charset of my tables:

– any table has an utf8 charset;
– 2 plugin tables have CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
– 2 plugin tables have CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;
– 1 plugin table has latin1 charset;`

??

In the config.php the DB_COLLATE variable is empty, while the CHARSET is set to utf8.

• This reply was modified 3 years, 3 months ago by islp.

Hi @islp, thanks for the extra information.

I don’t necessarily expect this kind of activity to be registered in Live Traffic unless the bot tried to post so many times it was blocked by your Rate Limiting rules.

You could try out the setting to disable XML-RPC authentication by checking the “Disable XML-RPC authentication” box in Wordfence > Login Security > Settings to prevent authentication attempts through that file. However, manual attempts to access the XML-RPC file itself are commonly tried by attackers, which is perhaps the type of activity that happened here. You may also add the following code to your .htaccess file if you are certain no plugins you use (such as Jetpack) require access:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

You could also try increasing Wordfence > All Options > Rate Limiting > How long is an IP address blocked when it breaks a rule to days rather than minutes/hours. This helps stop automated attempts from retrying so frequently.

Let me know if this helps prevent this kind of comment insertion going forward.

Thanks again,

Peter.

Hi @wfpeter, my xmlrpc.php is exactly the same as yours since many years. ??

There are a couple of things I don’t understand completely.

That is:

1. I found this error in debug.log, so I suppose this error really came out from somewhere. But, if some bot can really run this SELECT on my db, can a similar bot run an INSERT, an UPDATE, a DELETE, ecc.? I must say I noticed this thing only because it produced an error in my db: now that my db is completely ok, with charsets/collate, etc., I could never notice something similar. I’m suspecting another origin for this error, for example a plugin (not a direct request), but I don’t know if this is possible;

2. I don’t think the bot directly wrote the debug.log file because the file is protected and not accessible;

Thanks for taking the time to answer. ??