PHP2Shell: preventive protection with Airlock

On 21 October, technical details of two critical PHP vulnerabilities were published under the name PHP2Shell. The first attempts to exploit them were observed that same day. The incident shows how quickly attacks can begin after a vulnerability is disclosed, and how important it is to have a reliable WAF that provides preventive protection.

Airlock is not affected

Airlock Gateway, Microgateway and IAM were not affected, as they do not use PHP. Our focus was therefore on protecting our customers’ PHP backends.

How does Airlock protect PHP backends?

Our tests showed that Airlock Gateway and Microgateway blocked the attacks we tested in their default configuration. More than half a dozen independent protection mechanisms, including Deny Rules, limits and parameter normalisation, came into play. No PHP2Shell-specific rules were needed.

Airlock provides defence in depth: many attacks are blocked completely, while in other cases valuable time can be gained to apply security updates. Preventive protection is particularly important right now. Reactive measures may come too late when attacks begin immediately after—or even before—a vulnerability is disclosed.

AI is making the situation more challenging still: it accelerates both the development of exploits and the discovery of vulnerabilities.

Why Airlock also provides specific protection rules

Despite effective WAF mitigations, PHP2Shell still carries residual risk from previously unknown exploit variants. The vulnerabilities therefore need to be fixed by updating PHP.

To reduce the remaining risk further in the meantime, we have made specific PHP2Shell protection rules available to our customers for virtual patching with Airlock.