In short: If your PHP server is giving you trouble and you want to talk directly to an expert, call us or write to us on WhatsApp. Affected? Call us. We help. We clarify remotely whether an outage, a misconfiguration or an attack is behind it, and we take over from the first message until the incident is closed and documented.
Do not delete anything and do not rebuild anything right now. A restart or a rollback can also blur traces. First tell us what you see. Report an emergency and then we will set the next step.
Are You Affected? These Disruptions Are a Case for Us
Not every disruption is an attack, but in these days it is worth taking a look. Get in touch if any of the following occurs on your PHP system:
- PHP processes or the web server abort, keep restarting or are terminated by the system (exit status 137).
- The load rises for no apparent reason or memory fills up.
- Pages deliver empty responses, 500 errors or error messages that did not exist before.
- Processes that start a shell are running under the web server or PHP-FPM.
- There are PHP files in the upload or cache folder that you do not know.
- An application stops working after a PHP update.
- Your host has blocked access or taken the site offline.
The difference between an outage and an attack usually shows only in the logs. Initial clues on what matters are described in the post The web server starts a shell.
What to Do Right Now
- Observe before you intervene. Note the time, the error messages and what was changed last (update, plugin, configuration).
- Secure the logs. Copy web server, PHP and system logs away before they rotate. Trade press advises keeping logs from 20 October 2026 onward.
- Do not restart blindly. A restart fixes some outages but destroys volatile traces. Restart if operations require it, and note what you did.
- Weigh availability. If you suspect an attack, isolating or switching off is often right. The BSI (German Federal Office for Information Security) advises this when an update is not immediately possible.
- Determine the PHP version.
php -vshows the version, but not always that of the web server runtime. - Call or write. The more precisely you can describe the situation, the faster we get to the core.
How Does PHP SOS Help?
We work remotely, with no travel, across Germany and Europe.
- Assess the situation: In the first conversation we listen and ask targeted questions: systems, PHP operating mode, time, latest changes. Afterward you know whether we see an outage or a suspected attack.
- Secure and close: We secure the state, fix the cause and, if necessary, close the vulnerability with an update, a restart and interim measures.
- Check and clean up: If a break-in shows up, we remove malicious code and check access and secrets. Otherwise we document the cause and keep operations running cleanly.
- Harden and report: You receive a short report and recommendations so that the disruption does not recur.
If there is more behind it, we move into the emergency help for hacked websites or into structured incident response.
Memory, Crashes and the New Limit
Since the security releases of 21 October 2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35), the directive memory_hard_limit_percent exists. Since then memory_limit is a soft limit. Without a setting of your own, the hard limit is twice memory_limit up to 1G, and above that memory_limit plus 1G. If it is exceeded, the process ends immediately with exit status 137. An operation that ran close to the limit before the update can suddenly show crashes as a result. That is not an attack but a consequence of the fix, and the solution is to adjust the application or the limit properly, not to roll back the update.
Conversely: anyone who sees crashed processes and has not yet patched should not dismiss it as coincidence, because the vulnerability CVE-2026-109618 is connected with an out-of-memory condition. Whether that plays a role in your case is shown by the logs. Background on memory management can be found under Out-of-memory in PHP, possible signs of a break-in under Suspicious processes on Linux.
When the Host Intervenes
Some providers block accounts or take sites offline as a precaution. That does not automatically mean you were hacked, but it can be a consequence of irregularities. Ask for the reason and the time, ask for the logs and note what the provider demands. We coordinate with your host if you wish. It makes sense to clarify in advance who at the provider may make decisions and whether the provider has server logs that you cannot see yourself. Such data, for example access at the network level, can later be decisive when it comes to narrowing down the time of a possible break-in.
What You Should Send Us
- a short description: what failed or is unusual, since when?
- the type of system (own server, hosting package, container) and the host
- the output of
php -v, the operating mode and web server, as far as known - error messages or excerpts from the logs
- the time of the last PHP update and the latest changes
- a contact person with authority to decide on restarts
Why PHP SOS
We work Made in Germany and, together with our partner network of cyber professionals, have specialized in IT security for over 25 years. You talk to one fixed contact instead of a ticket system. We work remotely, document what we see and do, and say openly what is proven and what is not. For acute cases around the vulnerability there is also the PHP2Shell emergency response.
Affected? Call Us. We Help.
If your PHP server is giving you trouble, do not wait for the next outage. Call us or write to us on WhatsApp. We take over from the first message. Report an emergency now.
Frequently asked questions
My PHP server is suddenly slow or crashing: is that an attack?
Not necessarily. Outages often have mundane causes such as too little memory, a faulty update or overload. Only a look at logs and processes shows whether it is an attack; warning signs are, for example, shell processes under the web server or unknown new PHP files.
What does exit status 137 mean for PHP processes?
Status 137 stands for a process that was terminated immediately. According to the PHP manual, a process ends with 137 when it exceeds the hard memory limit of the new directive memory_hard_limit_percent; it may also have been terminated by the system because of a lack of memory. A look at the logs clarifies the cause.
Can I talk to an expert on the phone before I change anything?
Yes, that is exactly what emergency help is for. Call us or write on WhatsApp and describe what you notice. We tell you what to leave alone and what you can safely do.
Should I simply restart the PHP service?
A restart can fix an outage but erases clues in memory. If a break-in is possible, secure the logs first and get advice. After a PHP update, however, a restart is mandatory.
Do you also work if my server is at a host?
Yes, we work remotely with the access you have and coordinate with your host if needed. Which checks are possible depends on your rights.