Web hosting that survives the next PHP flaw
— without taking sites offline.
Layers instead of hope: filtering in front of PHP, isolated containers without a shell, detection, committed response times and per-customer evidence. Also for sites hosted elsewhere.
PHP2Shell: attacks before the patch
The flaw is triggered before the application code runs. Logins, app permissions and WordPress updates therefore do not help.
Exploitation was observed before the flaw became public.
Corrected versions for the currently supported PHP branches.
Older branches only get source patches. Many hosters and systems run exactly there.
NSA, NCSC and CERT-EU advise taking unpatchable systems offline. HostOps is the alternative.
Honest note: interim measures are not a complete fix
Configuration hardening, filter rules and container isolation reduce risk considerably but do not replace updating to a corrected PHP version. We tell you openly where you stand and plan the path to a supported version. We do not promise 100 % security.
Sources: Datadog Security Labs · NCSC-NL
Six protection layers instead of one firewall
Each layer catches what the previous one lets through. A zero-day becomes a controlled incident instead of a compromise.
1Edge filter
WAF and Caddy rules ('virtual patching') roll out within minutes of disclosure: oversized field names, null bytes, body size limits.
2Isolated runtime
One container per site, supported PHP versions only, pinned images, no shell in the image, read-only, memory limit, no outbound traffic without approval.
3Detection
Alerts when a PHP process spawns a shell, on suspicious error logs and on new files (webshell scan, integrity checks).
4Patch response
CVE feed, match against your inventory, rebuild image, test instance, staged rollout. Target for critical flaws: protected within 4 hours.
5Recovery
Hourly immutable snapshots, site code in Git, rebuild instead of cleanup after a compromise.
6Transparency
Per-customer CVE report with timestamps, status page and support for NIS2 notifications.
Three reasons classic hosting is not enough here
Patching alone is too slow
Days pass between the first attacks and a fix, and older PHP branches get no ready-made update. Without protection before the patch, switching off is the only option.
One flaw must not open everything
On shared hosting many sites share process, rights and network. In HostOps a hit stays contained to one site.
You must be able to prove what happened
NIS2 and customer contracts demand evidence. For each CVE we show when which system was protected.
From alert to evidence in four steps
Every production change goes through human approval. No blind mass updates.
Inventory
We record PHP versions, deployment mode and exposure of your sites. Only systems you own or have commissioned in writing.
Secure
Edge filter and hardening immediately, then move to supported, isolated containers.
Monitor
Round-the-clock detection; alerts flow into an incident process with clear ownership.
Prove
You receive a report per CVE: detected, protected, patched, with timestamps.
Four typical starting points
All four share one problem: PHP is everywhere, but nobody wants to patch at night for every flaw.
SMBs with WordPress or a CMS
Your site runs at a budget hoster. You want to know whether you are affected and an operator who reacts.
Agencies
Many customer sites, one liability risk. You need a committed response time and reports you can pass on.
Systems houses and resellers
You serve customers with mixed estates and want to offer the solution under your own brand.
Existing Intelego customers
We know your systems. We check them in a targeted way and harden them within your current support.
Evidence for auditors and customers
HostOps delivers the records: who detected, secured and fixed which flaw, and when.
Patch and vulnerability management with time evidence, support for the initial notification.
Technical measures documented, EU operation, support when reporting a breach.
Technical vulnerability management and change management with approval and log.
Data processing and response times in writing, not as marketing claims.
Resellers and agencies
You own the customer relationship, we run the operation. Your brand, your prices, our platform and response time.
White-label
Own branding, own domain for status and report pages.
One response for all
A single CVE response applies to all your customers at once.
Reports for your customers
Ready-made evidence per customer and incident, easy to pass on.
Four tiers — from self-test to operations
Start small and grow with your situation.
- Determine PHP version and deployment mode
- Assess exposure to PHP2Shell
- Plain-language recommendation
- Own systems or with written commission only
- PHP configuration hardening
- Edge filter (virtual patch)
- Memory limits and container boundaries
- Detection rules for shell spawns
- Final report with residual risk
- Isolated containers per site
- Supported PHP versions, pinned images
- Patch response with target time for critical flaws
- Hourly immutable snapshots
- Per-customer CVE report
- Optional: TLS via CertOps
- Own brand and reports
- Multiple end customers under one contract
- Unified CVE response
- Second-level support for your team
All prices excl. VAT, B2B. Current values are in the configurator. Patch-response times are targets and depend on upstream availability.
Frequently asked questions
Why does a WordPress update not help?
The flaw is in PHP itself and is triggered while the request is parsed, before WordPress or any plugin runs. A CMS update changes nothing. What matters is the PHP version and protection in front of PHP.
Am I affected?
Probably, if your site uses PHP. PHP 5.4 to 8.5 in all common deployment modes is affected. The quick check classifies your situation.
Is a filter or WAF enough?
It reduces risk considerably but is an interim measure. That is why HostOps combines several layers and leads you to a supported PHP version.
What about PHP 7.4 or 8.0?
Only source patches exist. We run such branches only temporarily and hardened, and plan the migration with you.
Do you check third-party sites?
No. We only check systems you own or that are covered by a written commission. Unsolicited scanning of third-party systems may be a criminal offence in Germany.
What happens after a compromise?
We rebuild from clean code and an immutable snapshot instead of cleaning up. You get an incident report that supports your notification duties.
Where does the data run?
In the EU. We conclude a data processing agreement with you.
Know where you stand
We check your PHP systems, secure them and show you the path
to an operation that survives the next flaw.