
PHP – It’s Scary!
An older application may depend on a PHP version that is no longer supported. An upgrade might affect database connections, integrations, libraries or business-critical workflows. Documentation may be incomplete, and the original developers may have moved on.
Critical Vulnerabilities, Legacy Code and the Cost of Looking Away
The final post in STEP Software’s October Cybersecurity Awareness Month series
Nothing says Halloween quite like discovering something dangerous has been lurking in your systems for years.
Unfortunately, this year’s real-world cybersecurity horror story is not fiction. It is PHP, one of the internet’s most widely used programming languages, and a reminder that even familiar, dependable technology can harbour serious vulnerabilities.
On October 21, 2026, the PHP development team released security updates addressing two critical vulnerabilities that could allow attackers to execute code remotely without authentication. Both received a CVSS v4.0 severity score of 9.2. The flaws affect PHP installations serving web requests, with the PHP team identifying particular risk in certain server configurations.
The official PHP security announcement urges users to update immediately. The Canadian Centre for Cyber Security’s advisory also directs administrators to review the issue and apply necessary updates.
And yes, government websites in Europe were reportedly taken offline as operators responded to the threat, according to Reuters.
That is a rather unpleasant Halloween trick.
The Vulnerability Lurking Beneath the Surface
PHP powers websites, content management systems and business applications across the internet. It is used in platforms including WordPress, Drupal, Joomla and Magento.
The problem is not that PHP is inherently insecure. Like any software, it needs maintenance, security updates and responsible configuration.
The latest incident involves two serious flaws in PHP’s internal memory and request-handling processes. According to the official PHP advisory, one involves memory corruption during an out-of-memory condition, while the other involves stale internal state that can persist after memory has been freed.
In practical terms, these vulnerabilities could allow an attacker to execute code on an affected server without first logging in.
That could put application data, connected systems and business operations at risk.
The wider lesson is important: a vulnerability in a shared software component can become a business problem for every organization relying on it.
You might have a modern website, a well-designed application and sensible security policies. But if the underlying runtime is vulnerable, those other precautions may not be enough.
Your PHP Application Might Be Older Than Your Security Plan
Here is where the Halloween metaphor gets uncomfortably realistic.
Many organizations do not have a complete inventory of the software running their business. They know about their main website, their customer portal and the applications their IT team actively maintains.
But what about:
- The forgotten application-built years ago?
- The internal reporting tool?
- The customer-facing portal maintained by a third party?
- The custom application that still works beautifully, provided nobody touches the code?
These systems can become cybersecurity blind spots.
Common warning signs include:
- Unsupported PHP versions: Older releases may no longer receive security fixes from the PHP project.
- Unmaintained dependencies: Libraries and frameworks can introduce vulnerabilities even when the application itself has not changed.
- Incomplete documentation: Your team may not know which components are installed, who owns them or how to update them safely.
- Unclear vendor responsibilities: Everyone assumes someone else is monitoring vulnerabilities and applying patches.
- Limited testing capacity: Teams postpone updates because they cannot confidently predict what an upgrade might break.
PHP’s official guidance notes that PHP 8.1 and older no longer receive updates from the project, although some distributions and long-term support vendors may provide backported fixes. Organizations must verify their actual support arrangements rather than assume an older installation is protected.
The official PHP security release information is the place to start.
What Should Businesses Do Right Now?
If your organization uses PHP, do not wait for the next routine maintenance window to find out whether you are affected.
Start with these five steps:
- Identify your exposure. Inventory PHP applications, versions, hosting environments and dependencies. Include business-critical custom software and applications managed by external vendors.
- Confirm the fix. Review the PHP security announcement and your operating system or hosting provider’s security guidance. The PHP team lists fixed releases including PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Confirm the correct package and supported upgrade path for your environment.
- Prioritize internet-facing systems. Assess exposure, business criticality and the potential consequences of compromise. If immediate patching is not possible, follow authoritative security guidance on restricting access or temporarily isolating affected systems.
- Test and verify. Apply the update, restart the relevant services where required, and confirm that the installed runtime is patched. Test critical application workflows and review logs for suspicious activity.
- Review the wider application. Patching the runtime is essential, but it does not automatically resolve outdated dependencies, insecure application logic, excessive permissions or other weaknesses.

Do not assume that updating WordPress or another content management system automatically updates the PHP runtime underneath it. These are separate components, and responsibility for updating them depends on your hosting and deployment arrangements.
When the Fix Is More Complicated Than the Patch
For some organizations, updating PHP is straightforward. For others, it opens a rather large skeleton-filled closet.
An older application may depend on a PHP version that is no longer supported. An upgrade might affect database connections, integrations, libraries or business-critical workflows. Documentation may be incomplete, and the original developers may have moved on.
Simply applying an update without understanding those dependencies can introduce operational problems. Doing nothing leaves the organization exposed.
This is where STEP Software can help.
Our Legacy Software Division helps organizations stabilize, maintain and modernize existing applications. Our Advisory Division can help assess software risks, review code and establish practical remediation priorities.
Depending on the application, the next step may involve:
- A software audit to identify vulnerabilities, unsupported components and technical debt.
- Targeted remediation and testing to help make a PHP upgrade safer.
- Additional specialist capacity through staff augmentation when internal teams are already stretched.
- A longer-term modernization plan that reduces risk without automatically requiring a complete replacement.
Our approach is practical: understand the system, establish priorities and determine the safest route forward. Sometimes that means modernizing. Sometimes it means stabilizing a system that still delivers real business value.
Either way, the objective is to replace uncertainty with an actionable plan.
The Final Scare: Thinking the Job Is Done
This October, STEP Software has explored cybersecurity health checks, software supply chain risks and cybersecurity debt. The PHP vulnerabilities bring those themes together.
A critical flaw can emerge in software that organizations have trusted for years. A third-party dependency can become a serious exposure. An application nobody has reviewed recently can suddenly demand urgent attention.
Security is not a one-time project, and passing an audit last year does not guarantee protection today.
Organizations need an ongoing process for tracking software assets, monitoring advisories, maintaining dependencies, testing updates and assigning responsibility. Our article on the questions to ask your software vendor before signing is a useful place to strengthen that conversation.
For further guidance on protecting your organization, visit Canada’s Get Cyber Safe resources.
No Tricks. Just Better Software Security.
Halloween is a fine time for ghosts, ghouls and things that go bump in the night.
It is not a great time to discover that your business-critical application has been running vulnerable software for months.
If your organization uses PHP, check your exposure and act on the current security guidance. Then take a closer look at the legacy applications, dependencies and vendor arrangements that could create your next cybersecurity surprise.
Need help understanding the condition of your software or planning your next steps? Talk to STEP Software.
Because the scariest vulnerability is not always the one nobody has fixed.
Sometimes, it is the one nobody knew was there.


