Is Your Business Website Safe? What to Do This Week

If you woke up on Thursday and found the Australian Signals Directorate's own website offline, you saw the start of this. Overnight into 22 October 2026, ASD, the Australian Bureau of Statistics and Jobs and Skills Australia all went down for a while. A spokesperson for the Minister for Cyber Security said some sites were unavailable "as work is undertaken to mitigate risks arising from this vulnerability".

The vulnerability is a pair of flaws in PHP itself, now nicknamed PHP2Shell. PHP runs a large share of the web, including most WordPress, Joomla, Drupal, Magento and Laravel sites, and a lot of older custom-built business systems. In the same week, GitLab shipped a fix for a bug rated 10.0 out of 10, the highest severity there is.

This article is for business owners and managers, not just IT staff. It covers what happened, what to patch, how to check the patch actually took, and the harder question of whether your PHP system is worth keeping at all.

---

What PHP2Shell is, in plain English

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on the CVSS v4.0 scale.

Put simply, an attacker can send a specially crafted web request to a vulnerable server and get it to run their code. No login is needed. According to the PHP advisory, on the most exposed setup (Apache with mod_php) a working exploit needs a single request, and it fires before any of your website's own code runs. That last point matters: it does not help that your WordPress plugins are up to date or that your custom app has good security. The hole is underneath all of that.

The PHP advisory says every PHP installation that serves web requests is affected, including:

• PHP-FPM (the common setup on modern Linux hosting)
• Apache mod_php (rated highest risk)
• php-cgi
• FrankenPHP
• LiteSpeed

Hosting control panels are caught up too. Plesk says every PHP version it ships is affected.

Is anyone exploiting it yet?

The answer depends on whom you ask and when. The Australian Cyber Security Centre said it was not aware of active exploitation when it issued its alert. Security firm watchTowr reported exploitation in its honeypots from 21 October, and Qualys noted that Cloudflare had already seen attack traffic aimed at these flaws.

Two details make us treat this as urgent rather than routine. First, details leaked on social media the week of 19 October, before the planned release. Second, researchers at Wiz said AI tools did a lot of the heavy lifting in turning an old, awkward bug into a working exploit. In their words, "Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit." If AI made it easier for researchers, it made it easier for attackers too. The gap between a patch landing and attacks starting keeps getting shorter.

---

The GitLab flaws, and why they matter to non-developers

If your business or your developer runs its own GitLab server to store source code, this part is for you. If you only use GitLab.com, GitLab has already patched it for you.

GitLab released three critical fixes in October 2026:

Date	Flaw	Severity	Who needs to act
2 Oct	CVE-2026-90970, command execution through the Self-Hosted AI Gateway	9.9	Self-hosted AI Gateway users
12 Oct	CVE-2026-97229, integer overflow in the CI/CD regex compiler	10.0	All self-managed CE and EE
21 Oct	CVE-2026-110264, integer overflow in the regex compiler, no login needed	10.0	All self-managed CE and EE, back to version 7.0

The 21 October fix is in GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. There is no workaround. Patching is the only fix.

The trap is this: if your team patched promptly after the 12 October release, you are still exposed. Those 12 October versions (19.4.2, 19.3.5, 19.2.8) are older than the 21 October fixes. Being diligent nine days ago does not cover you today.

Why should an owner care about a code server? Because it usually holds more than code. Deployment keys, database passwords, cloud credentials and customer configuration often end up in a GitLab instance. Someone who takes over that server can often reach everything it deploys to.

---

What to do this week

Here is the order we would work in for a typical small or mid-sized business.

1. Find every place PHP runs

This sounds obvious. In practice it is where things get missed. Look beyond the main website:

• The main website and any marketing microsites
• Staging and test copies (often forgotten, often unpatched, often public)
• Old booking, quoting or intranet systems built years ago
• Hosting control panels such as Plesk and cPanel
• Developer laptops and build servers
• Anything a previous agency set up and nobody has looked at since

The ACSC's advice is the same: identify PHP in your environment, apply updates, and monitor for suspicious activity.

2. Patch to a fixed version, or confirm your host has

If you are on shared or managed hosting, ask your host in writing whether your PHP has been updated for CVE-2026-109618 and CVE-2026-109619, and when. Do not accept "we keep things up to date" as an answer. Ask for the version or the package changelog.

If you run your own server, update PHP through your operating system's packages or to the fixed upstream release for your branch.

3. Check the patch actually took effect

Two mistakes are common, and both leave you exposed while you think you are safe:

• Restarting the wrong service. On Apache with mod_php, PHP lives inside Apache. Restarting PHP-FPM does nothing for it. AlmaLinux notes that mod_php hosts need Apache itself restarted.
• Trusting the version number. Linux distributions such as Ubuntu backport the fix into the version they already ship, so php -v may barely change. Check the package changelog for the CVE numbers instead.

4. Do not rely on configuration tweaks

The PHP advisory lists some settings that reduce the risk, such as changing memory limits and upload progress options. It also states clearly that they do not make a server safe. Treat them as a stopgap for the hours before you can patch, not as the fix.

5. Look for signs someone got in first

If a server was exposed during the window before you patched, check for new admin users, unfamiliar files in upload folders, changed scheduled tasks and unusual outbound connections. If you find anything, assume credentials stored on that server are compromised and rotate them.

6. Patch GitLab to the 21 October release

If you self-host GitLab, update to the fixed version for your release line, then review the threat detections GitLab published for signs of attempted exploitation.

---

The bigger problem: PHP that cannot be patched

Here is the part many owners will not want to hear. The PHP project only fixes branches 8.2 to 8.5. PHP 8.1 and older get nothing from php.net. And PHP 8.2 itself reaches end of life on 31 December 2026, ten weeks from now.

If your site or system runs on PHP 7.x or 8.0 or 8.1, you have three real options.

Option	What it means	Good when	Watch out for
Backported patches	A paid long-term support vendor, or a source backport, fixes the old version	You need weeks or months to plan a proper upgrade	It buys time. The next flaw needs the same treatment, and plugins stop supporting old PHP
Upgrade PHP	Move the existing code to PHP 8.4 or 8.5 and fix what breaks	The application is sound and still fits how you work	Old code and plugins can break in ways that take real testing to find
Replace the system	Rebuild on a modern, supported platform	The app is fragile, poorly documented or no longer fits the business	Costs more up front. Needs a careful data migration

The PHP security team did publish minimal source backports for PHP 7.4, 8.0 and 8.1, and vendors such as TuxCare are shipping fixed builds for branches upstream has left behind. That is useful for emergencies. It is not a plan.

---

Should you move away from PHP?

I run a business that builds mostly on Microsoft .NET, so you might expect me to say yes. My honest answer is: it depends on what the PHP is doing.

PHP itself is not the problem. A current, supported PHP version, patched promptly, on well-maintained hosting, is a perfectly reasonable platform. A WordPress site on PHP 8.4 with a sensible plugin list and someone responsible for updates is fine. Rewriting it out of fear would be money badly spent.

Unmaintained PHP is the problem. The risk sits with systems where nobody owns the patching: the custom quoting app built in 2014 by a developer who has since moved on, the site stuck on PHP 7.4 because one plugin breaks on anything newer, the staging copy nobody remembers.

Here is how I would decide:

• Brochure website, a few pages, rarely changes. Consider a static site. With no server-side code running, flaws like PHP2Shell have nothing to attack, and hosting costs drop. Our Small Business Website Package starts from $999 + GST and runs on Azure, with hosting included for 36 months. It excludes domain registration, logo and photography, copywriting and anything dynamic such as logins, bookings or e-commerce.
• WordPress or similar, actively used, on supported PHP. Keep it. Put patching on a schedule, cut plugins you do not need, and make sure someone is named as responsible.
• Custom PHP business system on PHP 8.1 or older. Get it upgraded or assessed now. If it is small and the code is reasonable, a PHP upgrade is usually the cheapest path. If it is critical, fragile and undocumented, this is the moment to plan a replacement, because you will be doing this again with the next flaw.
• Business-critical system with sensitive client data. Have it assessed before you choose. A replacement on .NET and Azure gives you Microsoft's long-term support cycles and managed patching, but a replacement is a project, and a rushed one creates its own risks.

What I would not do is rip out a working PHP system in a panic this week. Patch first. Decide calmly next month.

---

How we can help

At Hrishi Digital Solutions we work on both sides of this: keeping older systems alive safely, and moving them on when it is time.

• Emergency patching and verification. We find every PHP and GitLab instance you run, patch them, confirm the fix took effect, and check for signs of compromise. If you are on shared hosting, we deal with your host for you.
• PHP upgrades. We move applications off end-of-life PHP onto 8.4 or 8.5, test them, and fix what breaks. Our legacy system rescue service covers inherited WordPress and custom systems nobody else wants to touch.
• Modernisation assessment. For systems where patching is no longer enough, our legacy modernisation assessment compares upgrade, replatform and rebuild options with real costs, so you can decide on facts. When a rebuild makes sense, our system modernisation service handles the migration.
• Ongoing patching. A scheduled maintenance arrangement so the next critical advisory is a routine job, not a scramble.

As an NT Government approved supplier we work to public sector security expectations, and we bring the same discipline to small business work. Every engagement is fixed scope and priced up front, so you know the cost before we start.

---

Common questions

Is my WordPress site affected by PHP2Shell?

Almost certainly, unless your host has already updated PHP. The flaw is in PHP itself, not WordPress, so keeping WordPress and plugins updated does not protect you. Ask your host which PHP version you are on and whether it includes the 21 October fixes.

My host says they manage everything. Do I need to do anything?

Ask for confirmation in writing, including the PHP version or patch date. Most good hosts patched quickly. Some cheaper or overseas hosts are slower, and older plans may be locked to an unsupported PHP version.

We use GitLab.com, not our own server. Are we exposed?

No. GitLab has already patched GitLab.com and GitLab Dedicated. Only self-managed installations need updating.

Is PHP still safe to use for new projects?

Yes, on a supported version with someone responsible for patching. Choose a platform for new work based on your team's skills, hosting and the system's lifespan, not on one week's headlines.

What does it cost to upgrade an old PHP system?

It depends on the size of the code, how many plugins or libraries need replacing, and how much testing the system needs. A small site can be a day or two. A large custom system can be a project. We assess first and quote a fixed price before any work starts.

---

Key takeaways

• PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets attackers run code on PHP servers without logging in. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Check the patch took effect: restart Apache on mod_php hosts, and check package changelogs rather than version numbers.
• Self-managed GitLab needs the 21 October release. The 12 October patch is not enough.
• PHP 8.1 and older get no upstream fixes, and PHP 8.2 ends on 31 December 2026. Plan upgrades now.
• PHP is not the enemy. Unmaintained PHP is. Patch first, then decide whether to upgrade or replace.

---

Not sure where you stand?

Book a free 30-minute call and tell us what you run. We will tell you whether you are exposed, what needs doing first, and whether your system is worth upgrading or due for replacement. If you only need the patch applied and verified, we will say so.