Closed BurntimeX closed 1 month ago
A potential workaround is to use base64 which when encoded only contains the special characters =
, +
and /
whose encoded variant is unaffected.
We have decided to not make any changes.
The developers of Apache have realized that their fix went a bit too far and caused troubles with legitimate usages such as ours. Changes have been made to prevent the incorrect blocking in such cases: https://github.com/apache/httpd/commit/a1a93beb58b81f1de2b713ae5f96c41ed5952a74
This fix will be rolled out soon and distributions such as Debian have already acknowledged this to be a regression and will backport the changes: https://security-tracker.debian.org/tracker/CVE-2024-38474
If you do not want to wait for the fix, then the rewrite rules in the .htaccess
must be adjusted. In the rewrite rules, [L,QSA]
at the end of the line must be replaced by [L,UnsafeAllow3F,QSA]
. This change overrides the new filter for this rule.
Apache's fix for https://www.cve.org/CVERecord?id=CVE-2024-38474 means no
%3Fs
are allowed anymore in URLs. This causes a problem in the login form, where the URL of the originally called page is passed encoded as theurl
parameter.