In short: Hiring an IT security provider is worthwhile if there are signs of a break-in, old PHP versions without an official update are running, time or expertise is lacking internally or legal questions are involved. If your website is with a host that confirms patch and restart in writing, or your own IT can update a supported PHP version and verify it, you often need no outside help for PHP2Shell.
The question many are asking right now
In the week after 21 October 2026, many companies looked more closely for the first time at who actually looks after their web servers. The result was often sobering: the agency is responsible for content, the host for the hardware, and nobody knows exactly which PHP version is on the old vServer.
At the same time: not every company needs a security provider in this situation. Anyone who honestly checks what can be done internally saves money and keeps control. Anyone who overestimates themselves risks a break-in going undetected. This article helps with the assessment, without wanting to sell you something you do not need.
Fix it yourself or hire an IT security provider: the criteria
| Criterion | Fix it yourself | Hire a provider |
|---|---|---|
| Hosting model | Shared hosting or managed with confirmed patch | Own server without support, unclear responsibility |
| PHP version | 8.2 to 8.5, official update or distribution backport available | 8.1 or older, only source backports or third-party sources |
| Number of systems | One or a few websites, well documented | Many servers, mixed environments, containers |
| Internal expertise | Admin with server rights, experience with package management and restarts | Nobody with access or experience available |
| Signs of a break-in | No anomalies after checking | Unknown files, processes, accounts or connections |
| Personal data | No sensitive data on the system | Customer data, health or payment data |
| Insurance and notification duties | No involvement | Insurer or data protection must be involved |
| Need for evidence | Internal note is enough | Report needed for management, audit or insurer |
If several rows in the right-hand column apply in your situation, there is much to be said for outside help. If only the right-hand column for “need for evidence” applies, targeted support with the documentation is often enough.
A self-test in seven questions
Answer the questions with yes or no. Every no is a hint as to where you might need help.
- Do you know, for each website, which server it runs on and with which PHP version?
- Can you prove that this level is fixed against CVE-2026-109618 and CVE-2026-109619, for example via the package changelog? The instructions are under Checking the PHP version and patch level correctly.
- Does someone in-house have the rights and the knowledge to update PHP and restart all workers?
- For websites at the host, do you have written confirmation of patch and restart? A template is offered in How to ask your host about the patch status.
- Has someone searched for anomalies since 17 October 2026, such as new PHP files in upload folders or unknown cron jobs?
- Are the server logs from 20 October 2026 onwards preserved?
- Is there a person who may decide on a temporary shutdown and can be reached?
Seven yeses mean you are well positioned. One or two noes can often be made up internally. With three or more noes, especially on questions 2 and 5, outside support is a serious consideration.
When you explicitly do not need a provider
There are situations in which we ourselves would advise against spending money on outside help. A simple company website at a large host that has confirmed the patch, without forms handling sensitive data and without anomalies, is one. So is your own server with PHP 8.3 or 8.4 whose admin has installed the distribution backport, restarted all processes and briefly looked through the logs.
In these cases the most important thing is a short written note: what was checked when, and with what result? It helps with follow-up questions and in the next situation.
Honestly, it also means not underestimating your own limits. Installing an update is routine for many admins. Assessing a suspicious file correctly without destroying traces usually is not. Anyone who finds something unusual while patching should pause at that point, delete nothing and decide anew whether to continue alone.
Even if you do everything yourself: decide today whom you would call if something does turn up. In an emergency, looking for a provider is lost time.
The middle way: divide instead of hand over
Between “everything ourselves” and “hand everything over” lies the variant that works best in many companies. Your own team takes on what it knows: updates, restarts, contact with the host. A provider takes on what requires specialist knowledge or an independent view, such as checking for traces, assessing a suspicion or the report for insurers.
For this to work, access, responsibilities and data protection must be settled. If a provider accesses servers with personal data, a data processing agreement is generally required; notes are under Data processing agreements when service providers access servers. How to find a suitable provider is described in Choosing an IT security provider.
How does PHP SOS help?
- We begin with a brief inventory and tell you openly if you do not need us.
- We take on selectively the parts that are missing internally, such as the check for traces, legacy systems or the evidence, and leave the rest with your team.
- We work remotely with the access you approve and document every step.
- For acute needs, we take over inventory, patch, restart and search for traces completely with the PHP2Shell immediate help.
Conclusion
The right answer to “yourself or provider?” is rarely black or white. Anyone who knows their systems, runs supported PHP versions and can prove that patching and restart were done often manages PHP2Shell alone. Anyone with legacy systems, unclear status or signs of a break-in should not hesitate to get help.
Frequently asked questions
When should I hire an IT security provider?
Above all if there are signs of a break-in, if old PHP versions without an official update are running, if nobody internally with server rights and experience is available, or if personal data and insurance questions are involved.
Can't my host simply take care of it?
With shared hosting and many managed plans, the host patches PHP itself. Have the patch level and restart confirmed in writing. For your application, plugins and a check for traces, the host is usually not responsible.
What should I prepare before calling a provider?
A list of the affected websites and servers, access routes, contacts with decision-making authority and a short description of what you noticed. Until then, do not delete or change anything that might contain traces.
Is there a middle way between doing it yourself and handing everything over?
Yes. Often your own team takes on the routine, such as updates and restarts, while a provider takes on the check for traces, the assessment or the documentation. A clear division of who does what is important.