Linux Security

wp2shell WordPress Vulnerability: CVE-2026-63030 Explained

by

What Is the wp2shell WordPress Vulnerability?

On July 17, 2026, researchers disclosed the wp2shell WordPress vulnerability, a chain of two flaws that lets an unauthenticated attacker execute remote code against WordPress Core installations. Consequently, the security community tracks this chain under two identifiers: CVE-2026-60137 (critical SQL injection) and CVE-2026-63030 (high-severity REST API batch endpoint route confusion). Since then, moreover, CISA has added both to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation.

Suggested image: a simple flow diagram showing “REST API batch request → route confusion → SQL injection → remote code execution.” Alt text: “wp2shell WordPress vulnerability CVE-2026-63030 attack chain diagram.”

CVE-2026-63030: WordPress REST API Batch Endpoint Vulnerability

First, this WordPress REST API batch endpoint vulnerability targets WP_REST_Server::serve_batch_request_v1(). Accordingly, researchers classify it as CWE-436 (interpretation conflict) and rate it 7.5 (High) on the CVSS v3.1 scale. Furthermore, because the affected endpoint, /wp-json/batch/v1, has shipped with WordPress since version 5.6, the vulnerable code reaches a large installed base. However, some scanning vendors report a higher combined-severity score of 9.8 when they score this CVE as part of the full wp2shell WordPress vulnerability chain rather than as the standalone route-confusion issue; even so, the underlying advisory still treats 7.5 as the rating for that standalone component.

Affected versions: WordPress versions 6.9.0 through 6.9.4 and versions 7.0.0 through 7.0.1.

Fixed in: Versions 6.9.5 and 7.0.2, which WordPress released on July 17, 2026.

CVE-2026-60137: WordPress SQL Injection Vulnerability

Meanwhile, this WordPress SQL injection vulnerability lives in the author__not_in parameter of WP_Query. As a result, researchers classify it as CWE-89 and rate it 9.1 (Critical) on the CVSS v3.1 scale, since it sits in the core class that builds most of the database queries WordPress issues.

Affected versions: WordPress 6.8.0 through 6.8.5, 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1.

Fixed in: Versions 6.8.6, 6.9.5, and 7.0.2.

How the WordPress Unauthenticated RCE Chain Works

On their own, each flaw stays fairly contained. For instance, the route confusion alone remains a bounded problem, and, similarly, the SQL injection normally requires authentication before an attacker can trigger it. Together, though, they produce the WordPress unauthenticated RCE that defines wp2shell: indeed, early researchers found that CVE-2026-63030 functions as a de facto auth bypass, unblocking the authenticated SQL injection so that an attacker could then dump the target database and pivot to code execution. As a result, an unauthenticated attacker can execute code via the WordPress REST API batch endpoint, with no valid account or user interaction required, and potentially achieve complete compromise of the website and its underlying data.

This distinction also affects patch prioritization. Specifically, version 6.8.x carries the SQL injection component but does not appear on the list of branches vulnerable to the full RCE chain, since the route confusion introduced in 6.9 supplies the unauthenticated path. Consequently, a scan that checks only for CVE-2026-63030 may miss 6.8.x exposure to the SQL injection itself.

Is This WordPress RCE Vulnerability Being Exploited?

At disclosure, no evidence of exploitation existed. Since then, however, reports of in-the-wild activity have emerged, and VulnCheck Canaries observed active exploitation beginning July 20. In fact, by the early hours of the following Saturday (UTC), successful exploitation was already well underway, and within three days of disclosure, attackers were widely chaining the two vulnerabilities to attack one of the largest surfaces on the internet. Meanwhile, reports indicate hackers are deploying persistent webshells and installing malicious plugins on affected servers.

Who Discovered the wp2shell WordPress Vulnerability

To begin with, Adam Kues of Assetnote, the attack surface management arm of Searchlight Cyber, discovered the vulnerability and responsibly disclosed it through WordPress’s HackerOne program. Because, however, the researchers described the attack as having no preconditions and being exploitable by an anonymous user against a stock install, they withheld full technical details to give defenders time to patch.

How to Patch This WordPress Core Security Vulnerability

BranchAffectedFixed Version
6.8.xSQL injection only (CVE-2026-60137)6.8.6
6.9.xFull RCE chain (both CVEs)6.9.5
7.0.xFull RCE chain (both CVEs)7.0.2

Given the severity, therefore, organizations operating affected WordPress installations should prioritize upgrading immediately, since applying the WordPress-provided update remains the most effective way to remediate CVE-2026-63030. Fortunately, WordPress has already taken steps to help: maintainers stated they are forcing updates for affected installations with automatic updates enabled. Even so, administrators should still verify that each internet-facing WordPress website has successfully upgraded, since workarounds are not recommended at this time.

If you need help confirming whether the wp2shell WordPress vulnerability has already been leveraged against your site, or needs assistance applying and validating the patch, contact our support team for a review.

References

SourceLink
Rapid7 Vulnerability Analysiswp2shell: A Critical RCE Vulnerability in WordPress Core
SOCRadar CISO FAQWordPress wp2shell (CVE-2026-63030): CISO FAQ & Fix
CVE.org Official RecordCVE-2026-63030
GridinSoft BlogWordPress wp2shell CVE-2026-63030: Update to 7.0.2 Now
VulnCheck AnalysisWP2Shell Vulnerabilities: CVE-2026-60137 and CVE-2026-63030
CyCognito Threat BlogEmerging Threat: CVE-2026-63030, CVE-2026-60137
KEVIntel Exploitation TrackerCVE-2026-63030 Exploitation Observed
Penligent Technical WriteupCVE-2026-63030 wp2shell — Patch Priority and Safe Validation
Strix CVSS ReferenceCVE-2026-63030 Severity, CVSS & Fix

Root Exploit: cPanel & WHM Authentication Bypass (CVE-2026-41940)

by

CVE-2026-41940 is a CVSS 9.8 authentication bypass affecting every supported version of cPanel & WHM. A remote unauthenticated attacker can gain root access to the server in two HTTP requests. Exploitation in the wild has been confirmed since at least February 23, 2026. Patch immediately.

What Is the Vulnerability

The flaw lives in cpsrvd‘s session handling. On a failed login, cPanel writes a preauth session file to disk at /var/cpanel/sessions/raw/ before any authentication occurs. That file is a newline-delimited key-value store:

needs_auth=1
user=
ip_address=172.17.0.1
local_port=2087

The session data was not sanitized before being written. By injecting raw \r\n characters via a crafted Authorization header, an attacker can append arbitrary key-value pairs — including user=root — into that file. On the subsequent authenticated request using the issued cookie, cPanel reads the session file and grants root access.

The three files modified by the patch:

Cpanel/Session.pm          (saveSession — primary fix)
Cpanel/Session/Load.pm     (session loader)
Cpanel/Session/Encoder.pm  (new hex round-trip primitives)

The root cause is that filter_sessiondata() — a sanitizer that strips \r\n=, from session values — already existed, but saveSession relied on each caller to invoke it. The patch moves that call inside saveSession itself, so no caller can bypass it.

Who Is Affected

All cPanel & WHM versions after 11.40. This includes every currently supported release branch. WP Squared (cPanel’s WordPress hosting platform) is also affected.

If you are running an end-of-life version, assume you are vulnerable. No patches will be issued for unsupported builds.

Patching

Run the following as root to force an immediate update:

bash
/scripts/upcp --force

After the update completes, confirm your build version in WHM under Server Information, or:

bash
cat /usr/local/cpanel/version

Patched versions by branch:

BranchPatched version
110.0.x11.110.0.97
118.0.x11.118.0.63
126.0.x11.126.0.54
132.0.x11.132.0.29
134.0.x11.134.0.20
136.0.x11.136.0.5
WP Squared136.1.7

Interim Mitigation (Pre-Patch)

If you cannot patch immediately, block the cPanel and WHM ports at your firewall. This prevents exploitation without affecting hosted sites, email, or applications — only control panel access is interrupted.

For firewalld:

bash
firewall-cmd --permanent --add-rich-rule='rule port port="2083" protocol="tcp" reject'
firewall-cmd --permanent --add-rich-rule='rule port port="2087" protocol="tcp" reject'
firewall-cmd --permanent --add-rich-rule='rule port port="2095" protocol="tcp" reject'
firewall-cmd --permanent --add-rich-rule='rule port port="2096" protocol="tcp" reject'
firewall-cmd --reload

For iptables:

bash
iptables -I INPUT -p tcp --dport 2083 -j DROP
iptables -I INPUT -p tcp --dport 2087 -j DROP
iptables -I INPUT -p tcp --dport 2095 -j DROP
iptables -I INPUT -p tcp --dport 2096 -j DROP

Apply these rules before the patch if your server has any public exposure on those ports. Remove them once the patch is confirmed deployed.

Checking for Compromise

cPanel has published an official detection script. Run it as root:

bash
/usr/local/cpanel/scripts/check_cpanel_rpms --targets=cpanel

Additionally, inspect the raw session directory for anomalous files. Legitimate preauth sessions will not contain user=root:

bash
grep -rl 'user=root' /var/cpanel/sessions/raw/

Any result from that grep on an unpatched server is grounds for treating the host as compromised. watchTowr has also published a Detection Artifact Generator for more thorough IOC analysis.

Check your WHM and SSH access logs for root logins that did not originate from your known admin IPs:

bash
grep 'Accepted' /var/log/secure | grep root
last root | head -30

Hardening After the Patch

This is a reasonable time to enforce controls that should already be in place:

Restrict WHM (port 2087) to trusted IP addresses only. In WHM: Home > Security Center > Host Access Control, or via /etc/hosts.allow:

cpanel: 198.51.100.10 198.51.100.11

Enable two-factor authentication for all WHM accounts: Home > Security Center > Two-Factor Authentication.

Disable root login via cPanel entirely if your workflow does not require it. All administrative actions can be performed through a named reseller account with sudo-equivalent privileges, preserving an audit trail.

The Fine Print

Zero-day exploitation was confirmed as far back as February 23, 2026 — about two months before disclosure. If your server was public-facing on port 2087 during that window without IP restrictions, treat it as potentially compromised regardless of what the detection script returns. A thorough audit of cron jobs, authorized SSH keys, and installed packages is warranted:

bash
crontab -l -u root
cat /root/.ssh/authorized_keys
rpm -Va 2>/dev/null | grep -v '^......G' | head -40   # RPM-based systems
debsums -c 2>/dev/null | head -40                      # Debian-based systems

Over 2 million cPanel instances are internet-accessible. If auto-updates were disabled, those servers are still unpatched.

References: cPanel official advisory · watchTowr full disclosure · Rapid7 ETR · NVD CVE-2026-41940

-Eric

Thwarting the Terrapin SSH Attack (Mitigation)

by

The Terrapin Attack is the biggest SSH vulnerability that we have seen in decades.  Terrapin splices TCP sequence numbers to truncate SSH extension negotiation. While this is a concern, effective exploitation of this vulnerability is very difficult, and mitigation is very easy! The paper notes that AES-GCM is not vulnerable to the attack:

AES-GCM (RFC5647) is not affected by Terrapin as it does not use the SSH sequence numbers. Instead, AES-GCM uses the IV obtained from key derivation as its nonce, incrementing it after sending a binary packet. In a healthy connection, this results in the nonce being at a fixed offset from the sequence number.

The original Encrypt-and-MAC paradigma from RFC4253 protects the integrity of the plaintext, thus thwarting our attack, which yields one pseudorandom block during decryption.

This means you can simply use the AES-GCM cipher in SSL communication by configuring your hosts to default to that protocol. The AES-GCM cipher has been supported in SSH since version 6.2 so pretty much all supported distributions going back to at least 2014 have an easy mitigation.

Mitigating on the server

Newer Servers that are using `update-crypto-policies` (RHEL, Alma, Rocky, Oracle, newer Ubuntu and Debian)

Newer operating systems that provide the command update-crypto-policies, create a new policy file and activate it.  You can modify `DEFAULT` to something different if you are using a different policy, but “DEFAULT” works for most systems.

# cat /etc/crypto-policies/policies/modules/TERRAPIN.pmod
cipher@ssh = -CHACHA20*
ssh_etm = 0

# update-crypto-policies --set DEFAULT:TERRAPIN
Setting system policy to DEFAULT:TERRAPIN
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Older Servers are not using `update-crypto-policies`

Simply add this to the bottom of /etc/ssh/sshd_config:

Match All
Ciphers aes256-gcm@openssh.com

Note that Match all is added in case you have other match blocks. Of course, if you prefer, you can exclude the Match all line and insert the cipher above any match blocks so that it is a global option.

Forcing aes256-gcm is a bit of a hammer, it certainly works but may be more than you need.  Ultimately only Chacha20 and ETM-based MACs need to be disabled, so modify this as you see fit.

Testing Server Mitigation

The Terrapin research team has published a scanning/test tool.  There is GitHub page to compile it yourself, or pre-compiled binaries for the most common OS’s are available on the releases page.  The result should look something like this.  “Strict key exchange support” is unnecessary if the vulnerable ciphers are disabled.  As you can see, it says “NOT VULNERABLE” in green:

Output of a successful terrapin mitigation

Mitigating on the client

This can be done per user or system-wide.  To configure it for all users on a system, add this to the bottom of /etc/ssh/ssh_config:

Ciphers aes256-gcm@openssh.com

To configure it for a single user, add this to the top of the SSH configuration in your home directory (~/.ssh/config)

Ciphers aes256-gcm@openssh.com

Mitigating Windows SSH Clients

Unfortunately, the following Windows packages do not support AES-GCM and cannot be mitigated in this way:

If you use any of these then it would be a good idea to switch to an SSH client that supports AES-GCM.

Windows clients that support AES-GCM

Here are a few Windows clients that do support AES-GCM, in alphabetical order, by second letter:

The Fine Print

The examples above are one (very simple) way of dealing with this.  Ultimately you need to disable the ETM and ChaCha20 ciphers.  You can see what is configured in ssh as follows:

]$ ssh -Q mac|grep etm
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com
]$ ssh -Q cipher|grep -i cha
chacha20-poly1305@openssh.com

-Eric

How to reset your root password!

by

From time to time I am asked how to set reset the root password on a Linux server when you get locked out. Obvious for security reasons you can’t to do this remotely, but it is pretty easy to do if you have physical access.

First, reboot the system and interrupt the grub bootloader that looks like this by pressing ‘e’. In this example we are booting from CentOS, but it works for pretty much any modern Linux distribution (SuSE, Debian, Ubuntu, etc), because they all use grub:

grub bootloader interface

The when you press ‘e’ it will display a edit screen like this.  If you are prompted for a password when you press ‘e’ then your system administrator has disabled editing the bootloader configuration.   It is still possible to reset the root password if your bootloader his password it, but you will need to boot off of a rescue disk to do it.

grub edit menu

Arrow down to the first section/line that starts with ‘linux16’ or ‘linuxefi’ or ‘linux’. it usually looks something like this (yes, it is a big long single line):

linux16 /vmlinuz-3.10.0-1127.19.1.el7.x86_64 root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=auto vconsole.keymap=us biosdevname=0 net.ifnames=0 rd.auto=1 LANG=en_US.UTF-8

Add this to the end of that line; this is a temporary change to the bootloader that will exist only for this reboot:

init=/bin/bash

It should look something like this:

linux16 ... init=/bin/bash

Then press control-x to boot and eventually it will give you a bash prompt. When it does, run the following commands:

# mount -o remount,rw /
# passwd root
<change the password>
# mount -o remount,ro /
# echo b > /proc/sysrq-trigger

The last line will reboot the system. That should do it! Now you should be able to log in with your new root password.

-Eric

Docker or KVM: Which is Right for You?

by

Over the years there have been many different technologies to isolate workloads. Isolation is important for security because if one workload is compromised, and they are not isolated, then others can be affected. In today’s ecosystem, there are two predominant forms of workload isolation: containers and virtual machines.

Containers

Containers are similar to chroot jail in that all of the programs running within the container are executed in a way that they believe they have their own root file system. Linux namespaces allow the container to have its own process ID space, so `init` can be process ID 1, whereas, with chroot jails, the namespace was shared, so processes in the jail could not have a process ID of 1 since the host OS `init` process was already using process ID 1.

Containers share the same kernel and they do not have direct access to hardware resources.

 

Virtual Machines

Virtual machines are an emulated hardware environment provided by KVM. They boot their own kernel, have their own disks and attach network devices. If a user has full control over

visualization: App->OS->Virtualization stack

a virtual machine, then they can install any operating system they wish. Because the hardware is virtualized and running a separate kernel, virtual machines provide greater isolation than containers since they do not share the same kernel. The isolation is provided by hardware optimizations implemented in silicon by CPU manufacturers. This makes

it more difficult to escape a virtual machine environment than a container environment. You might ask: But what about branch prediction attacks, like Spectre?

In this case, branch prediction attacks equally affect containers and virtual machines so we can exclude that as a consideration for choosing containers or virtual machines.

Root File System

In practice, the operating systems running within these isolation technologies both operate from their own root file systems. Traditionally this was a complete distribution installation, however, that has changed in a way that hinders security and increases the difficulty of systems administration. There is a trend of “turn-key” operating system deployments, especially in Docker. If you want a particular application, let’s say, a web server running Word Press, then you simply run a few short commands and your Word Press server is up and running. This makes it easy to install for the novice user, but there is no guarantee that the Docker environment is up to date.

Further compounding container deployment security is the fact that some containers do not have a complete root file system and administrators cannot log in at all. Some would say this is good for security, but this type of monolithic container is still subject to the increasing likelihood of new attack vectors against an aging codebase. If a vulnerability does come along, then the monolithic container can become compromised. Since it can be difficult to log into this kind of container, it is harder to inspect what is happening from within the environment– and even if you can log in, the installation is so minimal that the toolset for inspecting the problem is not available, and the deployment may be so old that even if the container includes a package manager like Yum or APT, the distribution repositories may have been archived and are no longer available without additional effort.

Container intrusions can often be inspected from the outside using a privileged installation with configurable tooling, but the security issues and increased difficulty of maintenance are a counterindication for today’s containerized counter culture.

Our recommendation is always to install a long-term support release of a well known distribution in a virtual machine instead of a container. As a full virtual machine, not only do you get increased isolation, vendor updates, and a better security life cycle, but you also get increased management tooling such as live migration, full block device disks that can be cloned and mounted on other systems or snapshotted with easy rollback.

If you must use containers for your environment, then please use a normal OS distribution, configure security updates and email notifications and centralized logging. This will go a long way to making the system maintainable in the future and save you support costs.

If you are interested in learning more, then call us for a free consultation, so we can help work out what is best for your organization.

-Eric

Fixed Versions: Linux SACK Attack – Denial of Service

by

The recently published CVE-2019-11477 and CVE-2019-11478 attacks enable an attacker with access to a TCP port on your server (most everyone, including those with web or mail servers) to either:

  1. Slow it down severely
  2. Cause a kernel crash

See the NIST publication for more detail:

https://nvd.nist.gov/vuln/detail/CVE-2019-11477

Upstream distributions have released fixes for these as follows.  The 2019-11478 vulnerability is an issue as well, but the -11477 issue has higher impact so we are listing it here.  So far as I have seen, the fix for both is in the same package version so you only need to reference the -11477 articles:

Mitigation

You can mitigate this attack with iptables. If you are using fwtree, our latest release for el6 and el7 includes the mitigation (version 1.0.1-70 or newer). Of course it is best to update your kernel, but this provides a quick fix without rebooting:

# [ -d /etc/fwtree.d ] && yum install -y fwtree && systemctl reload fwtree && iptables-save | grep MITIGATIONS

You can also do it directly with iptables:

# iptables -I INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP
# ip6tables -I INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP

You can also disable TCP selective acks in sysctl:

# Add this to /etc/sysctl.conf
net.ipv4.tcp_sack=0

Red Hat / CentOS / Scientific Linux

Vendor security article: https://access.redhat.com/security/cve/cve-2019-11477

Fixed Versions

  • el5: not vulnerable (and EOL, so upgrade already!)
  • el6: kernel-2.6.32-754.15.3.el6
  • el7:  kernel-3.10.0-957.21.3.el7

Ubuntu

Vendor security article: https://usn.ubuntu.com/4017-1/

Fixed Versions

  • Ubuntu 19.04
    • 5.0.0.1008.8
  • Ubuntu 18.10
    • 4.18.0.22.23
  • Ubuntu 18.04 LTS
    • 4.15.0-52.56
  • Ubuntu 16.04 LTS
    • 4.15.0-52.56~16.04.1
    • 4.4.0-151.178

Debian

Vendor security article: https://security-tracker.debian.org/tracker/CVE-2019-11477

Fixed Versions

  • jessie
    • 3.16.68-2
    • 4.9.168-1+deb9u3~deb8u1
  • stretch
    • 4.9.168-1+deb9u3
  • sid
    • 4.19.37-4

SuSE

Vendor security article: https://www.suse.com/security/cve/CVE-2019-11477/

Fixed Versions

For SuSE, there are too many minor version releases to list them all here. To generalize, if you are running a newer kernel than these then you are probably okay, but double-check the vendor security article for your specific release and use case:

  • Pre SLES-15:
    • 3.12.61-52.154.1
    • 4.4.121-92.114.1
    • 4.4.180-94.97.1
    • 4.12.14-95.19.1
  • SLES 15
    • 4.12.14-150.22.1
  • Leap 15
    • 4.12.14-lp150.12.64.1

Vanilla Upstream Kernel (kernel.org)

Security patch: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=3b4929f65b0d8249f19a50245cd88ed1a2f78cff

Fixed Versions

  • 5.1.11
  • 4.19.52
  • 4.14.122
  • 4.9.182
  • 4.4.182
  • 3.16.69

Redirect Directory Trailing Slash (/) with Restricted Access

by

Securing Apache and Maintaining Usability

First, you should always avoid .htaccess and use it as a last resort. Still, this example holds whether or not you are using .htaccess.

Let’s say you have a directory you wish to secure so that only the index and some file (test.txt) is available. Other other content in the directory should be denied. For example:

These links should load:

  • www.example.com/foo
  • www.example.com/foo/
  • www.example.com/foo/test.txt

In addition, the link without the trailing / should redirect to the link with the trailing / (from /foo to /foo/) for ease of access for your users.

These links should give a 403:

  • www.example.com/foo/bar
  • www.example.com/foo/letmein.txt

To accomplish this, you might write a .htaccess as follows:

Apache 2.2

Order allow,deny
<Files ~ ^$|^index.html$|^test.txt$>
     Order deny,allow
</Files>

Apache 2.4

Require all denied
<Files ~ ^$|^index.html$|^test.txt$>
     Require all granted
</Files>

However, you will run into a problem: The link without a trailing / will not work (www.example.com/foo) because permissions are evaluated before the mod_dir module’s DirectorySlash functionality evaluates whether or not this is a directory. While not intuitive, we also must add the directory as a file name to be allowed as follows:

Apache 2.2

Order allow,deny
<Files ~ ^foo$|^$|^index.html$|^test.txt$>
     Order deny,allow
</Files>

Apache 2.4

Require all denied
<Files ~ ^foo$|^$|^index.html$|^test.txt$>
     Require all granted
</Files>

Hopefully this will help anyone else dealing with a similar issue because it took us a lot of troubleshooting to pin this down. Here are some search terms you might try to find this post:

  • Apache 403 does not add trailing /
  • Apache does not add trailing slash
  • .htaccess deny all breaks trailing directory slash
  • .htaccess Require all denied breaks trailing directory slash

-Eric

 

Check Authorize.net TLS 1.2 Support: tlsv1 alert protocol version

by

TLS v1.0 and v1.1 to be Disabled on February 28th, 2018

As you may be aware, Authorize.net is disabling TLS v1.0 and v1.1 at the end of this month.  More information about the disablement schedule is available here.

You may begin to see errors like the following if you have not already updated your system:

error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

We can help you solve this issue as well as provide security hardening or PCI compliance service for your server. Please call or email if we may be of service!

Checking for TLS v1.2 Support

Most modern Linux releases support TLS v1.2, however, it would be best to check to avoid a surprise. These tests should work on most any Linux version including SUSE, Red Hat, CentOS, Debian, Ubuntu, and many others.

PHP

To check your server, you can use this simple PHP script. Make sure you are running this PHP code from the same PHP executable that runs your website. For example, you might have PHP compiled from source and also have it installed as a package. In some cases, one will work and the other will not:

<?php
$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, 'https://apitest.authorize.net');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

if (($response = curl_exec($ch)) === false) {
 $error = curl_error($ch);
 print "$error\n";
}
else {
 $httpcode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
 print "TLS OK: " . strlen($response) . " bytes received ($httpcode).\n";
}

curl_close($ch);
?>

Perl

As above, make sure that you are using the same Perl interpreter that your production site is using or you can end up with a false positive/false negative test. If you get output saying “403 – Forbidden: Access is denied” then it is working because TLS connected successfully.

# perl -MLWP::UserAgent -e 'print LWP::UserAgent->new->get("https://apitest.authorize.net")->decoded_content'
Can't connect to apitest.authorize.net:443

LWP::Protocol::https::Socket: SSL connect attempt failed with unknown errorerror:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version at /usr/lib/perl5/vendor_perl/5.10.0/LWP/Protocol/http.pm line 57.

OpenSSL/Generic

To check from the command line without PHP, you can use the following which shows a failed TLS negotiation:

# openssl s_client -connect apitest.authorize.net:443
CONNECTED(00000003)
30371:error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version:s23_clnt.c:605

Other Languages

If you use any language, we can help verify that your application is set up to work correctly.  Just let us know and we can work with you directly.  I hope this post helps, please comment below!

-Eric

Meltdown BUG: What about KVM/Xen/Docker/OpenVZ/LXC/PV-Xen/HyperV?

by

Different Variants: Meltdown and Spectre

This article discusses only Meltdown and its affect on hypervisor environments since it is the easiest to implement.  Note that Spectre is capable leaking hypervisor memory from all hypervisors running on affected processors (Intel and possibly AMD, ARM) but it is both more difficult to exploit and to mitigate.  Please read on to understand how Meltdown affects your virtualization stack:

How Meltdown Affects Virtualized Environments

Every hosting provider held their breath over the past week wondering if the as-of-yet undisclosed Intel hardware bug now released as “Meltdown” would affect their visualization stack. They all want to know: is this a hypervisor escalation!?  Here in this post we use the word “affected” meaning guest-to-hypervisor memory read access.

The Meltdown bug enables reading memory from address space represented by the same pagetable—anyone using virtual page tables is unaffected between virtual tables.  That is, Guest-to-Host pagetables are unaffected, only Guest-to-Guest or Host-to-Host, and of course Host-to-Guest since the host can already access the guest pages.

For a hosting provider this means different customer VMs on the same fully-virtualized hypervisor cannot access each others’ data—but—different users on the same guest instance can access each others’ data.  This latter part holds true for non-virtualized hardware as well: users under the same OS kernel can access each others’ data.  Thus, containers are affected!

Which Technologies Are Affected?

Fully virtualized technologies are not affected in the sense that guests cannot access host (hypervisor) memory.  However, an unprivileged guest process can still access privileged (and other unprivileged) guest process memory pages.  Container-based technologies are affected by Meltdown across container boundaries.

Affected Virtualization Technologies

Anything container based: neighbor containers can read other neighbor containers process memory.

  • Docker
  • LXC
  • OpenVZ
  • UML
  • Paravirtual Xen
  • Chroot Jails

Unaffected Virtualization Technologies

Any fully virtualized technology is unaffected.

  • KVM
  • Xen HVM
  • HyperV
  • VirtualBox (if using VT)

Solutions

  1. Update your distribution kernel if your OS distribution has released an update for CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754. See this post for updated distribution kernel versions that address these CVEs: https://www.linuxglobal.com/spectre-meltdown-security-updates-distribution/
  2. If you cannot do #1, your best option is to install Linux 4.15-rc6 or one of the supported vanilla kernel patches in the link above.  On all systems.  Yes, 4.15-rc6 is a release candidate, but this kernel is receiving wide spread testing because of this bug.
  3. If this is not an option and you mostly trust the code running inside of the container, then you could run your container instances under KVM to isolate them from eachother to protect your guests and privileged container.
  4. If running Xen-PV, switch everything to Xen-HVM and hope for the best.  Many operating systems will boot in either environment unless your guest kernel was built specific to Xen PV—but there could be driver issues between the two.
  5. If you do not trust your users on a single host, then your best option is #1 above.

Remember, the only real fix is to install an updated kernel on all servers, physical or virtual.  Solutions 3and 4 only mitigate the problem since the guest is still vulnerable to interprocess memory reads.

Help!

We can help!  Just give us a call or send an email so we can make a plan and get you running secure, once again!

-Eric

 

 

 

Protect Your Server from Ransomware

by

Protect Your Business Servers from Ransomware!

The fundamental problem exploited by Ransomware is a lack of backup. At Linux Global, we protect our customers from Ransomware in a number of ways:

  • Frequent offsite backups
  • Realtime data replication for databases
  • Frequent server snapshots with offsite image backup

With these systems in place your data is safe, even in the event of your files being encrypted by Ransomware.

We can even protect your Windows server by using Linux to virtualize your infrastructure and maintain hourly snapshots with frequent offsite backups.

Call today and Ransomware-proof your infrastructure!