APCu management
tool_apcu
Admin tool that embeds the upstream APCu management GUI (krakjoe/apcu apc.php) in Moodle's site administration. The GUI file is downloaded to MOODLEDATA from a pinned commit and checked against a SHA-256 checksum. The GUI's own authentication is disabled, access is gated by moodle/site:config, and its write operations (clear cache, delete entry) are protected with a sesskey check.
No security vulnerabilities or code-quality defects were found in the code that could be verified.
- Access control:
index.phpcallsadmin_externalpage_setup(), which callsrequire_login()and checks the external page's access. The page is registered withmoodle/site:config, so only site administrators can reach it. - CSRF: write operations of the embedded GUI (
CC,DU) are detected in$_GET,$_POSTand$_REQUESTand require a sesskey before the GUI is included. The sesskey is added to the GUI's write links. After a write the page redirects to a URL that keeps only the view parameters (post/redirect/get). - Remote code integrity: the PHP file that is downloaded and later
required is pinned to an upstream commit and checked withhash_equals()against a hardcoded SHA-256 checksum, both after download and before every include. A tampered or substituted file is never executed, whatever the transport security of the download. - Output: user-derived values in notifications are passed through
s(). Core renders notification messages unescaped, so this is the correct handling.
The only item recorded is an informational note: the embedded third-party HTML is echoed as-is, so its escaping depends on the pinned upstream file, which is not in the review tree. That cannot lower the grade.
tool_apcu is a small admin tool of about 470 lines of PHP logic. It wraps the upstream APCu apc.php management GUI inside Moodle's site administration. Because of licensing, the GUI file is not shipped with the plugin. It is downloaded to MOODLEDATA/tool_apcu/ from a pinned GitHub commit, checked against a SHA-256 checksum, and then included from index.php.
The security posture is strong. The page is restricted to moodle/site:config through admin_externalpage_setup(). The GUI's two write operations (clear cache, delete user-cache entry) require a sesskey, and the sesskey is added to the GUI's own links. The page then redirects after each write so that a reload does not repeat it. Running PHP code from dataroot is the main risk in this design. The checksum check before every include means only the exact pinned upstream file can run, which also makes the core \curl default of CURLOPT_SSL_VERIFYPEER = 0 irrelevant to the download's integrity.
One informational item is recorded. The HTML produced by the third-party GUI is echoed without filtering, so escaping of cache keys and reflected parameters depends on the pinned upstream file, which was not available for review. The plugin also has PHPUnit and Behat coverage for its helpers and for the CSRF flow, a null privacy provider, and an uninstall routine that removes its dataroot directory.
Findings
index.php includes the downloaded upstream apc.php and buffers its output. It parses the output with DOMDocument, extracts the <body> and echoes it directly into the admin page. Nothing in the plugin sanitises this HTML. Escaping of APCu cache keys, the reflected SEARCH value and other request-derived content shown by the GUI is therefore left entirely to the upstream file. That file is not in the plugin tree or in core, so its escaping could not be checked in this review. This is a note about that dependency, not a vulnerability.
Informational. The page is limited to site administrators, and the file is pinned by checksum, so only the exact reviewed upstream version can run. Any weakness would sit in the upstream code, which could not be inspected here.
The upstream GUI lists APCu user-cache entries (including keys written by Moodle and any other application sharing the PHP pool) and reflects view parameters such as SEARCH back into the page. The plugin's own code applies s() to every value it outputs itself, such as the notification parameters.
// Output APCu GUI.
echo $apcuguihtml;
No code change is required while the upstream file stays pinned. When the pinned commit is bumped (see UPGRADE.md), add a check to the upgrade checklist that the new apc.php escapes cache keys and every reflected request parameter (SEARCH, PHP_SELF-based links).
| Library | Version | License | Declared |
|---|---|---|---|
APCu GUI (apc.php) Upstream APCu management GUI. It is downloaded at install, upgrade or first use to MOODLEDATA/tool_apcu/apcu.php.inc, verified by SHA-256, and included by index.php. | 5.1.28+ (commit e5132e4da010829c7359a6bda4dc985834ba2094) | PHP License 3.01 | ✓ |
Downloaded code is integrity-pinned. tool_apcu_do_guidrop() uses core \curl::download_one(). Its resetopt() defaults leave CURLOPT_SSL_VERIFYPEER at 0, but the file is checked with hash_equals() against a hardcoded SHA-256 checksum before it is moved into place and again before every require_once. A man-in-the-middle could at most make the download fail. They could not get code executed. The options followlocation => true with maxredirs => 0 contradict each other but in practice simply disable redirects.
Storage in dataroot. The GUI file lives in its own MOODLEDATA/tool_apcu/ directory, created with make_writable_directory() and removed by db/uninstall.php through remove_dir(). The paths are built from constants only, with no user input.
Disabling the GUI's authentication depends on include resolution. The upstream GUI's authentication is turned off by apc.conf.php in the plugin directory, which the upstream script is expected to include by relative path. For robustness, index.php could define('USE_AUTHENTICATION', 0) itself before including the GUI. Then the behaviour would not depend on include_path or the working directory. Either way, the Moodle capability check stays in force.