In short: An IT inventory for web servers is a list of all websites, portals, shops and servers, with the details you need immediately when a security alert arrives: where it runs, with which PHP version and operating mode, which application, who is responsible and which data would be affected. Without this list, every response starts with searching. With it, checking against an alert like PHP2Shell takes minutes instead of days.
The first question was: where does PHP run in our company at all?
When the PHP project released the patches on 21 October 2026 and the BSI (German Federal Office for Information Security) recommended immediate action, the instruction was clear: update PHP, restart all processes. For many companies, however, the first step was not the update but an inventory. The main website was known. But the dealer portal? The careers page at another provider? The landing page from a campaign three years ago? The internal wiki?
Trade press and measurement services have made the scale of the problem visible. Palo Alto Networks (Unit 42) counted more than 22.6 million exposed, potentially vulnerable instances. Among them are likely to be many systems that their operators simply no longer think about.
What belongs in an IT inventory for web servers
A usable inventory is a spreadsheet with one row per website or application. These columns have proven their worth:
| Column | Example | Purpose |
|---|---|---|
| Address | shop.example.com | unambiguous identification |
| Purpose and importance | online shop, revenue-critical | prioritisation |
| Host or location | managed server at provider X | whom to call |
| Server and operating system | vServer, Debian | update path, security sources |
| Web server and PHP operating mode | Nginx with PHP-FPM | risk, e.g. mod_php |
| PHP version and package level | 8.3, package with date | comparison with alerts |
| Application and version | Shopware, plugins | vendor alerts |
| Responsible internal / external | head of IT / agency Y | who acts |
| Data processed | customer accounts, orders | reporting duties, urgency |
| Backups | daily, off-site, last tested on … | restoration |
| Last patch evidence | date and proof | evidence for third parties |
The operating mode deserves special attention. For PHP2Shell, the PHP team rated the risk highest for Apache with mod_php. Anyone who knows which systems are run this way can tackle them first. The package level column matters because the displayed version number often stays the same after backports; notes on this are under Checking the PHP version and patch level correctly.
Finding forgotten systems: how to proceed
The known systems are quickly entered. The real work lies in the unknown ones. These sources help to track them down:
- Domains and DNS: Go through all of the company's domains and their subdomains. Every entry that points to a web server is a candidate.
- Invoices: Accounting knows every host, registrar and cloud provider that gets paid. This is often the most complete list.
- Agencies and departments: Marketing, sales and HR like to commission websites directly. Ask them.
- Known servers: On each server, the configuration shows which websites it actually serves.
- Devices with a web interface: NAS devices, routers and appliances sometimes bring their own PHP, see PHP on NAS devices, routers and appliances.
For step 4, a few read-only commands help on Linux servers. They show configured websites, PHP services and FPM pools:
# Configured websites (Apache or Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Running PHP services and processes
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# FPM pools on Debian and Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
If several PHP versions run side by side on one server, each belongs on the list. Each must be updated and restarted individually.
Also enter systems that are actually meant to be switched off. They are often precisely the ones still running, not updated for years and forgotten. An entry “switch off by …” keeps the task visible.
Keeping the inventory up to date
An inventory is only as good as its last update. Three rules keep it alive. First: one person is responsible and is informed of every new website, every move and every shutdown, even if an agency does the work. Second: once a quarter, the list is reconciled with DNS, invoices and server configuration. Third: the inventory is part of the emergency plan and is also available outside your own IT, for example as a printout.
For companies with many distributed systems, such as dealer portals, configurators and supplier access, IT security for mid-sized businesses and industry describes typical places to look. How to integrate the inventory into the emergency plan is covered in Creating an IT emergency plan for web servers.
Common mistakes in a web server inventory
Many inventories exist but do not help in an emergency. The causes are similar:
- Servers only, no websites: The list names machines, but not which websites run on them and who is responsible for them from a business perspective. When a vulnerability appears, nobody knows which department is affected.
- Version instead of package level: “PHP 8.3” says little after PHP2Shell. Only the package level and date show whether the fix is included.
- External systems missing: What runs at an agency or a platform provider is left out because “we are not responsible there”. Responsibility for the data nevertheless stays in-house.
- No contacts: An entry without the name and phone number of the responsible party loses time in an emergency.
- One-off exercise: The inventory is created in a week of crisis and never opened again. After a year, a good part of it is wrong.
Anyone who avoids these five points will have a list to work with at the next alert.
How does PHP SOS help?
- Together with you, we record all websites and servers, including the forgotten ones, via DNS, invoices, service providers and server configuration.
- For each system, we determine the operating mode, PHP version and actual package level.
- We prioritise the systems by reachability, data and operating mode and tell you where to act first.
- Where PHP2Shell is still open, we close the vulnerability through the PHP2Shell immediate help and enter the evidence in the inventory.
Conclusion: An inventory is the most unassuming and at the same time most effective security measure. Anyone who knows what is running can act immediately on the next alert instead of having to search first.
Frequently asked questions
What details does a web server inventory need at a minimum?
Website address, server or host, PHP operating mode, PHP version with package level, application with version, responsible person internally and externally, type of data processed and location of backups. With these details, every new security alert can be checked against the list quickly.
How do I find websites that nobody remembers any more?
Through several routes at once: domain management and DNS zones, invoices from hosts and registrars, questions to agencies and departments, and the configuration of the known servers. Old campaign sites, test systems and subdomains usually turn up this way.
Who should maintain the inventory?
A named person, usually in IT or with the head of IT. What matters is that every change to websites and servers is reported there, even if a department or agency initiated it.
Is a spreadsheet enough or does one need software?
For most mid-sized companies a well-maintained spreadsheet is enough. Software pays off when many systems are to be recorded automatically. What counts is that it is up to date, not the tool.