[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