Responding to a Critical PHP Security Issue: Backups, Client Communication, and Late-Night Work

Technology, Website Maintenance & IT Experiences

Some days in IT are not about building something new. They are about protecting what already exists, responding to unexpected technical challenges, and making decisions before a small issue becomes a bigger problem.

Over the past few days, I have been dealing with an important PHP security issue affecting the wider web development community. What began as a security concern quickly became a priority involving customer website backups, client communication, technical assessment, preventive measures, and late-night work.

This experience has reminded me that maintaining websites is not just about keeping them online. It is also about understanding risks, responding responsibly, and helping clients make informed decisions.

Two Critical PHP Vulnerabilities Disclosed Worldwide

On October 21, 2026, two critical vulnerabilities were publicly disclosed in the PHP programming language:

• CVE-2026-109618 — a memory-corruption vulnerability associated with PHP’s handling of out-of-memory conditions.
• CVE-2026-109619 — a vulnerability involving stale internal state and the use of memory after it has been freed.

These vulnerabilities can, under certain conditions, allow unauthenticated attackers to execute arbitrary code on affected systems. The potential consequences include unauthorized access to sensitive information, server compromise, and website defacement.

The vulnerabilities affect multiple PHP versions, including older versions that no longer receive standard security updates. Security updates have been released for supported PHP branches, making it important for website owners and administrators to check their server environments and apply the appropriate fixes.

The disclosure is a reminder that even widely used and well-established technologies can develop serious security issues. When vulnerabilities occur in a core technology such as PHP, the implications can extend across many hosting environments and web applications worldwide.

However, not every website is necessarily exposed in the same way. The actual risk depends on the PHP version, server configuration, application environment, and available security patches.

Why This Matters for Older Websites

Many businesses continue to operate websites that were developed several years ago. These websites may still perform their intended functions, but their underlying software, PHP versions, plugins, themes, or server configurations may require additional attention.

A website developed for an older PHP environment cannot always be moved directly to a newer version without compatibility testing. At the same time, remaining on an unsupported or vulnerable environment can create security risks.

This presents a difficult challenge: maintaining compatibility while addressing security concerns.

For IT professionals responsible for customer websites, the priority is to assess each environment carefully rather than make assumptions based solely on the website’s age or the version number displayed in its dashboard.

My First Priority: Taking Website Backups

As I began responding to this issue, one of my first priorities was to take backups of customer websites.

Before making significant changes to a website’s environment or configuration, it is important to preserve its files and database. A reliable backup helps protect existing content and provides a recovery option if an update or other intervention causes unexpected problems.

For older websites in particular, backups are an essential part of responsible maintenance.

They allow technical work to proceed with greater confidence, but they must also be handled properly. A backup should be stored securely, checked for completeness, and kept separate from the production environment where practical.

Taking a backup does not resolve a vulnerability by itself. It helps protect the website’s data and supports recovery while the underlying security issue is addressed.

Calling Clients and Sending Emails

Another significant part of this work has been communicating directly with customers.

I have been calling clients and sending emails to explain the PHP security concern, discuss its potential implications, and inform them about the preventive steps being considered for their websites.

Not every client has the same technical background, and security advisories can be difficult to understand without additional explanation. My responsibility is therefore not limited to identifying technical problems. It also includes communicating what is known, explaining the possible risks, and helping clients understand why action may be necessary.

Each website has its own technical history, business requirements, and operational importance. Some websites may need a PHP update and compatibility testing, while others may require a more detailed assessment before a safe remediation plan can be established.

Clear communication is particularly important when preventive action could temporarily affect a client’s online presence.

Temporarily Taking Selected Websites Offline

After assessing the circumstances, I decided to temporarily take a few selected customer websites offline as a preventive measure while the technical situation was being reviewed.

This was not a decision taken lightly.

A website can be an important business asset, providing information, generating enquiries, supporting customers, or enabling daily operations. Taking it offline can cause inconvenience, but leaving a potentially vulnerable website exposed without an appropriate mitigation plan may also be risky.

The decision was limited to selected websites where temporary suspension was considered appropriate. It was not a blanket decision to take every customer website offline.

The objective was to reduce exposure while arranging the next steps, including reviewing the PHP environment, assessing compatibility, and determining the appropriate remediation approach.

Taking a website offline is not a permanent fix, nor does it guarantee complete protection. It is a temporary risk-reduction measure that should be accompanied by a clear plan for patching, testing, and restoring the service safely.

Working Late into the Night

Between preparing backups, reviewing technical requirements, contacting customers, responding to emails, and considering preventive measures, the work has continued late into the night.

Some responsibilities cannot always be completed within regular working hours, particularly when a security issue requires prompt attention across multiple customer websites.

Each action needs careful consideration. A rushed PHP update can break an older website, while delaying an appropriate security response can leave a vulnerable environment exposed.

Finding the right balance requires patience, technical assessment, and a willingness to work through the details.

Late-night work is not something to celebrate for its own sake. What matters is ensuring that the additional effort contributes to a safer, more reliable outcome for the clients who depend on these systems.

What Comes Next?

The immediate response is only one part of the process. The longer-term priority is to move affected websites toward a more secure and maintainable environment.

Depending on each website’s circumstances, the next steps may include:

• Reviewing the installed PHP version and confirming whether the relevant security fixes are present.
• Updating to an appropriate patched PHP release, where supported.
• Testing compatibility with the website’s CMS, plugins, themes, and custom code.
• Reviewing server configurations and relevant security logs.
• Verifying backups and preparing a recovery plan.
• Coordinating with hosting providers when server-level changes are required.
• Restoring temporarily suspended websites after the necessary checks and remediation have been completed.

Older PHP versions that have reached end of life need particular attention because standard upstream security fixes may no longer be available. In such cases, a supported upgrade path or another appropriate mitigation strategy needs to be considered.

The goal is not merely to bring a website back online. It is to restore it with a reasonable level of confidence in its security, stability, and compatibility.

Lessons from This Experience

This situation has reinforced several important lessons for me.

• Backups are fundamental. Preserving a recoverable copy of a website should be part of routine maintenance, not something considered only after a problem appears.
• Security requires continuous attention. A website that worked correctly yesterday may still require action when a new vulnerability is disclosed.
• Communication is part of technical responsibility. Clients should be informed about significant risks and understand why a particular preventive measure is being taken.
• Every website needs individual assessment. Different PHP versions, hosting configurations, and application dependencies mean that the same solution will not work for every website.
• Temporary protection should lead to a sustainable solution. Taking a website offline may sometimes be appropriate, but the long-term objective must be effective remediation and safe restoration.

Beyond Keeping Websites Online

Working in IT is not always about developing new features, launching projects, or making websites look better. Sometimes, it means revisiting older systems, responding to unexpected security concerns, making difficult decisions, and explaining technical issues to people who rely on your work.

Much of this effort happens behind the scenes. Website visitors may never know about the backups, client calls, security assessments, or late-night decisions that take place to protect a service.

Yet these responsibilities are an important part of maintaining trust.

For me, this experience is another reminder that technology is not only about making things work. It is also about understanding when something could go wrong, preparing for uncertainty, communicating honestly, and taking responsible action.

The work continues—one website, one conversation, and one careful decision at a time.