A reporter uncovered use after free issues in the Apache HTTP Server triggered by a fuzzing tool when APR pool debugging is in use. Pool debugging is not enabled by default, and should not be used in production environments. The bugs do not get triggered in a default build and we would not classify them as a "zero day vulnerability".

The reporter has provided additional info publicly under:
https://github.com/hannob/apache-uaf/.

Daniel Gruno from the web server PMC has looked at the issue extensively, and with tens of millions of tests against httpd versions 2.4.29 through 2.4.38 (he reworked Hanno's code into a threaded python test) with no pool debugging. Those tests did not show any problems. We therefore believe the problem to not occur without pool debugging.

With pool debugging most of the occurrences happen when HTTP/2 is used via mod_http2. Those problems are, at least partially, understood. There are discussion between the web server and the APR project on how to best fix them. As already noted, pool debugging is not meant for production use.

Another type of error also contained in the same original report, an assert in __pthread_tpp_change_priority pointing at a pthread mutex problem, was analyzed and fixed. We are not aware of a successful reproduction of that issue with 2.4.37 (or later).

Unfortunately the OpenBSD platform uses APR pool debugging by default. Due to another bug, these builds would crash when using HTTP/2, so we do currently not expect them to experience the majority of the use after free issues. We are in contact with OpenBSD maintainers on how to best resolve the situation.

The Apache HTTP Server is a volunteer project, where people work on the project as time and ability allows, and as such, we do triage problems based on some simple rules;

- Is the issue reproducible in standard (production) systems, or is it
  solely pertaining to debug/testing scenarios?
- Which version are affected? (old versus new, stable versions)
- Does the potential impact merit an immediate fix as CVE, or is it a bug
  added to the list of things to do at a slower pace?

We examined the report closely, and determined that we needed more information from the reporter on a reproducible vector here, as we were unable to, in any way, reliably reproduce the issue on standard systems. As a response was not received for several months, and as we deemed this did not impact stability or security to a degree that merited concern, we have been in a standard holding pattern, waiting for further feedback from the reporter, while simultaneously looking closer at the issue, seeing if we ourselves could find a potential exploit. We have of course reached out to the APR project to see if they can help address the pool issue, and are working with them to further investigate possible solutions.

Furthermore, we would like to point out that the 11 year old Bugzilla report referenced deals with mod_php in the mix and did not have the requested stack trace needed for further investigation, and as such, cannot be reliably compared to the current issues. In addition the part of the new report that shows the same symptom as the old Bugzilla report, has already been analyzed and fixed.