phpBB versions 3.2.5 and below suffer from a native full text denial of service vulnerability.
c5811b9abc0a93f3730a4f0ec740ca6cVulnerability information
=========================
Title: phpBB Native Fulltext Search denial of service
CVE ID: CVE-2019-9826
CVSSv3 score: 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H)
Vulnerability description
=========================
Improper input validation in the Native Fulltext Search component of
phpBB 3.2.5 and earlier allows an unauthenticated remote user to trigger
a denial of service attack via the keywords URL parameter of search.php.
Successful exploitation generates a slow SQL query which causes the
database engine used by phpBB to consume all available CPU resources.
Depending upon the database engine, users will also be completely unable
to create or modify posts due to locks on the search index tables. The
slowness of the query depends on the size of the search_wordlist and
search_wordmatch tables.
Because the denial of service is caused by a long-running database
query, for a typical phpBB installation running on MySQL/Linux, only <#
CPUs> requests need to be made by an attacker in order to consume all
CPU resources available to the database engine. The slow query will
continue to run after the attacker disconnects because PHP does not
detect connection aborts until it tries to send data back to the client.
Vulnerable packages
===================
phpBB 3.2.5 and earlier when configured to use the Native Fulltext
search component. (This is the default configuration.)
Solutions and workarounds
=========================
The vendor has released phpBB 3.2.6, which improves input validation in
the Native Fulltext Search component.
Mitigations are available for earlier versions of phpBB:
1. Set “Search backend” to an engine other than “phpBB Native Fulltext”
2. Set the “Can search board” group permission to “No” for all untrusted
user groups
3. Set “Enable search facilities” to “No”
Proof of concept
================
Due to the triviality of the attack, proof of concept code is withheld
for the moment in order to allow users some time to test and install the
vendor patch.
Report timeline
===============
The vendor was given a initial disclosure deadline of 2019-04-22. A one
week grace period was granted so that a fixed release could be available
at the time of disclosure.
2019-02-18: Initial disclosure to vendor with PoC and candidate patch
2019-02-19: Vendor acknowledges receipt of report
2019-03-12: Update requested
2019-03-13: Vendor verifies vulnerability
2019-03-15: Vendor assigns CVE ID
2019-03-19: Follow-up, no response
2019-04-15: Second follow-up
2019-04-18: Vendor requests extension to disclosure date
2019-04-22: One week extension granted
2019-04-29: Vendor patch released
2019-04-29: Public disclosure