Support » Plugin: iThemes Security » config.php &.htaccess corrupted

  • twohumans


    On several of the websites that I manage, at different times/different days we are seeing errors because the config.php content has been erased (file size = 0) or because the .htaccess has been partially erased.

    We made extensive verification and we know that there was no intrusion on the servers or on the VPS server that host these sites. We also know that it is not an human error. We know that no update (or backup) took place at the time the files were changed. In the latest incident, no update took place in the 3 days prior to the incident and the website is up to date.

    We cannot see any other security problem with the sites that had an incident.

    The solution we applied was to reload the config.php or .htaccess files. So far after correcting the files by reuploading them, the problem has not come back.

    All websites have similar plugin configuration, nothing out of the ordinary for us that manage many WordPress websites.

    So we are looking for ideas / solutions.


Viewing 6 replies - 1 through 6 (of 6 total)
  • nlpro


    Hi twohumans (both of you),

    This reply is stricly about the iTSec plugin writing to the .htaccess file (on Apache webserver).

    I think you should be aware that the iTSec plugin writes EVERY hour to the .htaccess file. Even when there are no changes (compared to the last written content) whatsoever.

    One would expect some kind of optimization in the writing process, so that the .htaccess file only gets written when the content changes. I really don’t like the idea of the .htaccess file unnecessarily being (re)written EVERY hour. Makes it prone to … corruption.

    iThemes really needs to optimize the writing process to the .htaccess file.

    So why is the iTSec plugin writing EVERY hour to the .htaccess file?
    This is for making sure banned IP’s are actually banned (within a reasonable timeframe).
    It got implemented as a cron job in the plugin 7.8.0 release. According to the 7.8.0 changelog:

    Enhancement: Remove quick bans. Persist banned hosts to .htaccess or nginx.conf on an hourly schedule.

    And below an additional related entry from the 7.9.0 changelog:

    Enhancement: Add a setting for configuring the number of bans added to the server config files (.htaccess/nginx.conf).

    The default value is 100. Older banned hosts will be locked out after WordPress loads.
    So probably the best thing to do would be to check the number of banned IP’s and if it’s > 100, lower the setting’s value. Then wait and see what happens.

    +++++ To prevent any confusion, I’m not iThemes +++++

    Thread Starter twohumans


    Thank you, this is interesting.
    So I understand that something must have changed lately that makes these rewrite more prone to corruption. I don’t remember in the last years having this issue, and I just got a few in a week on one of the two files, thus breaking the sites.



    The theory is that as the number of banned IPs increase over time, you may run into timeout issues writing all those bans (default max 100) to the .htaccess file. It all depends on what the hosting env can deal with.

    The newly introduced (ban) setting gives you the possibility to tweak the writing process such that it doesn’t run into such timeouts.

    Remember it’s just a theory. But it’s worth to investigate and to be aware of. In the end there may be a totally different cause.

    Anyway check the number of banned IP’s.

    Thread Starter twohumans


    It was at the default value of 100, I lowered it in one more critical site. I would be surprised that it is a time-out issue, but nothing surprises me anymore (lol) so maybe. I did see a surge in memory usage and i/o just before the incident – but no fault. I’ll keep an eye on all that, and I’ve raised the time-out with the engineers.

    I had this exact same problem today, but it was caused by something else entirety. I’m relaying my story here just in case others have the same issue.

    In our case, the hosting space had become full of database backups (look in /wp-content/uploads/ithemes-security/backups). Checking the ‘Backups to Retain’ setting, I can see it’s still set to 1. But for whatever reason, this is not being honoured as I can see a few weeks worth of database backups still sitting on the server.

    Anyway, because iThemes Security plugin occasionally writes to .htaccess and wp-config.php, it can’t when there is no disc space available, and so those two files get saved empty, consequently causing the website to crash.

    I’m going to log a ticket with the plugin developer. It’s possible this is a bug and setting might not work properly when set to 1.

    I hope that helps someone.

    Thread Starter twohumans


    In our case this does not apply as we do not use iTheme for backups and have enough free space.

    One of the theories we have is that some ModSecurity rules might have caused this since we had errors at about the same time as the incident. We deactivated the rules and are waiting to see if this solves the problem. I do not have a list of the rules that were changed.

    We also added resources to the server because we saw a peak in memory usage (but no fault) just before the incident.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘config.php &.htaccess corrupted’ is closed to new replies.