On October 22, Armenian cybersecurity authorities warned of two critical vulnerabilities in PHP. The patches are available, but exploitation attempts were detected before the flaws became public. For businesses, the uncomfortable question is whether updating a website is enough when the technology underneath it remains vulnerable.
Everything Works. That's What Makes It Dangerous.
Imagine the owner of an online store in Yerevan starting an ordinary working day.
The website loads quickly. Customers are placing orders. Payments are going through. The WordPress dashboard shows no pending updates.
Everything appears to be in order.
But somewhere beneath the familiar interface, the server is running an outdated version of PHP.
The business owner doesn't know which version.
And until now, there has been little reason to ask.
That is precisely what makes the latest cybersecurity warning so relevant.
On October 21, 2026, the PHP development team released emergency patches for two critical vulnerabilities identified as CVE-2026-109618 and CVE-2026-109619.
One day later, Armenia's Information Systems Agency (ISAA), together with AM-CERT, issued a public warning.
The vulnerabilities, collectively known as PHP2Shell, can potentially allow an unauthenticated attacker to execute malicious code on affected servers.
Both carry a critical CVSS 4.0 severity score of 9.2.
And unlike vulnerabilities associated with a particular website plugin or application, these flaws affect PHP itself.
That distinction changes everything.
A website can be fully updated at the application level while the server underneath it remains vulnerable.
A functioning website is not necessarily a secure website.
And sometimes, the most dangerous weakness is the one nobody can see.
The Technology Nobody Talks About Until Something Goes Wrong
Most business owners recognise names such as WordPress, Drupal, Joomla or Magento.
Far fewer pay attention to the underlying technologies that make these platforms function.
PHP is a widely used server-side programming language. It processes requests, generates dynamic content and supports many of the operations behind modern websites and web applications.
When someone logs into a customer portal, submits a form or places an order, PHP may be responsible for a significant part of the work happening behind the scenes.
Think of a website as a restaurant.
The design is the dining room. The content is the menu. The shopping cart is the ordering system.
PHP is part of the kitchen.
You can redesign the restaurant, replace the menus and install a sophisticated ordering platform.
But if a critical problem exists in the kitchen, none of those improvements will necessarily fix it.
That is the challenge presented by PHP2Shell.
The vulnerability isn't limited to one WordPress theme or a particular extension.
It exists within the PHP runtime itself.
And because different applications depend on that runtime, the potential exposure reaches across a much wider range of digital services.
Corporate portals, online stores, educational platforms, content management systems and internal business applications may all require attention.
The question is not whether the website looks modern.
The question is whether its underlying environment is secure.
Two Vulnerabilities. One Serious Risk.
To understand the significance of PHP2Shell, we need to look briefly beneath the surface.
Both vulnerabilities involve how PHP manages memory while processing requests.
The first, CVE-2026-109618, concerns errors during out-of-memory handling.
Under certain conditions, PHP may interrupt an operation while internal request data has only been partially initialised.
When the system subsequently attempts to clean up the interrupted request, it may process invalid memory contents.
The second, CVE-2026-109619, involves stale internal state.
In specific circumstances, references to request-related information may remain after the memory holding that information has been released.
A later request handled by the same worker may then interact with that invalid state.
These are not ordinary application bugs.
They are memory-safety vulnerabilities in the environment responsible for executing PHP applications.
Successful exploitation can potentially allow an attacker to run arbitrary code within the affected process.
Depending on the server's configuration, access privileges and security controls, this could lead to data exposure, website manipulation, service disruption or further intrusion.
However, remote code execution does not automatically mean an attacker gains unrestricted control over an entire corporate network.
The actual consequences depend on the system's architecture and the permissions available to the compromised process.
The PHP security team has identified Apache configurations using mod_php as particularly exposed, including a demonstrated scenario in which exploitation can occur before the application itself begins executing.
Other PHP deployment models, including PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, must also be assessed and patched.
The technical details may differ. The need to act does not.
The Attacks Started Before the Public Warning
The timing of this incident makes it especially important.
The vulnerabilities were publicly disclosed on October 21.
But according to Amazon Threat Intelligence, an exploitation attempt had already been observed on October 17.
That was four days before the official disclosure.
The activity was detected through MadPot, Amazon's infrastructure for observing suspicious internet activity.
Researchers subsequently identified additional exploitation attempts.
This does not establish that a particular business was successfully compromised. Nor does it mean that every exposed PHP server has been attacked.
But it demonstrates a fundamental reality of modern cybersecurity.
The day a vulnerability becomes public is not always the day attackers first learn about it.
For businesses, this creates a difficult operational challenge.
Traditional maintenance schedules often assume that software updates can be reviewed, tested and installed during a convenient service window.
That approach may be entirely reasonable for routine changes.
It becomes much harder to justify when a critical vulnerability is already attracting exploitation attempts.
Security teams must then balance two risks: the operational impact of deploying an urgent patch and the potential consequences of leaving a vulnerable system exposed.
There is no universal answer to how much downtime a business should accept.
But there should be a clear process for making that decision.
And the process must exist before the emergency begins.
Why Armenia's Warning Matters
Armenia's digital economy increasingly depends on web-based services.
Companies use websites not merely to present information, but to conduct business.
Orders, payments, customer records, appointments, educational services and internal workflows are managed through interconnected digital platforms.
Many Armenian organisations rely on established international software products. Others maintain custom-built applications developed by local teams.
Some have internal IT departments. Others outsource most of their technology operations.
None of these models is inherently unsafe.
The challenge arises when responsibility for the underlying infrastructure becomes unclear.
A company may assume its web developer handles security updates.
The developer may believe the hosting provider is responsible.
The hosting provider may expect the customer to select and maintain the relevant PHP version.
Each party believes the task belongs to someone else.
And the vulnerable component remains untouched.
This is an illustrative risk, not evidence that the same situation is widespread among Armenian companies.
Yet it raises an important question for any business using external technology providers.
Who is specifically responsible for maintaining the software that runs your website?
Not the visual design.
Not the content.
Not just the application.
The actual server-side components.
If nobody can answer that question clearly, the organisation has a management problem as well as a technical one.
The PHP Versions Businesses Need to Check
On October 21, 2026, the PHP development team released security updates for its supported branches.
The first patched versions are:
| PHP Branch | Fixed Version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Earlier releases within these branches should be treated as vulnerable unless the relevant software vendor has confirmed that the necessary security fixes have been backported.
PHP 8.1 and older branches are no longer supported through the PHP project's regular security release process.
Some Linux distributions, hosting providers and commercial extended-support vendors offer patched builds of older versions.
In those environments, the version number alone may not tell the full story. The specific package, build date and vendor security advisory must be checked.
For example, Plesk has published patched builds for several older PHP branches while retaining their original version numbers.
Another detail deserves attention.
The October 22 ISAA/AM-CERT notice lists PHP 8.2.3 among its recommended versions. The official PHP release announcement identifies PHP 8.2.35 as the corrected fixed release.
Businesses should therefore follow the PHP project's release information and verified vendor advisories when selecting an update.
PHP 8.2 is also approaching the end of its official security-support period on December 31, 2026.
Installing version 8.2.35 addresses the two newly disclosed vulnerabilities, but organisations using this branch should already be planning their migration to a more recent supported release.
What If Your Company Doesn't Have an IT Department?
This is where the issue becomes particularly relevant to small and medium-sized businesses.
Not every Armenian company employs a system administrator.
A website may be maintained by a development agency, a freelancer or a hosting provider.
That does not mean the business owner must suddenly become an expert in PHP memory management.
But the owner should be able to request a clear, verifiable explanation of the website's security status.
The right questions are straightforward:
-
Which PHP version is actually serving our website?
-
Have CVE-2026-109618 and CVE-2026-109619 been fixed?
-
When was the update applied?
-
Were all relevant PHP processes restarted?
-
Have the available security logs been reviewed for suspicious activity?
-
Who is responsible for emergency security updates going forward?
An answer such as "everything is fine" is not particularly useful.
An answer such as "the production website runs PHP 8.3.36, the affected services were restarted, application functionality was tested, and the relevant logs were reviewed" is considerably more meaningful.
It describes work that can be verified.
And verification is what responsible technology management requires.
One technical detail is worth noting.
The command php -v typically reports the PHP version used by the command-line environment.
That may not be the same version actually processing requests through the web server.
A machine can run multiple PHP versions simultaneously.
Therefore, version verification must cover the production runtime, not simply whatever PHP executable is available in an administrator's terminal.
Updating Is Necessary. But It May Not Be Enough.
Suppose a company installs a patched PHP release today.
Is the incident over?
Not necessarily.
The patch prevents the known vulnerability from being exploited through the corrected code.
It does not automatically determine whether the server was compromised before the patch was installed.
This distinction is particularly important because exploitation attempts were observed before public disclosure.
For organisations with potentially exposed systems, security specialists should review relevant activity beginning at least on October 17, where logs are available, and extend the investigation if other evidence warrants it.
Depending on the environment, that review may include unusual HTTP requests, unexpected PHP processes, suspicious outbound connections, newly created executable files and unexplained changes to web directories.
None of these indicators, taken alone, necessarily proves a successful intrusion.
Security events require contextual analysis.
But if credible signs of compromise are discovered, the organisation should move beyond routine maintenance and follow its incident-response procedures.
That may involve isolating affected systems, preserving evidence, checking file integrity, reviewing access credentials and assessing whether information was exposed.
Patching closes a known vulnerability. It does not erase the consequences of a compromise that has already occurred.
Can a Web Application Firewall Protect You?
Businesses that already use Web Application Firewalls may reasonably ask whether their existing security products provide sufficient protection.
A WAF can inspect incoming HTTP traffic and potentially block suspicious requests associated with known exploitation techniques.
That can reduce exposure in some situations.
But PHP2Shell affects the runtime itself.
A WAF cannot guarantee that every possible exploitation method will be recognised or blocked.
There is also the possibility of traffic reaching the origin server without passing through the intended protection layer.
The PHP security team has explicitly stated that no available mitigation offers complete protection equivalent to installing the corrected software.
Temporary measures may be necessary when immediate patching is not possible.
These may include restricting internet access, reducing exposure to untrusted requests, disabling specific vulnerable functionality where appropriate and following the official PHP advisory.
But they should be treated as temporary risk-reduction measures.
Not as permanent alternatives to patching.
The same principle applies to other security technologies.
Endpoint detection, intrusion prevention and continuous monitoring can provide valuable additional protection.
They do not correct the underlying vulnerable PHP code.
One More Important Update on October 23
The PHP project issued an additional informational advisory on October 23 concerning session upload progress.
In an unusual configuration involving changes to PHP's session serialisation handler at runtime, the enabled upload-progress mechanism may introduce another remote-code-execution risk.
The PHP team recommends setting session.upload_progress.enabled=0 until the next regular bugfix release to protect against this specific scenario.
The issue is associated with CVE-2026-115560, for which a full advisory is expected with a subsequent release.
This does not mean that every PHP installation using file uploads is affected.
The problematic configuration requires particular combinations of application behaviour and PHP settings.
Administrators should review the official advisory, assess whether their application uses the relevant functionality and implement the appropriate changes.
It is another reminder that critical security developments rarely stop with the first public announcement.
The technical picture can evolve as researchers and software maintainers continue investigating.
Seven Actions Worth Taking Now
For organisations operating PHP-based services, the immediate priorities are practical.
1. Identify every PHP-powered system.
Include public websites, corporate portals, administrative interfaces, staging environments, containers and applications maintained by third parties.
2. Verify the actual runtime version.
Check the production PHP environment, installed vendor packages and relevant security advisories.
3. Apply confirmed security fixes.
Use patched releases or vendor-supported backports. Test application compatibility and restart the appropriate services so the corrected runtime is actually in use.
4. Prioritise externally exposed systems.
Websites handling customer accounts, personal data, payments or sensitive documents deserve particular attention.
5. Investigate suspicious activity.
Review available logs and system events for exploitation attempts and signs of compromise, especially around and after October 17.
6. Document exceptions and remaining risks.
If a system cannot be patched immediately, record why, what temporary controls have been applied, who owns the risk and when remediation will be completed.
7. Confirm completion at management level.
The final report should identify affected systems, remediation status, testing results and unresolved issues.
These actions are not limited to major corporations.
A small online store, a professional services firm or a local educational institution may have fewer systems to manage, but the consequences of a compromised website can still be serious.
The objective is not to create unnecessary bureaucracy.
It is to ensure that somebody knows what needs to be done and can demonstrate that it has been done.
The Bigger Problem Is Not PHP
PHP2Shell will eventually stop dominating cybersecurity headlines.
The vulnerabilities will be patched across more environments. Security vendors will update their guidance. Organisations will return to their usual operations.
But the lesson should remain.
Modern websites are built on layers of software that business leaders rarely see.
A content management system depends on a runtime.
The runtime depends on operating-system components and libraries.
The application depends on external services, databases and supporting infrastructure.
Every dependency introduces its own maintenance and security requirements.
Yet many businesses still think of their website as a single product.
Something that was developed, delivered and occasionally updated.
That model no longer adequately describes the technology on which digital services depend.
A website is not a finished object.
It is a continuously operating software environment.
And maintaining it means more than keeping the homepage attractive and the shopping cart functional.
It means understanding what runs underneath, who maintains it and how quickly critical weaknesses can be addressed.
The Question Every Business Owner Should Ask Today
The most striking part of PHP2Shell is not simply that two critical vulnerabilities were discovered.
Security vulnerabilities are an unavoidable reality of software development.
What makes this incident important is the gap it exposes between what businesses believe has been secured and what has actually been maintained.
A website can be running normally.
A security plugin can report no issues.
The application can be fully updated.
And the underlying PHP runtime can still require urgent attention.
The good news is that patches for the two primary vulnerabilities are available. Official technical guidance has been published, and hosting providers and software vendors are responding.
Businesses have a clear opportunity to reduce their exposure.
But only if they act.
So the next time a developer or hosting provider tells you that your website is up to date, consider asking a different question.
Not simply:
"Is our website working?"
But:
"Can you confirm that the technologies running underneath our website have been checked for critical vulnerabilities — and that the necessary security fixes are actually installed?"
Because sometimes, the greatest threat to a website is not what appears on the screen.
It's what remains invisible beneath it.