PHP2Shell: the question every company had to answer in October 2026
On 20 October 2026, the PHP project warned administrators that emergency fixes for two critical vulnerabilities were coming the next day. Details had leaked ahead of the planned disclosure. The flaws, CVE-2026-109618 and CVE-2026-109619, quickly nicknamed PHP2Shell, allow an unauthenticated attacker to execute code remotely on a server running PHP. On 21 October the PHP project published the fixes for its supported branches.
For any company with PHP somewhere in its estate, the first question was not technical. It was: where do we run PHP, and which versions? A marketing site on a managed host, an old customer portal, an internal tool someone built years ago, a WordPress instance on a forgotten subdomain. Companies that already scanned their systems continuously could answer within the working day. Companies that relied on an annual penetration test had to start by building an inventory, while the details of the attack were already public.
That gap is the clearest illustration of why scanning and penetration testing are not interchangeable. One tells you continuously what known weaknesses exist across everything you run. The other tells you, at a point in time, what a skilled attacker could actually do. A security programme that has only one of them is missing half the picture.
What a vulnerability scan does
A vulnerability scanner is an automated tool that inspects systems and compares what it finds against databases of known vulnerabilities. It identifies software and versions, open ports and services, missing patches, weak configurations and expired certificates, and reports each finding with a severity rating. Scans can cover the external perimeter (everything reachable from the internet), internal networks and servers, cloud configurations and container images.
The value of scanning is breadth and repetition. A scanner can check every asset it knows about, every day or every week, and flag a new issue as soon as a new vulnerability is published and matched to a system. That is what turns "a critical PHP flaw was announced this morning" into "these four servers are affected" without anyone doing it by hand.
Authenticated and unauthenticated scans
An unauthenticated scan looks at systems from the outside, as an attacker on the network would, without logging in. It sees exposed services and can often infer versions from banners and responses, but it cannot see what is installed inside. An authenticated scan logs in with credentials and inspects installed packages, configuration files and patch levels directly.
Authenticated scans are far more accurate for patch and configuration findings, and they matter for exactly the kind of case PHP2Shell represents. Many Linux distributions apply security fixes to their own packaged PHP builds without changing the upstream version number, which means a scanner reading only a version string from the outside can report a patched server as vulnerable, or the reverse. Looking at the actual package state avoids that.
Limits: false positives, no exploitation, no chaining
Scanners report what matches a signature, not what is actually exploitable. That produces false positives, findings that look serious but cannot be exploited in context, and occasionally false negatives, real issues the scanner cannot see. Someone has to triage the results, or the report becomes a long list nobody acts on.
More fundamentally, a scanner does not think like an attacker. It will not notice that a medium severity information leak on one system, combined with a weak password policy on another and an over privileged service account on a third, gives an attacker a path to the customer database. Chaining weaknesses into an attack path is exactly what a scan cannot do.
What a penetration test does
A penetration test is a controlled attack carried out by skilled testers, with the organisation's authorisation, against a defined scope. The tester uses tools, including scanners, but the core of the work is manual: understanding how the application or network works, looking for weaknesses that tools miss, attempting to exploit them, and trying to move from an initial foothold towards something that matters.
The output is evidence of impact. A good pentest report does not just list vulnerabilities; it shows the path an attacker took, what they could access, and how severe that is for the business. That is what makes a pentest persuasive to management and useful for prioritising: "an attacker could reach customer records from the public login page" is a different conversation from "47 findings of medium severity".
Scope, rules of engagement and test types
Every pentest starts with a scope (which systems, applications, networks or environments are in) and rules of engagement (when testing happens, what techniques are allowed, who to contact if something breaks). Common types include external network tests from the internet, internal tests simulating an attacker already inside, web application and API tests, cloud configuration reviews and social engineering exercises.
Tests also vary in how much the tester is told in advance. In a black box test the tester starts with nothing but the target; in a grey box test they receive some information or a user account; in a white box test they have documentation and sometimes source code. Grey box is common for applications because it uses limited time on what matters most rather than on discovery.
Limits: point in time, depends on scope
A pentest is a snapshot. It reflects the systems as they were during the test window. A new deployment the following week, a configuration change or a newly published vulnerability such as PHP2Shell is not covered by last quarter's report.
It is also only as good as its scope. A thorough test of the main application says nothing about the forgotten subdomain that was left out. This is why pentests work best on top of continuous scanning and an up to date inventory: the scan keeps the picture current and finds what is exposed, and the pentest goes deep where the risk is highest.
How often you need each one
Scanning should be continuous or close to it. External perimeter scanning, because that is what attackers see first, is typically run at least weekly and often daily, with immediate checks when a critical vulnerability is announced. Internal and authenticated scans are commonly weekly or monthly, depending on how fast the environment changes.
Penetration tests are periodic. An annual test of the main external surface and key applications is a common baseline, with additional tests after significant changes: a new product, a major release, a migration to a new cloud environment, or an acquisition. Customers and regulators sometimes set their own expectations; some security questionnaires ask specifically for the date and scope of the last pentest.
What ISO 27001 and ENS expect
Neither ISO 27001 nor ENS says "run a penetration test every year". Both require the organisation to know its technical vulnerabilities and deal with them, and both leave the choice of methods to the organisation's risk assessment. In practice, auditors look for evidence that vulnerabilities are being found regularly, assessed, fixed and verified.
ISO 27001 Annex A 8.8
Annex A control 8.8 of ISO 27001:2022, management of technical vulnerabilities, is the most direct reference. In summary, it expects the organisation to obtain information about technical vulnerabilities in the systems it uses, evaluate its exposure to them, and take appropriate measures. Control 8.29 adds security testing during development and acceptance.
An auditor testing 8.8 will typically ask for scan reports over a period, evidence of how findings were triaged, remediation records with dates, and proof that critical issues were handled within the timescales the organisation set itself. Pentest reports and their remediation tracking are strong supporting evidence, especially for internet facing applications.
ENS: what RD 311/2022 asks for
For readers outside Spain: the Esquema Nacional de Seguridad (ENS) is Spain's mandatory security framework for the public sector and its private suppliers, set out in Royal Decree 311/2022. Article 10 requires continuous evaluation of the security of assets, detecting vulnerabilities and identifying configuration weaknesses, and article 21 requires ongoing evaluation and monitoring to keep systems adjusted to the vulnerabilities and updates that affect them.
In Annex II, these principles are developed through specific measures, including op.exp.4 (maintenance and security updates), op.mon.3 (surveillance) and mp.sw.2 (acceptance and entry into service of applications). All three apply from the BASIC category upwards, with additional reinforcements at MEDIUM and HIGH. The CCN-STIC guides published by Spain's National Cryptologic Centre explain how each measure is expected to be implemented and audited.
What happens after the findings
Finding vulnerabilities is the easy part. The value of both scanning and pentesting depends entirely on what happens next: whether findings are prioritised sensibly, fixed by the right people, and confirmed as fixed. Auditors and attackers both look at that part.
Prioritising by real risk, not only CVSS
CVSS scores measure the technical severity of a vulnerability in general. They do not know whether the affected system is internet facing, whether it holds customer data, whether an exploit is circulating, or whether a compensating control blocks the attack. A critical score on an isolated test server can matter less than a medium score on the production login page.
Good prioritisation combines severity with context: exposure, the value of the asset, whether the vulnerability is being actively exploited, and what an attacker could reach from there. That is how a team with limited time decides what to fix this week and what can wait for the next maintenance window.
Remediation and retesting
Every finding needs an owner, a target date and a record of what was done. "Fixed" should mean verified: a rescan confirming the vulnerability is gone, or a retest by the pentester for findings that needed manual exploitation. Without that step, the record shows intentions rather than outcomes.
Retesting matters most for pentest findings, because the fix for an application flaw is often partial. A developer patches the specific input the tester used, and the same weakness remains reachable through another path. Most pentest providers include a retest of the original findings; it is worth making sure it actually happens.
Walking through PHP2Shell: detect, patch, restart, confirm
PHP2Shell is a useful worked example because every step of a sound response depended on scanning, and none of it waited for a pentest. The first step was detection: identifying every system running PHP, which versions, and whether each was reachable from the internet. According to the PHP project's guidance, as reported by Kaspersky, unpatched installations that process web requests were at risk across common setups, including PHP-FPM, Apache with mod_php and php-cgi.
The second step was patching. The fixed releases were 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Systems on PHP 8.1 or older, which no longer receive updates from the PHP project, had no patch to apply; the only real fix was an upgrade, which takes longer and needed a temporary mitigation in the meantime. Early guidance published by the SANS Internet Storm Center described disabling session.upload_progress.enabled as a partial mitigation while patches were rolled out.
The third and fourth steps are the ones that get skipped. Installing a new package does not replace PHP processes that are already running: PHP-FPM or the web server has to be restarted so the patched code is actually loaded, and the version confirmed afterwards. Then a rescan, ideally authenticated, confirms that each system is no longer vulnerable. That is the evidence an auditor will ask for, and the assurance a customer will want.
Qalea's platform continuously scans the external attack surface and internal systems, flags exploitable vulnerabilities and prioritises them by real risk, with a remediation plan for each. Qalea's team adds penetration testing where depth is needed and follows findings through to confirmed remediation. The external attack surface post covers how exposed assets are discovered in the first place, what a certification audit actually tests explains how this evidence is reviewed, and the attack surface and pentesting topic page collects the rest of the series.
