[wp-trac] [WordPress Trac] #61673: URL-encoded _wp_http_referer causes Apache AH10508, leading to 403 in several places
WordPress Trac
noreply at wordpress.org
Wed Jul 17 10:59:45 UTC 2024
#61673: URL-encoded _wp_http_referer causes Apache AH10508, leading to 403 in
several places
-------------------------+-----------------------------
Reporter: vsteiner | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 6.6
Severity: major | Keywords:
Focuses: |
-------------------------+-----------------------------
Apache has recently made a security fix which disallows rewriting URLs
that contain a %3F (a URL-encoded question mark). See
https://www.cve.org/CVERecord?id=CVE-2024-38474.
Apache will now return 403 whenever it rewrites a URL containing %3F.
Since WordPress puts the referer in form fields (_wp_http_referer), and
browsers append this in a URL-encoded representation to the URL for GET
requests, many WordPress pages/functions are no longer accessible.
To reproduce, use Apache 2.4.59 and up.
* Go to https://example.com/wp-admin/edit.php?post_type=page
* Type something in the search box and confirm
* This will lead to 403, since the originating URL contained a question
mark
Apache offers the rewrite flag UnsafeAllow3F, but as far as I understand,
it will reopen the vulnerability, so it's not a great solution. In
addition, some hosters may not even allow their users to use this flag
(the German hoster Strato being one of them).
This ticket is to ask the question: should WordPress change the referer
mechanism as a consequence of the Apache vulnerability? Would it make
sense to use base64 encoding for the URL to circumvent the issue?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/61673>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list