Support » Plugin: Sucuri Security - Auditing, Malware Scanner and Security Hardening » Sucuri email notifications resetting

  • Resolved britwebwpcom


    We have noticed recently that the email notifications keep resetting to the admin role email even after we set a different email address in the alerts tab.

    This is happening every few days so the alerts send to the unique email we add but then automatically defaults back to the admin email so they receive all the Sucuri alerts which we do not want.

    Can you confirm if there is a known issue on this or if there is anything we can do? The API is set but this too seems to need to be added in again as it is missing as soon as the alert email changes. I cant seem to locate what could be causing this to occur, can anyone help?

Viewing 15 replies - 1 through 15 (of 17 total)
  • Let’s try to answer this question taking a look at the code:

    First of all, we need to understand how does the plugin determines the state of the options in the settings page, for this we will take a look at the code that is executed when the security alert options are displayed in the dashboard. This function “sucuriscan_settings_alerts_events” [1] is used to render the HTML of all those checkboxes, and using an iterator we go through all the available options and retrieve the current value from the database [2] (actually, from the settings file, the plugin doesn’t stores the settings in the database).

    If we take a look a the definition of this function “SucuriScanOption::getOption()” [3] the first thing that it does is to load all the data contained in the settings file located here [4] and checks if the requested option is contained in this file, if yes then the function returns that value, otherwise it returns the default value.

    Considering this information, we can assume that the failure point is with the “read the settings file” step, because according to what you are saying, the plugin is randomly “resetting” the settings to their default values. For some reason, in your web server, this file [4] is not being readable by the PHP interpreter at certain moment — we don’t know when yet.

    Since this seems to be an edge case involving specific details about the structure of your hosting account, I cannot do much to investigate. Right now I am unable to reproduce the problem in my server, so I cannot provide a fix. What I suggest you, is to monitor the permissions and content of the settings file, something in your server is either removing the read access or completely deleting the file, that’s why the plugin falls-back to show the default settings.

    Let me know if you can find the reason for this, I will be happy to help if you provide more information so I can reproduce the issue in my server.

    [4] /wp-content/uploads/sucuri/sucuri-settings.php



    Same problem after every update here as well and on multiple websites I admin. Also have to reset the API key constantly as well.



    Hello @jkuzma did you apply the changes suggested in my previous comment?

    Marking as resolved after no response from the original poster.

    @yorman You wrote the settings file was not being readable by the PHP interpreter at certain moment. But nothing prevents the plugin to update this file with default settings several times a week. The permissions are the following: -rwx——.
    I’m going to give up this plugin. Or what are your suggestions?

    @joeyblack — I apologize for not being able to offer you a definite solution to the problem reported in this ticket. I don’t have a suggestion right now to prevent the recurrent resets of the plugin’ settings as I am still unable to reproduce the issue.

    However, I have two theories:

    1. The “sucuri-settings.php” file is being deleted by another process in the server. So we are not seeing a “reset” but a “create” action, considering that the plugin has to create the settings file again when it detects that it doesn’t exists.
    2. It is also possible that, during the WordPress updates, the core system triggers the execution of the “deactivate” hook, which is the action that the plugin uses to reset everything (settings, hardening, security logs, etc…). People have been reporting that the settings are being reverted to the default values with high frequency, more than the frequency we push a new update, so this may not be the case.

    As you can see, both cases are caused by external actions foreign to the code.

    I will contact my project manager to see if we can increase the priority of this ticket so I can investigate the problem more carefully and hopefully find a definite solution. I will mark this ticket as “not resolved” once again until I can provide a fix.

    Hi Yorman,

    I just wanted to add that this is happening to me also.

    I have actually tried disabling email notifications (by removing all entries from the “Alert recipients” email list). This works, and I stop receiving emails. But every week or two, my admin email address gets added back to the list (and I wake up to a lot of emails).

    As you say, it’s as if the plugin is deactivating and reactivating. I think it is quite unusual for the plugin to clear its settings when it’s deactivated – is there a reason for that, or could you keep the settings until the plugin is actually deleted? Maybe that would help at least narrow down the issue, and we can determine if something is somehow deactivating and reactivating the plugin without us knowing.

    If it makes any difference, my host is siteground. Maybe the other people on this thread can share their hosting provider, and we can see if it’s related to who we are hosted with.


    • This reply was modified 1 year, 6 months ago by megamenu.

    @megamenu the only reason for us to reset the settings during the deactivation process is to clear up any data that the plugin created during and after the installation. Many people complained in the past because they were trying to uninstall the plugin but it kept some of its files in the system. Because the distinction between “uninstall” and “deactivate” on WordPress is small, the function that I wrote to trigger the reset of the settings is shared by these two actions.

    However, after thinking about this issue for some time, I concluded that it’s better to leave the files untouched during the deactivation and/or uninstallation. If people start complaining again because the data was not cleared up, the solution is easy, they can simply delete the files by themselves.

    I will make the corresponding changes to solve this problem.

    @yorman I see some plugins that include a checkbox in the settings that you check if you want to delete all data when the plugin it deactivated. It’s certainly useful having a cleanup function, but maybe only running it when the user opts in (or out) could be an option?

    @husobj There is already a button in the settings page to allow the user to reset all the data and changes applied by the plugin. This button actually executes the same function that WordPress automatically executes during the deactivation process, the same function that is executed when an update is triggered. Adding a checkbox may be redundant, and to be honest, I don’t know where to put it 😅

    @ycampo submitted these changes [1] to fix the problem with the settings.

    Once these changes are approved and merged, an update will be released.


    Plugin Author ycampo


    Please try upgrading the plugin to 1.8.18.

    I have the same problem, even I changed permissions to the file 777 nothing changed. This is not working and i had to deactivate the plugin because of this 🙁

    Hi yorman,

    I thought this one was fixed (I updated to the latest version as soon as it was released), but unfortunately this issue seems to have cropped up again. I have lost the API key and it has reset the email notification users.

    I have not changed the settings for a while (maybe 3 weeks?), but looking at the settings files, most of them were ‘touched’ a few hours ago:

    I’m taking a look at the code now to see if I can maybe figure out why that would happen, but if you have any ideas please let me know!


    Hello @megamenu thank you for your message and the screenshot.

    The changes applied to the code to attempt to fix this problem are available here [1]. Scrolling all the way down the page you will see that @ycampo added a new register statement to link the uninstallation event (triggered by WordPress) with the function that is used to reset all the settings, logs, and hardening.

    Meanwhile, the deactivation hook (which was the thing used before the fix) is now calling a function that only resets the scheduled task used to start the malware scanner in the background. You can see the function definition here [2] and the uninstallation function here [3].

    The only conclusion that we can get from reading the code is that WordPress is, for some reason, triggering the uninstallation function. I wish I could reproduce this problem easily, but tracking bugs like this is difficult. I suggest you to add some logs inside both functions, link that to any possible HTTP request from the access logs and —if we are lucky— we may end up with more information to understand what is happening here. I will do the same on multiple servers with different configurations.


Viewing 15 replies - 1 through 15 (of 17 total)
  • The topic ‘Sucuri email notifications resetting’ is closed to new replies.