CVE-2024-34506

What it actually does

Opening Special:MovePage for a page containing tens of thousands of subpages causes the request to exceed the configured maximum execution time, resulting in a denial of service.

Why it matters to the business

Wiki administrators or editors with page-move rights can unintentionally or maliciously render the site unavailable, interrupting content editing and public access until the web server or PHP process recovers.

How an attack unfolds

An attacker who possesses page-move rights locates or creates a page with a very large number of subpages and then requests the Special:MovePage interface for that page, triggering the long-running operation that exhausts the request timeout.

How to fix it

Upgrade MediaWiki to version 1.39.7, 1.40.3, 1.41.1 or later; the fix is included in commit 3324d89080922a0853b23e0019ad3a48a4ff389a. As a temporary mitigation, restrict page-move rights or impose stricter subpage-count limits before allowing the move operation.

How to confirm the fix worked

Confirm the installed MediaWiki version is at or above the fixed releases, then attempt Special:MovePage on a page that has a large number of subpages while monitoring request duration and server logs to ensure the operation completes without timeout.

Typical attack path

1. Obtain or abuse an account with page-move rights on a MediaWiki instance
2. Identify or construct a page that has tens of thousands of subpages
3. Request the Special:MovePage URL for that page
4. Wait for the request to exceed the server's maximum execution time, causing a 5xx response or worker crash

How to detect it

Inspect web-server and PHP-FPM access/error logs for requests to Special:MovePage that take an abnormally long time or result in 504/503 responses; correlate with user accounts that hold the move permission and pages known to have deep subpage trees.

• /wiki/Special:MovePage
• SpecialMovePage.php
• request time exceeded
• PHP Fatal error: Maximum execution time

What your security team should do

• Apply the version upgrade immediately on all public and internal wikis
• Review and tighten the 'move' permission to the smallest necessary group
• Add monitoring for unusually long requests to Special:MovePage.php
• Test the upgrade in a staging environment with representative data volumes before production rollout