Versioning based on a value in a config file seems rather ridiculous. The purpose of putting things into config files is usually so that the end user can change them as needed without waiting on you, and so that you don't have to maintain a unique application for every single customer.
As I mentioned in the comments, are you really planning to bump the version number every time a customer changes their configuration? That's going to be difficult if the customer doesn't tell you about it. You could have the application phone home with any changes, but privacy and security advocates are not going to be happy about that, not to mention, that's extra work for you to set up.
And if you don't update the version number with each change, then it doesn't really tell you anything about the configuration values, does it? If you're trying to debug a problem they're having, you're probably going to have to look at the current configuration, not what it was for five minutes after they installed a year ago.
If you really, really want to add some noise to your version number, this seems like the most relevant section of the SemVer FAQ:
That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.
Since there's no new code involved in this change, that would suggest a patch level increment.