If your website needs a PHP upgrade, a developer and whoever manages the hosting may be enough. If there are signs of unauthorised access, you need incident-response expertise as well. Those are different jobs, and the distinction matters before you write a recruitment brief.
October's PHP2Shell disclosure has made that decision urgent. It has also exposed a less technical problem: a business can pay an agency to maintain its website without knowing who is responsible for the software underneath it.
First, what actually happened?
PHP2Shell is the name given to two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. They can allow attackers to run code on an affected server without logging in. Despite the “PHP virus” description circulating in discussion, this is a software vulnerability issue, not one particular virus.
The UK National Cyber Security Centre advises organisations to find affected PHP installations, apply updates and investigate possible compromise. That includes PHP inside third-party products. Updating a WordPress theme, for example, does not establish that the underlying PHP runtime has been fixed.
Sophos took a portal offline. That isn't the same as a confirmed breach.
Sophos's 22 October advisory offers a useful UK-linked example. Its legacy MyUTM licensing portal used an affected PHP version. The company took the portal offline on 21 October and was updating it before bringing it back.
At that point, Sophos said its continuing log review had found no evidence of exploitation. Its products were not affected.
The important detail is the separation of work: stop exposing the service, update it, and review the evidence. A patch addresses the vulnerability. It doesn't, by itself, tell you whether somebody accessed the system beforehand.
Before hiring anyone, send your supplier these questions
For an agency-managed site, ask for a written answer to four things:
- Which services have you checked? Include customer portals, staging sites and older applications, not just the main domain.
- Who owns the PHP update? Name the hosting provider, agency or internal engineer responsible.
- How was the live service verified? Ask for the relevant vendor fix and confirmation that running services use it.
- What remains unresolved? Include failed tests, unavailable logs and any investigation still underway.
This is a proposed supplier checklist, not a substitute for a security assessment. Its purpose is to stop “we're looking into it” being mistaken for completion.
Match the person to the problem
- The application breaks on a supported PHP version — Expertise to assess: Senior PHP developer: dependency upgrades, framework compatibility and regression testing
- Nobody can confirm what runs on the servers — Expertise to assess: Linux or cloud engineer: PHP-FPM, hosting configuration, deployed packages and service restarts
- Logs or files suggest unauthorised access — Expertise to assess: Incident-response specialist: investigation, evidence preservation and recovery planning
- Every urgent update becomes a manual scramble — Expertise to assess: DevOps or platform engineer: maintained images, repeatable releases and clear ownership
A useful developer interview goes beyond “Have you used Laravel?” Ask what they tested after a runtime upgrade. Sign-in, uploads, scheduled tasks and enquiries can fail even when the homepage looks normal.
For a contractor, define the finish line: supported runtime, agreed tests passed, outstanding risks recorded and a handover the permanent team can use. If nobody will own updates after that handover, the longer-term requirement may be a permanent hire.
Don't wait for recruitment to contain an active incident. Use qualified response support immediately where needed.
Pearson Carter helps UK employers recruit software, cloud and DevOps professionals. Bring the technical gap and the responsibility you need someone to take on—not just a list of technologies.
Sources reviewed 23 October 2026. Security advisories may change; follow current vendor and national-agency guidance.