CVE-2025-32044: Moodle allows unauthenticated REST API user data exposure

The vulnerability describes unauthenticated user data exposure via stack traces in API calls. The provided commit (41917db65e6b3dba3bf3d805a8599e6752655646) directly addresses this by modifying how stack traces are handled.

1. Analysis of lib/classes/router/response/exception_response.php:

   • The function get_payload_data within the class core_router\response\exception_response (namespace derived from Moodle's file structure and common practice, confirmed by checking Moodle source) was changed.
   • Previously, it assigned $exception->getTrace() directly to the stacktrace field in the response. This raw trace could include function arguments if zend.exception_ignore_args was not set in PHP's configuration.
   • The fix explicitly filters out 'args' from each frame of the stack trace using array_map and array_filter.
   • This directly points to core_router\response\exception_response::get_payload_data as the function responsible for preparing the vulnerable stack trace output.

2. Analysis of lib/setup.php:

   • This file was modified to enforce ini_set('zend.exception_ignore_args', '1');. This is a global mitigation strategy to prevent arguments from appearing in any stack trace by default.
   • While this change is crucial for the fix, it doesn't pinpoint a specific Moodle function that is vulnerable but rather a configuration Moodle now enforces to protect itself. The vulnerability exists in how Moodle handles exceptions when this PHP setting is not active, which leads back to get_payload_data.

3. Analysis of lib/tests/classes/router/route_testcase.php:

   • The test function assert_exception_response was updated to assert that 'args' are not present in the stack trace, confirming the fix in get_payload_data.

The primary function that would appear in a runtime profile during the exploitation (i.e., when the sensitive data is being packaged into the response) is core_router\response\exception_response::get_payload_data. The vulnerability isn't that this function itself takes malicious input, but that it handles exception objects in a way that, under certain PHP configurations, leaks sensitive data that originated from arguments of other functions higher in the call stack during an API request that led to an exception.