Who patches my website: your host, your agency or you?

Whoever operates a layer patches that layer, and your plan or contract decides who that is. On shared and managed hosting the host usually patches PHP and the server, and you patch the CMS, plugins and your own code. On a VPS the runtime is yours. If an agency maintains the site, its agreement should name each layer. Write the split down this week.

Who is responsible for each layer of my site?

Hosts describe their split in their own words, and the words differ. The matrix below says what each model usually covers per those documents. Where a document is silent, the cell says to check your plan's terms. That is a real answer: silence is where disputes start.

Sources: Kinsta's roles table and PHP docs, WP Engine's PHP guide, Shopify's TLS page, checked 23 October 2026.

Does my host patch PHP, or do I?

On shared plans, the host. During PHP2Shell, Namecheap reported fixes on all shared servers and told VPS and dedicated owners to update their own. OVHcloud said shared hosting gets an updated PHP component automatically while VPS and Bare Metal customers patch and restart. SiteGround said no customer action was needed. All three are the vendors' own statements.

Two details move the answer back to you. First, a pinned version: SiteGround's KB says a manually chosen PHP version is not updated for you. Second, the plan: a managed WordPress host patches its infrastructure, but Kinsta's roles page lists plugins and themes as yours and does not mention PHP security fixes. Ask, and see how managed WordPress hosts compare on automatic patching.

What does my agency owe me?

What the agreement says, and nothing the agreement does not. A maintenance retainer might cover updates to the CMS and plugins, a monthly check and a restore test. It rarely covers the host's runtime, because the agency does not run it. If the agency chose and manages the hosting, the answer changes.

Ask for three things in writing: which layers it patches, how fast it acts on a critical advisory, and what evidence it gives you afterwards. "We patched immediately" is a claim. A package name and a restart time is evidence. Our 10-minute response guide has a client note you can adapt, and agencies running many sites can use the client triage list.

What if the host patched but my site is still exposed?

The host's patch closes one layer. Four things remain yours on almost every plan:

• Plugins, themes and CMS core. Outdated components stay outdated whatever PHP does.
• Keys and passwords. AWS saw PHP2Shell attempts from 17 October, four days before the fix (vendor telemetry). If your site was reachable on an unpatched runtime then, treat stored credentials as possibly read and rotate them.
• Old backups. A backup taken before the patch can contain whatever was planted. Restoring it brings that back unless you also close the hole.
• Pinned or custom runtimes. Your own container, or a version you chose by hand, is not on the host's fleet. See fix and patch PHP, and list every PHP runtime you run.

Who is liable when it goes wrong?

This is not legal advice, and general rules differ by country. What we can say is where to look. Contract language usually sits in three places: the host's terms of service, the host's service-level terms, and your agreement with any agency. Read for limits on liability, what counts as customer content, and whether the host has any duty to monitor or update what you run. Kinsta's roles page, for one, makes the customer responsible for content and plugins. A client contract that names your duties and the client's (such as approving updates) is worth more than a general policy. For a real dispute, ask a lawyer. The contract clauses that split blame between client, agency and host have their own page.

How do I write the responsibility down?

One page, per site, agreed by everyone who touches it.

• Host and plan name, and who holds the account login
• Who patches the PHP runtime, and how they will prove it (build name and restart time)
• Who updates CMS core, plugins and themes, and how often
• Who owns custom code and any container image
• Who owns DNS, the registrar login and TLS renewal
• Where backups live, how old they are, and who tests a restore
• Who watches for trouble and who is called first
• Which support question you will send the host, kept with the reply (see sample questions for shared hosts)

Am I covered? Who can give you each state

For the full PHP2Shell fix list, see PHP2Shell: affected versions and fixes. For the wider picture, see the late-2026 landscape report; more broad-view pieces are in the landscape guides.