User registration is NOT saved in a configuration file. It's saved in your database since it's a component option. More specifically, it's saved in the #__extensions table, in the JSON-encoded params field of the record whose element column is com_users.
The first thing I'd check is plain old assumptions gone wrong. You disabled user registration and saved. Did you try logging out, back in and check if the change actually got saved?
The second thing I'd check is whether the change was applied on the correct site. Laugh all you want, if you do 20 years of end user support seeing people making changes on the wrong site while absolutely convinced of the contrary will be a commonplace occurrence.
Now, if we have established that you are changing the correct site, the change is applied and it does revert after a while we need to figure out WHY it's happening.
The file which changed is a backup log file so that's not something you need to worry about. Besides, if your site was hacked I doubt that the only change the attacker would make is re-enable user registration so a bot can register but not activate an account. It sounds a lot like digging a tunnel into a bank to steal a cup of water from the public water cooler in the lobby. No attacker is that stupid.
One way is that a privileged user is changing it. If you've enabled Admin Tools' emails on user login you would know about that so I assume it's not the case.
If you've enabled Admin Tools' SQLiShield (enabled by default) it is not a SQL injection attack either.
This leaves us with a third party extension changing this setting OR your database being periodically restored e.g. by your host.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
