Normal view

There are new articles available, click to refresh the page.
Before yesterdayPatrolServer – Blog

PatrolServer 1.1.0

What better way to start the summer than with a brand new release of PatrolServer, we’ve very proud to announce version 1.1.0 is now available to all of you.

No matter how you use PatrolServer, whether it’s the API, or our dashboard and scanner, you’re going to love this new version. We integrated the most requested features, polished both the front and back-end and made the entire experience a whole lot faster. We put a strong focus on developers past months, keep on reading for more exciting news. You’ll love this as much as we do, for sure!


Technically speaking, filtering cards is not a new feature, it has been enabled for most accounts for the past few months. Today, the feature is officially out of beta phase. We’ve been tweaking the ability to filter cards under the hood, as well as restoring cards is now possible by clicking the “restore” button. Below is a small demonstration on how you can filter out unwanted cards.

Verification with Bash Scanner

In the previous version, verifying your server was only possible by us sending an email to the administrator account of the domain or by uploading a HTML file to your server. We decided to put Bash Scanner a little more in the spotlight (seriously, you’ll benefit the best of the features when installing Bash Scanner), thus the new default verification method is now by using the scanner.

If you prefer to use alternative methods such as uploading the HTML file or by using email, they are still there under the “Alternate methods” tab.


Server reminders has been the most requested feature of the past few months. Basically what it does is, at each chosen interval (either weekly or monthly), we’ll send you a reminder of all the issues on your servers over various mails. The new “Mail settings” page gives you more control over what emails you’ll get and which ones you’d like to exclude.


You can now see detailed analytics data for your scanned servers. It might take some time until PatrolServer gathered enough information over a various amount of time, but analytics gives you a status over time of your current servers.

We also got graphs available to display the amount of exploits and vulnerabilities over time, but we leave those up to you to discover. If you’d like to visit the brand new analytics page, click on your server name on the left top, and select “Graphs”, it’s next under the filter view.

Looking at our own internal analytics has been a lot of fun, we hope you like them as much as we do!

For Developers

Brand new API documentation

PatrolServer is a service for developers to keep track of outdated software on their servers. We run a daily scan on your servers, to make sure you run updated software. We would like to make it easy for you developers to integrate with our services and delivery across many platforms. Our powerful APIs are here to provide you a smooth integration with your own project. Our developer tools allow you to access your own data within the PatrolServer architecture. Our ultimate goal is to cover most virtual facets of PatrolServer, for you to integrate whenever you want.

Developers can now enjoy the brand new API documentation pages. They are much more structured and provide examples for all interactions with the PatrolServer API.

Visit the API documentation now!


The PHP SDK provides a stable interface to implement PatrolServer functionality in your own applications. The SDK makes integration child’s play. Take a look at the example below on how easy it is to intercept when your server finished scanning. You can do all kind of interactions after.

// Use the Singleton or create a separate PatrolSdk\Patrol object
use PatrolSdk\Singleton as Patrol;


Patrol::webhook('scan_finished', function ($event) {
    $server_id = $event['server_id'];

    if ($server_id) {
        // Get the Server object from the server_id
        $server = Patrol::server($server_id);

        // Get the installed software
        $software = $server->allSoftware();

Take a look at the PatrolServer PHP SDK on GitHub, we’ve also written a Laravel Facade with various other features such as automatically updating composer modules the moment they become outdated.

Under the hood

We detect a whole lot more software than ever before, thus we had to tweak performance in order to provide the same smooth experience as before. The team and I have rewritten card generation from scratch, with better performance in mind. We now extensively rely on caching mechanisms, as well as pre-generating data when users are the least active on our platform (eg; at midnight, we perform more resource heavy tasks than during the day).

On average, resource heavy actions are at-least 60% faster than before.

Nowadays, we support a vast majority of the most popular npm modules. We’ve added 80.000 more npm modules to the scanner and we’re counting. The PatrolServer scanner is able to find over 160.000 different installed software (+ modules, packages, …) on your server.

Feel free to give our new changes a try, and as always, thank you for using PatrolServer!


  • Send me mails about my server status (setting)
  • Send me mails about PatrolServer news (setting)
  • Remind me about my server statusses (setting)
  • Quick link from account settings to API settings
  • Remove account (setting)
  • Webhooks event log viewer
  • Bash Scanner is first verification option
  • Support phpMyAdmin
  • Support Joomla!
  • npm now has +30.000 modules
  • Support Magento
  • Card creation from scan results is rewritten from scratch
  • Card creation is up to 50% faster
  • Caching cards
  • Software comparer rewritten from scratch
  • Modal in/out animations
  • Logs in/out animations
  • Filtering cards
  • Add a location filter manually
  • Clear filters from hidden cards itself
  • Loading the app is remarkably faster
  • Tons of app bugfixes
  • Tons of app minor layout fixes & improvements
  • Mini scanners have a new layout
  • API documentation has a new style
  • Bucket API documentation

Filter unwanted solution cards

4 January 2016 at 11:38

Today we’re releasing the Ignore functionality for your solution cards. That means you can take full control over what type of solutions you’d like to see. Just as importantly, you can now report false positives where needed.

Hide cards you no longer want to see

Imagine you would like to hide the WordPress update card like the one above. All it takes is a simple click on the Ignore button, and it will take you to a wizard-style menu where you can add constraints about ignoring that particular card.

It is possible to hide the card forever, or you can tell the filter to hide just that particular version (note, if a new version of the software gets released, the card will be visible again).

View hidden cards

When you’ve hidden solution cards, they are not really gone. As the word describes, they are just hidden. When one or more cards are no longer visible, an option will be shown to view your hidden cards. They’re present in the same format as regular ones.

If you no longer want a filter to be applied, take a look at the Filters view where you can remove your active filters.

Until next time with a new awesome feature!

In-depth analyses of the Joomla! 0-day User-Agent exploit

17 December 2015 at 16:20

On Monday, Joomla! released updates and hotfixes for all their versions. It had to patch a zero-day exploit that was already being used in the wild.Initial analysis by Sucuri, Metasploit and Reddit suggested it had something to do with the storage of the unsanitized User-Agent string into the session data. This session data was stored into an custom Joomla database (utf8_general_ci) and was executed as it was a close handler of the database. We will guide you through the exploit and explain how you can be secure by using standard security measures.

We’ve developed a PoC which injects a malicious payload executing phpinfo.

Part 1: Unsanitized use of data

The easiest part is getting data into the platform. All modern CMS’ have multiple input they take for various reasons. The sended headers, cookies, the url itself. All this data is being processed and, in a CMS, most likely stored somewhere (You’re better off using a static generator to shrink your input vector). In this case, we use the User-Agent or the HTTP_X_FORWARDED_FOR header. This header tells the server what type of client is trying to connect (operating system, browser, versions,…). This is not a mandatory step for many sites, but mainly used for statistics and some including extra javascript/css to enhance the experience of the user. In Joomla! this data is saved into the session.

// File: libraries/vendor/joomla/session/Joomla/Session/Session.php

// Check for clients browser
if (in_array('fix_browser', $this->security) && isset($_SERVER['HTTP_USER_AGENT']))
    $browser = $this->get('session.client.browser');

    if ($browser === null)
        $this->set('session.client.browser', $_SERVER['HTTP_USER_AGENT']);
    elseif ($_SERVER['HTTP_USER_AGENT'] !== $browser)
        // @todo remove code:                           $this->_state   =       'error';
        // @todo remove code:                           return false;

The code snippet above illustrates the fact that the User-Agent string is stored unescaped and unsanitized.

Advice: Always sanitize user input

Part 2: The custom session handler

Joomla! uses a custom session handler to save the session data. The function session_set_save_handler can be used to override the session handler. In the case of Joomla!, they don’t save it into files, but they save it into the database. This is what happens:

  • A session is started by session_start
  • The read handler is called and returns the session data
  • session_decode is used to decode the current session data.
  • The $_SESSION variable is filled

… Now you can change / add data to your $_SESSION array …

  • A session is closed by session_write_close (or termination of the PHP file)
  • The session variable is encoded by session_encode
  • The write handler is called to save the session data

session_encode / session_decode

This uses a special version of serialize, instead of serializing the full $_SESSION, it serializes the values and groups them together with pipes.

  • source: array(“a” => 5, “b” => 6)
  • serialize: a:2:{s:1:”a”;i:5;s:1:”b”;i:6;}
  • session_encode: a|i:5;b|i:6;

When done correctly, these functions do not introduce an attack vector. But because both are using different code, both code bases should be maintained, so they are kept code free. In case of serialize, more people look over it, while session_decode is somewhat left behind.

Joomla session handler

The handler writes the data with a PDO and uses quotes to make sure no SQL injection can happen. This is written really well.

public function write($id, $data)
    // Get the database connection object and verify its connected.
    $db = JFactory::getDbo();

    $data = str_replace(chr(0) . '*' . chr(0), '\0\0\0', $data);

        $query = $db->getQuery(true)
            ->set($db->quoteName('data') . ' = ' . $db->quote($data))
            ->set($db->quoteName('time') . ' = ' . $db->quote((int) time()))
            ->where($db->quoteName('session_id') . ' = ' . $db->quote($id));

      // Try to update the session data in the database table.

      if (!$db->;execute())
            return false;
      /* Since $db->execute did not throw an exception, so the query was successful.
         Either the data changed, or the data was identical.
         In either case we are done.
      return true;
    catch (Exception $e)
        return false;

Though the following line is crucial to this bug:

$data = str_replace(chr(0) . '*' . chr(0), '\0\0\0', $data);

When you serialize a class with protected variables, the difference between normal and protected variables is that protected variables are prefixed with “\0*\0”.

class CustomClass {
    protected $data = 5;
echo serialize(new CustomClass);

Gives you:


But MySQL data can’t save null bytes, so the custom Joomla handler converts them to something that is supported (escaped version of zeros). This is handy because HTTP headers don’t allow null bytes, so you cannot pass null bytes through the HTTP headers. You wouldn’t be able to serialize the protected variables in a class, however the custom handler makes it possible.

Advice: Don’t reinvent the wheel, use the build-in functions (e.g. session handler).

Part 3: The session_decode bug (CVE-2015-6835)

As I’ve said earlier, if session_decode would decode the data properly, this exploit would not exist. Because nowhere in Joomla, they blatantly eval or serialize the User Agent. In januari 2015 a bug was found in the unserialize function (CVE-2015-0273). It made it possible to crash PHP (or execute own code) because it recreated the internal C structures, but didn’t check types. Functions would try to consume this structure and assuming a different type (e.g. using an int as pointer). This bug was quickly patched and a new version was released.

Though, the session_decode uses the same principles and wasn’t fixed. In september 2015, the exploit CVE-2015-6835 was filled. This made it possible to inject some data into the session array by carefully crafting your decoding string.


Gives you:

    'user_agent' => NULL
    '10:"test"' => 5  // Injected

Imagine that the bold part is your User Agent in the session data. If you can terminate the string after your injected code, you can create any variable you want, even objects. In part 3, we will search a way to terminate the string, in part 4 we will search how we can create objects that will be executed.

This bug is already fixed and released in PHP 5.4.45, PHP 5.5.29, PHP 5.6.13, in all supported Ubuntu, Debian and RedHat channels. And it was all released by end september. This exploit is critical for the Joomla! exploit to work, so everybody that installs the security releases of PHP was already save! High five for all those awesome people using automatic updaters!

Advice: Make sure you always use the latest version of your software

Part 4: Making things easier, MySQL UTF-8 support

As described in the previous paragraph, we need a way to terminate the data of the session variable. Luckily, Joomla! uses an own implemented session handler that uses MySQL with utf8_general_ci collocation. Whenever this encounters an unsupported 4-byte UTF-8 symbol, it just terminates the data. After inserting the session data through the custom Joomla session handlers, the following:




And we have the required structure to use the session_decode bug.

Advice: Use escape functions that removes 4-byte UTF-8 symbols from input data

Part 5: The search for an executor

Now that we have a way to add contents to the $_SESSION variable, we can also create new objects and add them to the session variable. Thus now we have to search for something that will get executed. For example, take the following class in your application.

Now we have to search after a call_user_func_array that is called upon __wakeup or __destruct and let it call the init function of our SimplePie object. Multiple valid classes can be found, but the attackers used the JDatabaseDriverMysqli class that automatically calls some cleanup code on destruction. Below are the relevant parts of the class.


This exploit uses multiple bugs in various systems to run its code: it uses an unsanitized User-Agent that is saved in the session data. Because this data is saved with a custom Joomla session handler into the database, a MySQL truncation bug can be used to trigger a session_decode exploit, to break and create custom objects. Those objects are then used to create a payload that will be executed by the disconnect handler of the JDatabaseDriverMysqli class.

In our examples, we always use phpinfo, the real attack doesn’t embed the code to execute directly, they execute the code that enters the 111 post variable:


So most attacks are used with some form of the following User-Agent:


Disclaimer: We added the real exploit for educational purposes (because they can be found everywhere in the forums), don’t use them against other sites!


Many security firms are giving you firewall / mod_security rules to fix this issue. Though, there are many security experts busy in all the upstream projects. They investigate and try to fix exploits as fast as possible. Mostly fixes are released before any exploits are used in the wild. In this case, the Joomla exploit was not fixed before the attacks, but the PHP bug was already fixed for 2 months. I don’t want to give firewall rules as solution. The best solution is to stay up-to-date with all your software. Upgrade Joomla to 3.4.6 or PHP to >= 5.4.45, >= 5.5.29, >= 5.6.13 (ps. Ubuntu and Debian packages also contain the fix).


Joomla has released 2 releases (3.4.6 and 3.4.7) to solve this issue. You are secure for the exploit in this form when using the 3.4.6 update, or an updated PHP version. Though it is certainly advised to upgrade to 3.4.7 because that version adds new security measures that makes sure variants of this exploit cannot happen.

3.4.6 Fix part 1 by sanitizing user input. The User-Agent isn’t saved anymore and the HTTP_X_FORWARDED_FOR should now be an IP. 3.4.7 Fix part 4 by encoding the session data with base64 before running it through session_encode. This way the truncation cannot happen because the 4-byte UTF-8 char is transformed.


Check your site against the exploit with our mini-scanner and know if your all your software are up to date with our full version scanner PatrolServer.

Introducing webhooks

15 October 2015 at 11:35

PatrolServer webhooks are officially available to all our users. As of today, developers are able to integrate PatrolServer within all their favourite applications. So next to polling the results of our scans with our API, we introduce a push mechanism to get information when something has changed.

What are webhooks?

Webhooks are real time events to alert you whenever an event occurs in PatrolServer. For example, your server finished scanning and has new issues. A webhook will be triggered and as a developer, you can now interact based on this new information.

The webhooks are HTTP POST requests, delivered to a destination URL entered in the API settings page. Each time a new event occurs, we’ll perform this action on the URL(s) of your choice.

Let’s take the following use case: new composer package issues have been found on your server. You intercept this with our webhook and automatically run thecomposer update command. Or, what if you’d like to send a message to Slack when your server software suddenly became outdated.

For implementation details, check the API webhooks documentation page.

Awesome! How does this work technically?

As you may have noticed, we make it our daily job to be as secure as possible. Webhooks security makes no difference. We work in three steps:

  1. When an event occurs on PatrolServer, we create an Event object on our server. We then send a JSON message to the webhooks URLs configured in your API settings page, containing a webhook_id and an event_id. No other event information is sent and so no other information can be intercepted.
  2. To get the Event object information,  you will need to fetch it fromhttps://api.patrolserver.com/webhooks/{webhook_id}/events/{event_id} with your API key and secret.
  3. You can then do whatever you want with the information retrieved from the API.

Which events are supported?

Event name Description
webhook.scan_started When our scanner is started both manually by pressing the button or automatically by our daily scan, this event will be sent
webhook.new_server_issues When a new issue has been found by our engine, this event will be triggered. Only new issues that arise will be sent. If you want daily status update of all remaining issues, you need to use the scan_finished event and get the date from our API.
webhook.scan_finished When a manually of automatically scan is done, this event will get sent. You get the server_id, so you can lookup all found issues with our API.

Let’s get started!

Login to PatrolServer and navigate to the API page (click on your email address in the right, top corner and select API).

Enter your webhook URL and you’re all set. Whenever an event occurs, we’ll send a request to that particular URL (or multiple, you can add more than one webhook).

Slack Integration

For the avid Slack users, we’ve made our webhooks compatible with Slack. When you visit the API page, you’ll notice a small Slack icon on the right bottom corner. All it takes is entering an Incoming Webhook URL and our system does the rest.

When you’ve successfully entered the Incoming Webhook URL, your Slack channel will be able to get messages from the PatrolServer Slack Bot as shown below:

Support for npm modules

30 September 2015 at 11:34

Today we’re very happy to announce that from now on, we’ll support npm modules.

We are following the Node.js ecosphere closeby. It is not only a thriving community, but the growth since 2009 has been phenomincal. With npm as main package manager, it is a easy as npm install grunt to install something as awesome as grunt.

Also keeping it secure or updated isn’t hard. Just run npm outdated and you magically see all outdated packages. When the correct semver versions are used, a npm update later, you are updated and secure.

Though many systems have outdated node modules. Not because it is hard. Not because it cause breakage. Just because you don’t manually verify if everything is up to date. We, as PatrolServer, want to make the invisible visible. Notify you when new updates for modules come available. Make sure you have the security updates installed.

How? Run our PatrolServer BashScanner client. It runs read-only on your server and checks current installed software against the newest software. After install you can opt for adding it as cron. And now you will get notified daily if something is outdated.

Combine this with our API and the sky is the limit. For example, with jenkins and automatic testing, the updated node module can be tested and integrated into your codebase, fully automated and fully tested without a touch of a finger.

We are glad to welcome the NPM family to PatrolServer.

Introducing the API

23 September 2015 at 11:34

Great news for all developers out there.

At PatrolServer, it is our mission to make sure no outdated server exists. As of today, we officially open our developers API to everyone who has an account on our service. Current users on free plans are also able to integrate with our API, in short: everyone can integrate with the magical experience of PatrolServer.

    "goal": "build cool stuff!"

Enter the developer area!

But, an API, why?

The possibilities are endless, top of my head, a few examples:

  • When your node modules become outdated, automatically execute the command npm update and you’ll never have to do it manually again.
  • Integrate with a server management tool like cPanel, and get a live status of your server software versions.
  • Send a text message whenever your server becomes outdated (probably something we could offer in the future).
  • Create your own scanning tool like the one we published on Github, and take full control.
  • Let creativity go crazy.

What with the future?

Look, we believe APIs will become more dynamic and task-oriented in the future. It makes sense to use data from others just because they’re so good at that particular field. Same as us, PatrolServer, strives to be the best at detecting outdated software and informing users about it.

The first major enhancement we got planned is the support of webhooks. Imagine a seamless integration with services like IFTTT, how cool would that be? Very.

We’re very thrilled to see what others will do with our API. Go ahead, it’s yours!

New solutions engine

10 September 2015 at 11:33

Whenever we detect outdated and/or unsupported software on your setup, we provide solutions. These solutions come in the form of a “card”, these so-called solution cards then lead you to a guide through the “Let’s fix it” button. A quick example of a solution card that will pop up when your PHP installation is outdated, and requires an update to a newer version:

Imagine the following situation: You got a server running two Drupal instances, both are outdated and will be detected by the system. Our system then generates those solution cards, but what happens next was not something that kept us busy during the first version of PatrolServer development.

Until now, we have fully rewritten our solutions engine from scratch. The current engine is not only faster, but is written with a dynamic way of thinking (think of a certain “what if”, and we’ll be able to generate a solutions card without digging up the current code and making changes).

Grouped solution cards

I’ll best explain this with an example: You got composer running (yup, we now support composer modules through our bash scanner), and the system detects that 4 out of the 7 modules are outdated (and/or no longer supported). However, updating those requires a single command to run: composer update. We now group cards based on the solution. If several different software versions can be updated with the same solution, only one solution card will be provided. It will look like this:

Cards are aware of the installation paths

The solution cards will now provide you with the detection path (if we were able to detect it, currently only through the bash scanner).

Let’s take our previous example, two Drupal instances on different paths will generate two cards, as you got to update both of them.

Bash Scanner

This is probably the biggest change, we designed a client that we called “bash scanner”. It’s open-sourced on Github. When you install bash scanner on your Linux distro, it will detect your currently installed software together with the versions and sends them over to our server. The server then checks if anything is outdated, and reports back.

For those who feel like creating an account during the installation process of bash scanner, that’s also possible (and is highly advised to make use of our daily scanning process).

Until next time.

PatrolServer 1.0.2

31 August 2015 at 11:33

At PatrolServer, we aim for continued innovation. Today I’m pleased to announce that, with the release of PatrolServer 1.0.2, we’re a step closer to our goal. No server should be left with outdated software.

Past month has been incredible for us here at PatrolServer. We’re a little over one month in public beta, and the response from you all has been overwhelming! As most have noticed, we took the time to listen to you all and implemented the most requested features. We enjoyed all of your participation and feedback! Keep it coming. Together, we can make PatrolServer even greater.

Get a quick overview of all your server statuses

For those who have a large amount of servers in their list, it can get messy to get a quick overview of those who are vulnerable. We implemented a red dot indicator to note the user that this particular server is not safe. This small change required us to work on performance. You’ll see the benefits in better performance!

We now support cPanel

cPanel is a web hosting control panel that provides a graphical interface and automation tools designed to simplify the process of hosting a website. We updated our scanner and now check for cPanel. If your instance becomes outdated, it will also be shown in the solutions list of your server (together with a nice guide on how to update your cPanel instance).

Revamped the pricing page and implemented payments

For those who want a little more, we now fully support payments through Stripe. Our pricing page is now much more clear, and you’ll know perfectly what you get. Check it out at https://patrolserver.com/pricing.

Quick note: Every current user will keep his servers added in our beta period, completely free!

Improved security measurements

By now, it’s pretty clear we give a large priority to security. The sign-in process is now throttled, this means when someone enters wrong credentials several times, that particular user won’t be able to login for some time afterwards. This is mainly another step to guarantee the safety of our users.

As always, keep your feedback coming. We absolutely love it!

The PatrolServer team.

Full changelog:

  • Invitation system (you can now invite your friends and get free servers)
  • Stats page now holds the top 50.000 Alexa results
  • FAQ rewritten with more common questions and answers
  • Mini scanner for BIND (https://scan.patrolserver.com/bind/CVE-2015-5477)
  • Mini scanner for cPanel (https://scan.patrolserver.com/cpanel)
  • SSL / HTTPS only
  • Huge performance boost by using caches
  • Bugfix: the character “-” was stripped from the domain name
  • SEO improvements
  • Bugfix: scrollbar issue on Chrome
  • Bugfix: last server was not visible in Firefox on smaller screens
  • Improved initial loading time
  • New pricing page
  • Pricing mechanism is now operational in the app
  • Login throttling
  • Support for cPanel
  • Quick overview in the server list (vulnerable / safe)
  • Password forgotten feature

As a final note, I’d like to announce several new exciting tools for developers. You will be able to integrate with PatrolServer in the next iteration cycle. We will provide a fully functional developers API together with some other tools. More to come soon, so stay tuned!

WebSummit, here we come!

25 August 2015 at 11:33

The Web Summit conference in Dublin is one of the leading European startup conferences. Each year, they select various startups to participate in their Alpha Program as exhibitioners. The great news is, we’re select to join their program!

From 3 to 5 November 2015, we will be rocking Dublin! Come and say “Hi” to our awesome team!

Wall of Shame – Hosters edition

Finding a new hosting company for your site is challenging. I mostly use DigitalOcean, therefore I have to take care of my own security. But when third parties ask for a good hosting for their e.g. PHP/Drupal/Wordpress site, I choke. I have to compare pricing, packages, performance and when I tangled all that, I have to check if they are secure. (I don’t want their database on the street or a defaced website).

On my last hunt to find a decent hosting provider, I got fed up. There are so many providers and when checking their software, you sometimes see that their front page has outdated PHP, as in 5.3 old. EOL for 11 months. That really bothers me. How can I rely on their security when their frontpage isn’t even up-to-date.

To warn future customers, I compiled a shame list including all hosting providers having 2 or more outdated software. Outdated, in this case, means being on an unsupported branch. I didn’t count software that are on a supported branch but are not the newest release.

Edit: To clarify, when I say outdated PHP 5.3, I only mean the standalone PHP version. When an Ubuntu version was detected, it was correctly marked as maintained.

The infamy list

Name # Issues Extra information
CoolHandle 4 Outdated WordPress and PHP version. Vulnerable for Freak and Logjam attacks.
Got Web Host 3 Unsupported WordPress version, vulnerable for Logjam and Freak attacks.
Verio 3 Outdated Apache version. Vulnerable for Logjam and Freak attacks.
Webhosting Buzz 2 Outdated PHP and WordPress version.
Crucial Paradigm 2 Outdated Apache version. Vulnerable for Logjam attack.
City Network 2 Outdated Nginx version. Vulnerable for Logjam attack.
FutureQuest 2 Outdated Nginx and PHP version.
InMotion Hosting 2 Outdated PHP version and vulnerable for the Logjam attack.
Lunarpages 2 Outdated PHP version and vulnerable for the Logjam attack.
Mister 2 Outdated PHP and OpenSSH version.
UK2 2 Outdated PHP version. Vulnerable for the Logjam attack.
Vodahost 2 Outdated OpenSSH and PHP version.
A2 Hosting 1 Outdated PHP version.
AN Hosting 1 Outdated PHP version.
BlueFish Web Hosting 1 Outdated Operating system (all packages).
Eleven2 1 Outdated PHP version.
Hostgator 1 Outdated PHP version.
Midphase 1 Outdated PHP version.
Westhost 1 Outdated PHP version.

Check here for the full list of servers (~100) I scanned.

If you are one of the hosting companies above. Contact us when solved to remove you from the list..