Apache shows 403 forbidden when "destination=" contains url encoded question marks (%3F) (CVE-2024-38474)

Problem/Motivation

(I hope the component "routing system" is right, otherwise, please adapt!)

Apache's fix for https://www.cve.org/CVERecord?id=CVE-2024-38474 means no %3Fs are allowed anymore in URLs.
This has landed recently with Ubuntu upgrades for example.

Whenever Drupal adds a destination query parameter that itself has a query parameter, the original one gets encoded as %3Fq%3D, i.e. ?q=
Which in turn means visitors get an HTTP 403 instead of the proper page.

This is pretty related to 🐛 Blanks in query strings not allowed anymore, HTTP 403 forbidden, "Rewritten query string contains control characters or spaces" (Apache CVE-2023-25690) Active

EDIT: It seems this is no issue anymore.
It's is just that my vhost config has the following in it, additionally to the core .htaccess (and I can't tell why :-) ) :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# https://www.drupal.org/project/drupal/issues/3347569 ; add B to flags
RewriteRule ^(.*)$ index.php?q=$1 "[B= ,L,QSA]"

Whereas the current drupal/core composer package's .htaccess has this:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]

Steps to reproduce

EDIT: I wrote the below two paragraphs before finding the solution:

There might be several situations where this might occur.
I faced this when placing a login block on a page, say /members for example.
After logging in, I get redirected to the following page:
https://domain.at/members?destination=/members%3Fq%3Dmembers

I don't know where the (encoded) /members?q=members actually comes from, as the originally visited page is /members without any query strings. It is unnecessary. And it breaks the login on every site using a placed login block. Or probably any other mechanism that retains query strings, I also see this with searches that retain selected facets.

Proposed resolution

It seems this was caused by leftover config stanzas of an older Drupal version.
I'm posting this here just for reference, if anyone else runs into the same problem.
The site seems to run without problems with the new rewrite rule only.