# Blog: PHP2Shell, server security and emergency help

> Blog on PHP2Shell and server security: situation, hosting, detection, hardening, secure development, management and decision aids.

Source: https://phpsos.de/en/blog/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

Assessment of the situation, instructions for admins and decision aids for management. Sorted by topic, every article with sources.

- [PHP2Shell: What Is Confirmed and What Is Not](https://phpsos.de/en/blog/php2shell-was-belegt-ist/): A fact check on PHP2Shell: which statements come from primary sources, which from media reports, and which claims do not hold up.
- [Why the PHP Vulnerability Became Known Before the Patch](https://phpsos.de/en/blog/php-luecke-vorzeitig-bekannt/): According to reports, details of PHP2Shell became public before the embargo expired. We explain the sequence and what it means for your patch planning.
- [Authorities Take Websites Offline: What Companies Can Learn](https://phpsos.de/en/blog/behoerden-webseiten-offline/): Mainz, the Hessian state government and the BKA took websites offline as a precaution. What companies can learn from this for their own decisions.
- [BSI Warning Level Orange: What the Rating Means](https://phpsos.de/en/blog/bsi-warnstufe-orange-erklaert/): The BSI rates PHP2Shell at 3 / orange. What the scale says, what it does not, and how companies translate the rating into decisions.
- [What CERT-EU and CERT-Bund Advise on PHP2Shell](https://phpsos.de/en/blog/cert-eu-empfehlungen-php/): The official bodies agree: patch immediately, otherwise isolate. We compare the recommendations and show what isolating looks like in practice.
- [Cloudflare Protection Rules Against PHP2Shell: What They Do and Do Not Do](https://phpsos.de/en/blog/cloudflare-waf-php2shell/): Cloudflare rolled out protection rules against PHP2Shell early. Why that helps, why it still does not replace the PHP update and which settings you should check.
- [22.6 Million Exposed Instances: Reading the Figures Correctly](https://phpsos.de/en/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel and others give very different figures for PHP2Shell. We explain what was counted and which figure really matters for you.
- [PHP2Shell in Five Minutes: Briefing for Management](https://phpsos.de/en/blog/php2shell-briefing-geschaeftsfuehrung/): The PHP vulnerability PHP2Shell on one page for decision-makers: situation, risk, five questions for IT and the decisions for today.
- [The PHP Security Vulnerability Explained Simply](https://phpsos.de/en/blog/php-luecke-einfach-erklaert/): PHP2Shell for non-technical readers: with everyday images, a small glossary and three typical starting situations, what you should do as a website operator.
- [PHP2Shell: 15 Questions from Hosting Customers](https://phpsos.de/en/blog/fragen-von-hosting-kunden/): Your website is with a hosting provider and you want to know what you have to do yourself about PHP2Shell? Here are the 15 most common questions with short answers.
- [Why a WordPress Update Does Not Help Against PHP2Shell](https://phpsos.de/en/blog/warum-wordpress-update-nicht-hilft/): After the headlines, many operators updated WordPress and feel safe. Why that misses the point with PHP2Shell and what counts instead.
- [PHP2Shell and Log4Shell: What the Vulnerabilities Have in Common](https://phpsos.de/en/blog/php2shell-und-log4shell/): Many compare PHP2Shell with Log4Shell from 2021. What the comparison supports, where it falls short and which lessons from back then help today.
- [Mass Scans for Unpatched PHP: How Automated Attacks Work](https://phpsos.de/en/blog/automatisierte-massenscans/): After PHP2Shell, attackers scan the internet automatically for vulnerable servers. How it works, why size does not matter and what protects you.
- [The Time Window Between Patch and Attack](https://phpsos.de/en/blog/zeitfenster-patch-angriff/): With PHP2Shell there were attack attempts even before the patch. We explain the phases of the time window, how to measure your own and how to shorten it.
- [After PHP2Shell: Why Further Announcements Are Likely](https://phpsos.de/en/blog/weitere-php-meldungen/): PHP2Shell is not over with the patch of 21 October. Why follow-up announcements are to be expected and how to prepare your team for them.
- [PHP2Shell: The Situation Report for the First Week](https://phpsos.de/en/blog/lagebild-erste-woche/): One week after the first observed attack attempt: the status of patches, official warnings, attacks and shutdowns, cleanly separated by source.
- [Dangerous Bad Advice on PHP2Shell That Is Circulating Right Now](https://phpsos.de/en/blog/gefaehrliche-falschtipps/): Blocking cookies, hiding error messages, updating only the CMS: nine pieces of advice on PHP2Shell that create false security, and what really counts.
- [Changing the PHP Version in the Hosting Customer Area](https://phpsos.de/en/blog/php-version-hosting-aendern/): How to switch the PHP version in your hosting provider's customer area, which version to choose and what to check before and afterwards.
- [Debian and Ubuntu: Is My PHP Package Patched?](https://phpsos.de/en/blog/debian-ubuntu-paket-gepatcht/): Which PHP packages Debian and Ubuntu have corrected against PHP2Shell, how to compare the installed version exactly and why proof often fails.
- [RHEL, AlmaLinux and Rocky Linux: Checking the PHP Patch](https://phpsos.de/en/blog/rhel-almalinux-rocky-php/): What Red Hat has published on PHP2Shell, how to prove the package version on RHEL and its rebuilds and why a reload is not enough.
- [The sury.org Repository: PHP Packages from a Third-Party Source](https://phpsos.de/en/blog/sury-repository-php/): Many Debian and Ubuntu servers get PHP from the sury repository. What that means for updates, proof and old PHP versions after PHP2Shell.
- [The Remi Repository: Keeping PHP Current on RHEL Systems](https://phpsos.de/en/blog/remi-repository-php/): Remi supplies current PHP versions for the RHEL family, as a module or installable in parallel. How to check the status after PHP2Shell and avoid forgotten branches.
- [Why php -v Shows the Same Number After the Update](https://phpsos.de/en/blog/php-v-zeigt-alte-nummer/): The update ran, yet php -v reports the old version. Usually that is a backport and not an error. How to tell harmless cases from real problems.
- [Proving CVE Numbers in the Package Changelog](https://phpsos.de/en/blog/cve-im-changelog-nachweisen/): If you must prove a PHP patch to management, auditors or insurers, a version number is not enough. Here is how the changelog entry becomes proof.
- [Switching Hosting Providers After a Security Incident: What to Look For](https://phpsos.de/en/blog/hoster-wechseln-nach-vorfall/): After an incident, wanting a new hoster is understandable. To keep the attacker from moving along with you, order and selection matter.
- [Multiple PHP Versions on One Server: Patch Each One Separately](https://phpsos.de/en/blog/mehrere-php-versionen-server/): Many servers run three, four or more PHP installations side by side. After PHP2Shell, each one must be found, updated and restarted.
- [Switching Off Old PHP Versions in the Hosting Panel](https://phpsos.de/en/blog/alte-php-versionen-abschalten/): PHP2Shell is a good occasion to get rid of old PHP versions. Here is how to proceed in three phases so that no website and no cron job fails unnoticed.
- [Plesk: Understanding PHP Handlers (FPM, FastCGI, Apache Module)](https://phpsos.de/en/blog/plesk-php-handler/): Which PHP handler Plesk uses for a website determines isolation, configuration and risk. A comparison with PHP2Shell in mind.
- [CloudLinux and alt-php: What Hosting Customers Should Know](https://phpsos.de/en/blog/cloudlinux-alt-php/): On CloudLinux servers, websites often run on their own alt-php packages. Each of these versions needs its own patch, and only the server operator can apply it.
- [PHP on NAS, Firewalls and Appliances: The Forgotten Systems](https://phpsos.de/en/blog/php-auf-nas-und-appliances/): It is not only web servers that use PHP. NAS systems, firewalls and specialist devices with a web interface can be affected too. There, usually only the vendor can patch; you control reachability yourself.
- [PHP at Cloud and PaaS Providers: Who Patches the Runtime?](https://phpsos.de/en/blog/paas-php-laufzeit/): On platform services, the PHP patch depends on the operating model. What matters is the runtime that actually serves requests, not the local environment or the application code.
- [Official PHP Docker Images: Tags, Digests and Rebuilds](https://phpsos.de/en/blog/offizielle-php-docker-images/): A tag of the official PHP image is a pointer that moves to new states over time. If you know what tag, variant and digest mean, you choose the right image and can prove the patch status.
- [CI/CD: Rebuilding PHP Images Automatically](https://phpsos.de/en/blog/php-images-in-ci-neu-bauen/): An image goes stale even without code changes. With scheduled builds, a version check and a rollout by digest, PHP patches reach production reliably.
- [Long-Term Support for Old PHP Versions: Options and Limits](https://phpsos.de/en/blog/langzeitsupport-alte-php-versionen/): If you cannot switch away from PHP 8.1 or older right away, you will find long-term support from distributions, third parties and commercial services. What these routes deliver, what you need in writing and where the limits lie.
- [Updating PHP on Windows](https://phpsos.de/en/blog/php-unter-windows-aktualisieren/): Windows has no automatic PHP update. If you choose the right variant, verify the download and restart all processes, you bring the PHP2Shell patch cleanly onto every machine.
- [Warning Sign: The Web Server Starts a Shell](https://phpsos.de/en/blog/webserver-startet-shell/): If a PHP-FPM or web server process starts a shell, that is one of the strongest warning signs of a break-in. Here is how to check the process tree, classify exceptions and monitor the pattern permanently.
- [Finding Suspicious Processes on Linux Servers](https://phpsos.de/en/blog/verdaechtige-prozesse-linux/): Malicious processes disguise themselves with harmless names and run from temporary folders or from deleted files. With a few read-only commands you find anomalies and classify them.
- [Detecting Hidden Cron Jobs as a Backdoor](https://phpsos.de/en/blog/cronjobs-als-hintertuer/): Attackers use scheduled tasks to return after a cleanup. Here is how to check crontabs, cron directories, systemd timers and at jobs completely and recognize suspicious entries.
- [Finding Recently Changed Files on the Web Server](https://phpsos.de/en/blog/geaenderte-dateien-finden/): After a possible break-in, what matters is what has changed on the server. Here is how to search by time window, use mtime and ctime correctly and compare against packages, Git and backups.
- [PHP Files in the Upload Folder: Interpreting the Finds Correctly](https://phpsos.de/en/blog/php-dateien-im-upload-ordner/): A PHP file in the upload folder is almost always a warning sign, but not every one is malicious code. Here is how to assess the find without destroying traces and clarify whether anyone called it.
- [Recognizing Obfuscated PHP Code](https://phpsos.de/en/blog/verschleierter-php-code/): Unreadable PHP code with eval and base64_decode is a classic sign of injected malicious code. Which patterns to look for, how to find them safely and when obfuscation is legitimate.
- [Checking a Server's Outgoing Connections](https://phpsos.de/en/blog/ausgehende-verbindungen-pruefen/): A web server mainly answers requests. If it itself opens connections to unknown destinations, that can mean control by attackers or data leakage. Here is how to check and limit outgoing traffic.
- [Finding Rogue Admin Accounts in the CMS and on the Server](https://phpsos.de/en/blog/fremde-admin-konten-finden/): An unknown administrator is often the simplest backdoor. Here is how to search layer by layer for rogue accounts, including those the interface hides.
- [Finding and Removing Unknown SSH Keys](https://phpsos.de/en/blog/ssh-schluessel-pruefen/): An injected SSH key opens the door for attackers even after all passwords have been changed. Here is how to find every authorized_keys file and check every entry.
- [Crypto Miner on the Web Server: Signs and Procedure](https://phpsos.de/en/blog/kryptominer-auf-dem-server/): CPU constantly maxed out without more visitors: that can be a crypto miner. Here is how to check the load, find the process and its restart mechanisms and proceed in an orderly way.
- [The Server Is Sending Spam: Finding the Causes](https://phpsos.de/en/blog/server-verschickt-spam/): Undeliverable mails, blocklists, complaints: when your own server sends spam, a script or a hijacked mailbox is usually behind it. Here is how to find the source.
- [SEO Spam and Foreign Pages in the Google Index](https://phpsos.de/en/blog/seo-spam-im-google-index/): Suddenly pages about pharmaceuticals or counterfeit goods rank under your domain. Here is how to find where the SEO spam comes from and get it out of the index.
- [The Website Redirects to Foreign Sites](https://phpsos.de/en/blog/website-leitet-um/): Visitors end up on prize draws or dubious shops, but you see nothing yourself? Here is how to find the layer where the redirect hides and remove it.
- [Preserve Evidence Before You Rebuild the Server](https://phpsos.de/en/blog/beweise-sichern-vor-neuinstallation/): A rebuild removes the attacker, but also every trace. Invest an hour in preserving evidence first and you can later say what happened.
- [Building the Timeline of an Incident](https://phpsos.de/en/blog/zeitleiste-eines-vorfalls/): When did the attacker arrive, what did they do, when was it noticed? A clean timeline answers these questions and is the basis for notifications, insurance and the report.
- [Comparing CMS Core Files With the Original](https://phpsos.de/en/blog/cms-kerndateien-vergleichen/): A comparison with a clean original shows every changed file, whether or not a scanner knows it. Here is how to set up the check for WordPress, Composer projects and system packages.
- [Checking the Database for Injected Code](https://phpsos.de/en/blog/datenbank-auf-schadcode-pruefen/): If you only check files, you miss half. Here is how to search content, settings, triggers and accounts of the database for injected code, read-only and on a copy.
- [Website Malware Scanners: What They Find and What They Don't](https://phpsos.de/en/blog/grenzen-von-malware-scannern/): The scanner reports nothing, so all is well? Not necessarily. Which types of website scanners exist, what each one sees and what none of them can see.
- [Isolating PHP-FPM Pools per Website](https://phpsos.de/en/blog/php-fpm-pools-isolieren/): A separate pool per website is the beginning, not the end. Here is how to check existing pools and harden sockets, extensions, status pages, resources and logs.
- [Setting memory_limit Correctly](https://phpsos.de/en/blog/memory-limit-richtig-setzen/): memory_limit caps the memory per PHP request. After PHP2Shell, php.net temporarily advises the opposite. What applies in normal operation, in the interim and after the update.
- [Sensibly Limiting post_max_size and upload_max_filesize](https://phpsos.de/en/blog/post-max-size-upload-limits/): Upload limits act in three places: the web server, PHP and the application. Here is how to set the values consistently, including php.net's interim values for PHP2Shell.
- [Disabling session.upload_progress: Correctly and Permanently](https://phpsos.de/en/blog/session-upload-progress-abschalten/): The remedy for CVE-2026-115560 and one of the PHP2Shell interim measures is quickly set. For it to hold, it must be in the right place, locked and rechecked after every update.
- [expose_php and Server Headers: Hiding Version Information](https://phpsos.de/en/blog/expose-php-versionsangaben/): PHP, Nginx and Apache state their version number in every response by default. This does not protect against attacks, but gives scanners a handy hit list. Here is how to switch it off and still keep track.
- [display_errors off: Disabling Error Output in Production](https://phpsos.de/en/blog/display-errors-produktion/): Visible PHP error messages reveal paths, database names and versions. Here is how to switch them off in PHP, in the framework and in the web server without losing sight of the errors.
- [php_admin_value: Locking Settings Against Overrides](https://phpsos.de/en/blog/php-admin-value-sperren/): A security setting is of little use if the application changes it again with one line of code. With php_admin_value and php_admin_flag you fix values for PHP-FPM and Apache bindingly.
- [Setting Memory Limits With systemd and cgroups](https://phpsos.de/en/blog/speichergrenzen-systemd-cgroups/): As a PHP2Shell interim measure, php.net recommends memory_limit=-1 and a memory limit outside PHP. Here is how to set that limit with systemd and cgroups without a single worker taking the whole service down.
- [Configuring Nginx for PHP Securely](https://phpsos.de/en/blog/nginx-fuer-php-absichern/): Most weaknesses in Nginx setups for PHP are not in Nginx but in a few lines of the PHP location. Here is how to configure the handover to PHP-FPM so that only intended scripts are executed.
- [Configuring Apache for PHP Securely](https://phpsos.de/en/blog/apache-fuer-php-absichern/): Apache is flexible, and that is exactly what makes it prone to misconfiguration. Here is how to connect PHP via PHP-FPM, close .htaccess as a backdoor and set the most important core options safely.
- [Forbidding PHP Execution in Upload Folders](https://phpsos.de/en/blog/php-in-uploads-verbieten/): A webshell needs two things: a folder it can be written to and a server that executes it. Here is how to take away the second, in every writable folder, not just uploads.
- [Filtering Upload Requests at the Edge: Opportunities and Risks](https://phpsos.de/en/blog/upload-anfragen-am-rand-filtern/): Trade authors suggest blocking upload requests outside real upload paths at the proxy until PHP is patched. That can help, but it can also paralyze forms and orders. Here is how to proceed in a controlled way.
- [Using ModSecurity and the OWASP Core Rule Set](https://phpsos.de/en/blog/modsecurity-owasp-crs/): Your own web application firewall with ModSecurity and the OWASP Core Rule Set is free and powerful, but it does not run itself. Here is how to choose the engine, start without outages and tune the rules.
- [Setting Up Fail2ban for Web Servers](https://phpsos.de/en/blog/fail2ban-fuer-webserver/): Fail2ban bans addresses that repeatedly stand out in the logs. For web servers it comes with ready-made filters, and a few lines add your own. Here is how to set it up without locking out yourself or your customers.
- [Firewall for Web Servers: Opening Only Necessary Ports](https://phpsos.de/en/blog/firewall-fuer-webserver/): A web server usually needs only two ports to the outside. Yet on many servers, databases, PHP-FPM or admin interfaces are listening on the internet. Here is how to find open services and close what is not needed.
- [Automatic Security Updates on Linux Servers](https://phpsos.de/en/blog/automatische-sicherheitsupdates/): According to reports, distributions shipped PHP backports in some cases on 21 October 2026, the day of the patches. Anyone using automatic security updates had them on the server quickly. For them to take effect, you need restarts, third-party sources and oversight.
- [Least Privilege: Permissions of the Web Server User](https://phpsos.de/en/blog/rechte-des-webserver-benutzers/): Injected code runs with the rights of the web server user. What this account may do decides how far an attacker gets. Here is how to limit shell, sudo, cron, database and file system to what is necessary.
- [Shielding Admin Areas with IP Allowlists, VPN or Extra Protection](https://phpsos.de/en/blog/admin-bereiche-abschirmen/): Why a website's backend does not need to be reachable by the whole world, and how to shield it with an IP allowlist, VPN or an upstream login without locking yourself out.
- [Configuring TLS and HTTPS Correctly](https://phpsos.de/en/blog/tls-https-richtig-konfigurieren/): Which TLS versions and cipher suites a web server should offer today, what the recommendations are based on, and how to check Nginx, Apache and outgoing PHP connections.
- [CIS Benchmarks and BSI Modules for Web Servers](https://phpsos.de/en/blog/cis-benchmarks-bsi-bausteine/): Which hardening standards exist for Linux web servers, how CIS Benchmarks and IT-Grundschutz modules differ, and how to turn them into a verifiable specification for your PHP servers.
- [Storing Passwords Securely in PHP: Using password_hash Correctly](https://phpsos.de/en/blog/passwoerter-in-php-speichern/): How developers store passwords in PHP with password_hash and password_verify, choose the right algorithm and replace old MD5 or SHA-1 hashes without a password reset for all users.
- [CSRF Protection in PHP Applications](https://phpsos.de/en/blog/csrf-schutz-php/): How developers prevent cross-site request forgery in PHP applications: tokens for every state-changing request, origin checks in the header and SameSite cookies as an additional layer.
- [Validating and Filtering Input in PHP with filter_var](https://phpsos.de/en/blog/eingaben-validieren-php/): How developers check input in PHP with filter_var, filter_input_array and allowlists, which filters are deprecated and why validation does not replace prepared statements and output encoding.
- [Preventing Command Injection in PHP](https://phpsos.de/en/blog/command-injection-php/): How developers avoid command injection in PHP: replace system commands with PHP functions, use proc_open without a shell, check arguments and find dangerous spots in existing code.
- [Preventing Server-Side Request Forgery (SSRF) in PHP](https://phpsos.de/en/blog/ssrf-in-php/): How developers prevent a PHP application from querying internal systems on behalf of outsiders: allowlists, protocol restriction, checking the resolved address and limits in the network.
- [Preventing XML External Entities (XXE) in PHP](https://phpsos.de/en/blog/xxe-in-php/): How developers process XML securely in PHP: libxml default behavior, risky options such as LIBXML_NOENT, protection with an entity loader and LIBXML_NO_XXE, and typical hidden XML inputs.
- [Type Juggling in PHP: Loose Comparisons as a Security Risk](https://phpsos.de/en/blog/type-juggling-php/): Why loose comparisons with == in PHP can lead to security vulnerabilities, what changed with PHP 8.0 and how to write robust comparisons in logins, tokens and permissions.
- [Secure Random Numbers and Tokens in PHP with random_bytes](https://phpsos.de/en/blog/sichere-tokens-php/): How developers generate tokens for password links, API keys and one-time codes in PHP: cryptographically secure sources, sufficient length, storage as a hash and limited validity.
- [Protecting Credentials and .env Files Properly](https://phpsos.de/en/blog/env-dateien-schuetzen/): How to protect database passwords, API keys and other secrets in PHP projects: .env files outside the web root, blocking in the web server, tight permissions and orderly rotation after an incident.
- [Public .git Folder: An Underestimated Data Leak](https://phpsos.de/en/blog/git-ordner-oeffentlich/): Why a web root rolled out with Git can expose the complete source code including its history, how to check for it, block it immediately and build the deployment permanently without a .git folder.
- [Backup Files in the Web Root: .zip, .sql and .bak](https://phpsos.de/en/blog/backup-dateien-im-webroot/): Why database dumps, archives and backup copies in the public directory are among the most common data leaks, how to find and block them, and how to clarify whether they have been retrieved.
- [phpinfo() Files: Why They Must Disappear](https://phpsos.de/en/blog/phpinfo-dateien-entfernen/): After PHP2Shell, many admins quickly create an info.php. Why such files are a data leak, how to find them and which ways of checking are better.
- [Keeping Dependencies Up to Date: Composer, npm and Plugins](https://phpsos.de/en/blog/abhaengigkeiten-aktuell-halten/): A project consists of three package worlds: Composer, npm and CMS plugins. How to keep all three up to date with a fixed rhythm, clear responsibility and tests.
- [Security Code Review for PHP Projects](https://phpsos.de/en/blog/sicherheits-code-review-php/): How teams specifically review their own PHP code for security vulnerabilities: types of reviews, critical functions, useful tools and a checklist.
- [Logging Securely: Recording Errors Without a Data Leak](https://phpsos.de/en/blog/sicher-loggen-php/): Logs help with troubleshooting and forensics but quickly become a data leak themselves. What PHP applications should log, what never, and how to protect logs.
- [Securing REST APIs in PHP](https://phpsos.de/en/blog/rest-api-php-absichern/): Interfaces are often less well protected than the website in front of them. The most important rules for REST APIs in PHP, from object authorization to rate limiting.
- [IT Service Provider Contracts: Defining Security Obligations Clearly](https://phpsos.de/en/blog/dienstleistervertrag-sicherheit/): PHP2Shell showed how often it is unclear who has to patch. Which security obligations belong in contracts with agencies, hosts and IT service providers.
- [Data Processing When Service Providers Access Servers](https://phpsos.de/en/blog/auftragsverarbeitung-serverzugriff/): Anyone who lets outsiders onto servers with customer data usually needs a DPA. What Art. 28 GDPR requires and how to organize access in an emergency in a data-protection-compliant way.
- [Vulnerability Management for Mid-Sized Businesses](https://phpsos.de/en/blog/schwachstellenmanagement-mittelstand/): No mid-sized company can work through every alert immediately. A lean cycle of recording, assessing, deciding and documenting makes sure the important things happen first.
- [Know What Is Running: An Inventory of All Websites and Servers](https://phpsos.de/en/blog/inventar-websites-server/): With PHP2Shell, many struggled not with the patch but with the question of where PHP is running at all. Here is how to build an inventory of all websites and servers.
- [Patch Management as a Process Instead of Firefighting](https://phpsos.de/en/blog/patch-management-prozess/): Anyone who only patches when things are on fire loses time in an emergency. How a patch management process with fixed classes, windows and evidence joins routine and emergency.
- [Emergency Contacts: Who Must Be Informed, and When?](https://phpsos.de/en/blog/notfallkontakte-liste/): In an emergency, what counts is whom you can reach and when. How to build a list of IT emergency contacts, with triggers, deputies and the details every call needs.
- [What a Hacked Server Costs: The Cost Items](https://phpsos.de/en/blog/kostenposten-eines-hacks/): A hacked web server causes more costs than the repair. Which cost items arise and how to justify a prevention budget with your own figures.
- [Informing Customers After an Incident](https://phpsos.de/en/blog/kunden-nach-vorfall-informieren/): Whether mandatory or voluntary: how to decide after an incident whom to inform, which channels are safe and how to prepare your customer service.
- [The Web Supply Chain: Agency, Host, Plugin Vendor](https://phpsos.de/en/blog/lieferkette-agentur-hoster/): PHP2Shell showed how many links lie between a patch and your website. How to know your website's supply chain, secure it and absorb failures of individual links.
- [Security Awareness for Admins and Editors: Awareness in the Web Team](https://phpsos.de/en/blog/sicherheitsbewusstsein-redaktion/): Anyone who maintains websites makes security decisions every day, often without noticing. How to train admins and editors by role, without a slide marathon.
- [Tabletop Emergency Exercise: Playing Through a Web Server Incident](https://phpsos.de/en/blog/notfalluebung-am-tisch/): A tabletop exercise costs one afternoon and shows whether your emergency plan holds up. Here is a ready-made script for an incident on a PHP web server.
- [ISO 27001 and TISAX: What Concerns Web Servers](https://phpsos.de/en/blog/iso-27001-tisax-webserver/): Anyone running an ISMS under ISO 27001 or holding a TISAX label must include web servers. Here is which requirements they touch and which evidence counts after PHP2Shell.
- [VdS 10000: Information Security for Small and Mid-Sized Businesses](https://phpsos.de/en/blog/vds-10000-kmu/): VdS 10000 is a lean framework for information security in mid-sized businesses. What it requires, what is new in 2025 and what it means for websites and web servers.
- [Lessons Learned: Getting Better After an Incident](https://phpsos.de/en/blog/lessons-learned-nach-vorfall/): After the incident is before the next one. A structured review without blame turns a bad week into measurable progress.
- [Patch, Shut Down or Wait? A Decision Aid for the PHP Vulnerability](https://phpsos.de/en/blog/patchen-abschalten-abwarten/): With a critical PHP vulnerability, those in charge must decide quickly. This aid sorts the three options, names criteria and shows when waiting is defensible.
- [WAF or Update: Why You Need Both](https://phpsos.de/en/blog/waf-oder-update/): A web application firewall can intercept attacks, but it does not close a vulnerability in the PHP interpreter. When a WAF helps, where it ends and how to combine both sensibly.
- [Rebuild the Server or Clean It Up? The Decision After a Compromise](https://phpsos.de/en/blog/neu-aufsetzen-oder-bereinigen/): After a break-in there are two paths: clean the server or rebuild it. Which criteria decide, and why the order matters more than the choice.
- [Fix It Yourself or Bring in a Provider? An Honest Weighing](https://phpsos.de/en/blog/selbst-beheben-oder-dienstleister/): Not every security situation needs outside help. With these criteria and a short self-test, decide whether your team can handle PHP2Shell alone or needs support.
- [Choosing an IT Security Provider: 12 Questions Before You Commission](https://phpsos.de/en/blog/sicherheitsdienstleister-auswaehlen/): Finding a good security provider under time pressure is hard. These twelve questions help you compare offers on the facts, without falling for marketing promises.
- [Managed Hosting or Your Own Server? The Security Comparison](https://phpsos.de/en/blog/managed-oder-eigener-server/): PHP2Shell was a stress test for every operating model. The comparison shows when managed hosting is safer, when your own server is, and which hybrid forms work well.
- [PHP Upgrade or Backport? The Decision for Legacy Systems](https://phpsos.de/en/blog/php-upgrade-oder-backport/): For old PHP versions there are several routes after PHP2Shell: distribution backport, third-party source, source patch, long-term support or upgrade. What each route is worth and how long it lasts.
- [Switch the CMS After a Hack? When It Helps and When It Doesn't](https://phpsos.de/en/blog/cms-wechsel-nach-hack/): After a break-in, trust in the CMS is often gone. But a new system rarely solves the actual cause. When switching makes sense and how to do it cleanly.
- [Static Websites: Less PHP, Less Attack Surface](https://phpsos.de/en/blog/statische-website-alternative/): A static website serves finished HTML files and needs no PHP on the server. That cuts the attack surface considerably, but brings its own limits and duties.
- [Pentest, Bug Bounty or Vulnerability Scan? Choosing the Right Testing Method](https://phpsos.de/en/blog/pentest-bugbounty-scan/): Scan, penetration test and bug bounty test websites in very different ways. What each method achieves, where it fails and which order suits your company.