Two serious security flaws were announced within a few weeks of each other, in October and November. One sits in PHP, the language that runs most websites, including WordPress. The other sits in OpenSSH, the tool most administrators use to log in to servers. Neither is a reason to panic, but both are a reason to check what you run and who looks after it.
The PHP flaw: PHP2Shell
On 21 October, the PHP project released fixes for two critical flaws, tracked as CVE-2026-109618 and CVE-2026-109619. Both scored 9.2 out of 10. In plain terms, a stranger on the internet could send a specially built request to a vulnerable web server and, under the right conditions, get it to run commands of their choosing. No password and no login are needed. Amazon reported attack attempts as early as 17 October, days before the public announcement, and security firms have since reported attacks and wide scanning of the internet.
The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older branches such as 7.4, 8.0 and 8.1 got backported fixes, but they no longer receive regular support, so the safer move is to upgrade to a current release.
Why it matters if you run a WordPress site
WordPress, WooCommerce and most small business sites run on PHP. The flaw is in PHP itself, not in WordPress or any plugin, so a fully updated WordPress site can still be exposed if the server underneath it has not been updated. On shared hosting your provider usually controls this. On a VPS or your own server, it is your job or your IT partner’s.
What to do about it
Ask your host which PHP version your site runs and whether it includes the October fixes. If you manage the server yourself, update PHP to a fixed release and restart the web service so the new version actually takes over. If you cannot update straight away, the PHP project and security researchers have published temporary mitigations, such as limiting request sizes at a reverse proxy, but these only reduce the risk until you patch. Also look at anything old that nobody remembers: forgotten test sites, old portals and abandoned servers are exactly what attackers scan for.
On most shared hosting in Uganda and abroad, you can see and change the PHP version yourself in cPanel, under the PHP version or MultiPHP settings. If you cannot find it, send your host a message today and ask. A short, polite email or WhatsApp message is enough, and it is much cheaper than cleaning up a hacked site later.
The SSH flaw: SSHole
On 6 November, the OpenSSH team released version 10.6p2 to fix CVE-2026-123158, nicknamed SSHole, with a severity score of 8.1. A bug let an attacker log in to certain accounts using any password between 257 and 1,024 characters long. It was exploited fast: the first attempts were seen less than nine hours after the flaw was published, and one security firm gained root access to a test server it had set up as bait.
The scope is narrower than the headlines suggest. It affects OpenSSH servers on Linux systems that use the musl C library with PAM switched off, which includes Alpine Linux and some router and embedded builds such as OpenWrt. Mainstream distributions such as Ubuntu, Debian and Red Hat use a different library and are not affected, nor are servers that check passwords through PAM. To be exploitable, the server must also allow password logins and have an account whose password is disabled, such as root or a key-only user.
What to do about SSHole
If you run Alpine Linux, including in containers, or any router or appliance that uses OpenSSH, update to OpenSSH 10.6p2 or your vendor’s patched package and restart the SSH service. If you cannot patch yet, turn off password logins so that only SSH keys work, and restart the service. Then check your logs for password logins on accounts that should never accept one. If you cannot rule out an unauthorised login, treat the machine as compromised: rotate keys and passwords, review users and authorised keys, and consider rebuilding it.
The lesson behind both
Both flaws were exploited within days, sometimes hours. The window between a fix being published and attackers using the gap keeps shrinking, so an update plan that runs once a year is no longer enough. A few habits cover most of the risk: know every server and site you run, keep PHP and server software on supported versions, use key-based SSH logins and turn off password logins where you can, keep tested backups off the server, and have one person who owns patching.
If you are not sure which PHP version your site runs, or whether your servers need attention, send us the details and we will check, and tell you plainly what needs fixing and what does not.
