Major Description
The fix for CVE-2021-44832 in release 2.17.1 of log4j-core prevents remote JNDI injection via the JDBC Appender.
Given the nature of that CVE, an attacker requires local access to the configuration to be able to exploit it, OR in the rare chance the log4j2.configurationFile property is set to a remote HTTP location, an attacker can use a Man in the Middle Attack (MiTM) and inject their own malicious configuration which could disable logging for an application entirely.
Is it possible to disable remote loading of log4j configurations entirely?
If that feature is required, it may be necessary to create a log4j configuration server that provides signed configs to the application, but that seems like overkill to me.
I would opt for limiting the scope of the log4j2.configurationFile to local configurations, and if remote configuration is a feature you cannot remove, limiting it with a flag/variable and also limiting it to HTTPS for remote configs.
I don't think the priority on this is extremely urgent, but someone may try to get a CVE under their belt by demonstrating this vector, and given the pressure you've been under I did not feel the need to get a CVE for this.