?_vitor_action=update

That URL is only used if wp-cron is non-functional, or if some is intentionally hitting it directly.

If the plugin is active, and the list is being updated normally, hitting that URL will have no effect (see https://plugins.trac.www.ads-software.com/browser/vigilantor/tags/1.3.3/vigilantor.php#L151)

If wp-cron is not working to update the list, a JS call will be enqueued and appended to a page (when the last update time is longer than the update interval) which may be hit by a random client and then go away once it’s updated. If you use a page cache (e.g. WP Super Cache) it’s possible that enqueued script call may be cached. Unfortunately, if the plugin is disabled, calling this URL will result in a full page load so it would be advisable to find out if there is a reason it’s still being accessed and stop it.

Are the hits coming from random IPs?
Are they concentrated around certain times or happening fairly evenly throughout the day?

Thanks for the reply,

The hits are coming mostly from the city that the business is in, but there are hits to this url from random places overseas as well, it’s almost as if they’re being redirected. There’s a new hit literally every few seconds. I’ve had the plugin disabled for awhile as well, I can’t really recall the history of when I had it active but the visits persist either way, I have it back on now. The IPs are random but I see multiple hits from the same IPs a couple times in a row just a second or two apart, as if the page is being refreshed 4-5 times per IP visitor. I have no caching setup. The hits are also happening at all hours of the day. I’m using WordFence to block traffic trying to visit the url, every WordFence hit says the traffic initially visits a normal page like the homepage, about page etc. but is then redirected to this url. At this rate we’re talking thousands of hits a month to “/?_vitor_action=update”

I also can’t manually recreate or see any kind of redirection that might be happening but according to WordFence the visitors never visit this url first, I can also see that not all traffic is being routed there, it’s like a bot net is specifically targeting it or something.

If you go in to WordPress admin, Plugins, and then settings for Vigilantor, does it show the list was last updated recently or is it very stale?

And is there any place in the source code for any WP page where you see:

<script type=’text/javascript’>jQuery.ajax({ url: ‘https://yourblogurl.com/?_vitor_action=update&#8217; });</script>

It sounds more like an issue with the plugin and site configuration than a directed attack, but I checked a handful of example sites where I have the plugin and there are no hits logged to that URL since cron is working so that script call should never be enqueued.

Also, can you test to see if your server can download https://openinternet.io/tor/tor-ip-list.txt or over https://? If it can’t download that, then it won’t have an updated list and may try frequently or add the JS.

I manually updated the plugin’s list before so I’m not sure when it was last automatically updated unfortunately, but I do see that line of code in the source so I guess cron is not configured (the host is bad and hard to deal with, will be switching). I’m not sure how to test if the server can download that file but I only have cPanel access, is that enough?

Here is a PHP script you can use to test.

Drop it in the root of your wordpress install where your wp-config.php file is located. It should tell if there are any issues downloading the list or not.

If it’s been a while since you manually updated the list, check in the Vigilantor settings what it says for when the list was last downloaded. If it’s not automatically updating, it will should be more than 10 minutes old.

<?php

error_reporting(E_ALL);
ini_set('display_errors', 1);

require_once 'wp-config.php';
require_once 'wp-includes/load.php';

var_dump( _downloadExitList() );

function _downloadExitList()
{
    $use_ssl = false;

    if (function_exists('curl_version')) {
        $ver = curl_version();
        if (in_array('https', $ver['protocols'])) {
            $use_ssl = true;
        }
    } else if (in_array('https', stream_get_wrappers())) {
        $use_ssl = true;
    }

    $url = ($use_ssl ? 'https:' : 'http:') . '//openinternet.io/tor/tor-ip-list.txt';

    $try     = true;
    $success = false;

    do {
        $req = new WP_Http();
        $res = $req->request($url, array('httpversion' => '1.1'));

        if (is_wp_error($res)) {
            if ($use_ssl) {
                $use_ssl = false;
                $url = 'https://openinternet.io/tor/tor-ip-list.txt';
                continue; // try again with http
            }
            $try = false;
        } else {
            $res     = $res['body'];
            $try     = false;
            $success = true;
        }
    } while($try);

    if (!$success && is_wp_error($res)) {
        echo "Download failed with error: " . $res->get_error_message() . "<br>\n";
        $res = false;
    } else {
        echo "List downloaded okay<br>\n";
    }

    return $res;
}

Actually it is automatically updating, I clearly saw the last update time change just now when I refreshed the page after a bit of time had passed. I’ve noticed that this line of code: “<script type=’text/javascript’>jQuery.ajax({ url: ‘https://yourblogurl.com/?_vitor_action=update’ });</script>” appears in my source code as well but only if I’m viewing the site logged out.

Hi mtlsam,

Based on your feedback, I think wp-cron is not working on your site for some reason, but I found a possible issue with the Ajax code (at least on one of my test sites).

It could possibly link to “https://site.com/wordpress?_vitor_action=update&#8221; which would result in a redirect to /wordpress/?_vitor_action=update which browsers will not follow in Ajax requests.

Also, to prevent the possibility of a handful of clients getting served that JS around the same time on very busy sites, it will now only add that script call approximately 10% of the time (when the lists are outdated).

Please update to 1.3.5 if you have PHP 5.6 or higher installed on your server and I think this should fix the problem.

Thank you for opening this thread!