Vulnerability in Kohana?

Yesterday, our portal, written in Kohana, underwent a successful attack. The idea that it is necessary to sin on a respected framework, the security of which is far from last, was not even discussed at first. The program that crawled our site took about 95 thousand requests and 5 hours to find this vulnerability. Take a close look at these two functions from the Kohana kernel version 3.2:

public function redirect($url = '', $code = 302)
{
    $referrer = $this->uri();
    $protocol = ($this->secure()) ? 'https' : TRUE;
    if (strpos($referrer, '://') === FALSE)
    {
        $referrer = URL::site($referrer, $protocol, ! empty(Kohana::$index_file));
    }
    if (strpos($url, '://') === FALSE)
    {
        // Make the URI into a URL
        $url = URL::site($url, TRUE, ! empty(Kohana::$index_file));
    }
    if (($response = $this->response()) === NULL)
    {
        $response = $this->create_response();
    }
    echo $response->status($code)
        ->headers('Location', $url)
        ->headers('Referer', $referrer)
        ->send_headers()
        ->body();
    // Stop execution
    exit;
}

public static function site($uri = '', $protocol = NULL, $index = TRUE)
{
    // Chop off possible scheme, host, port, user and pass parts
    $path = preg_replace('~^[-a-z0-9+.]++://[^/]++/?~', '', trim($uri, '/'));
    if ( ! UTF8::is_ascii($path))
    {
        // Encode all non-ASCII characters, as per RFC 1738
        $path = preg_replace('~([^/]+)~e', 'rawurlencode("$1")', $path);
    }
    // Concat the URL
    return URL::base($protocol, $index).$path;
}

As you can see, when using the redirect function of the request, the URL :: site function is applied to the current uri, in which preg_replace with the execution modifier “e” is used: rawurlencode is applied to each segment of the url, and the segment is transmitted in double quotes, which allows you to pass something something like ($ {@ phpinfo ()}) and it will work. Thus, if a redirect is made using the link http: // site / path / param1, then adding an expression like ($ {@ phpinfo ()}) to param1, you can execute some code. The main thing is that param1 also contains non-ascii characters, for example, Russian letters. In our case, after the vulnerability was found by the bot, a man took up the matter, and after some time with simple manipulations he was able to fill the shell through this hole. An invaluable help in this was provided by such a moment. The Kokhanovsky exception handler has this slice:

public static function handler(Exception $e)
{
// ..... //
        if (Request::$current !== NULL AND Request::current()->is_ajax() === TRUE)
        {
            // Just display the text of the exception
            echo "\n{$error}\n";
            exit(1);
        }
// ..... //
}

The request has an X-Requested-With header equal to XMLHttpRequest? Keep an error message! The tracker Kohana have already unsubscribed.