Support » Plugin: Redirection » Negative value for ip2long output causes MySQL error

  • I’m actually very surprised to not find any other topics about this, as it seems to be an issue that could potentially pop up fairly regularly.

    Here’s the issue: On a client’s website, we are seeing a MySQL error on any page that generates a 404 error. The error we get is as follows:

    WordPress database error Out of range value for column ‘ip’ at row 1 for query INSERT INTO wp_redirection_404 (url,created,ip,agent) VALUES (‘/unknown’,’2013-09-30 14:19:24′,’-1388166405′,’Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36′) made by require(‘<removed>wp-blog-header.php’), require_once(‘<removed>\wp-includes\template-loader.php’), do_action(‘template_redirect’), call_user_func_array, Redirection->template_redirect, RE_404::create

    As you can see, the value being inserted into ‘ip’ is -13881566405. This is a result of the ip2long() function used on line 149 in /redirection/models/log.php. If you view the documentation on, you will see that it returns a negative number on 32-bit systems.

    I’m trying to decide what the best solution for this would be. I think a best overall solution would be to just store the IP address as a string as is; I don’t get the reasoning behind converting between string and long, as it only creates problems like this.

    However, in our case, such a solution would probably be overkill because it would require code changes in multiple places, as well as mysql structure changes, and the code would have to keep being modified to work after each update of the plugin.

    I guess a better solution for the time being might be to change the ‘ip’ column to a signed integer column, but I’m not sure if there is still a chance of values being too large or too small once this is done (because the upper limit will be decreased by half to allow for the lower limit to be negative). Would I need to change it to a signed bigint? I think this would be the safest option for the time being and is what I’ll probably go ahead and try.

    Thanks in advance!

Viewing 4 replies - 1 through 4 (of 4 total)
  • I got same problem, in my inderstanding it’s generated by a bruteforce attack.

    The insert starts like:

    INSERT INTO wp_redirection_404 (url,created,ip,agent) VALUES (‘/wp-content/themes/deliciousmagazine/thumb.php’
    INSERT INTO wp_redirection_404 (url,created,ip,agent) VALUES (‘/wp-content/themes/PureType/timthumb.php’
    INSERT INTO wp_redirection_404 (url,created,ip,agent) VALUES (‘/wp-content/themes/PersonalPress/timthumb.php’
    INSERT INTO wp_redirection_404 (url,created,ip,agent) VALUES (‘/wp-content/themes/freshnews/thumb.php’

    but I even don’t have these themes/patches installed in my WP installation, so I suppose the attacker is trying to force an injection on WordPress to put a redirection on “wp_redirection_404” table.

    I will probably disable Redirection plugin and work over these entries by .htaccess, sadly =(

    Hoping someone comes up with a better solution. For now we’ve just disabled 404 logging in the Redirection options. Hope that helps someone.

    Here’s the solution we implemented.

    On line 149 of redirection\models\log.php we made the following change and this solved the problem for us.

    ‘ip’ => ip2long( $ip ),

    ‘ip’ => sprintf(“%u”,ip2long( $ip )),

    We also found some user agent strings were too long and were causing other db errors, so we further modified the function to truncate long user agents. Below is the function in its entirety.

    static function create( $url, $agent, $ip, $referrer ) {
    global $wpdb, $redirection;

    $insert = array(
    ‘url’ => urldecode( $url ),
    ‘created’ => current_time( ‘mysql’ ),
    ‘ip’ => sprintf(“%u”,ip2long( $ip )),

    if ( !empty( $agent ) ) {
    if (strlen($agent) > 255) {
    $agent = substr($agent, 0, 255);
    $insert[‘agent’] = $agent;
    $insert[‘referrer’] = $referrer;

    $wpdb->insert( $wpdb->prefix.’redirection_404′, $insert );

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Negative value for ip2long output causes MySQL error’ is closed to new replies.