How attacker target selection changes PHP2Shell exposure priorities

The PHP2Shell campaign reports are useful beyond the patch list. They show how an attacker may choose targets: collect public PHP banners, drop hosts that advertise fixed versions, avoid heavily filtered networks, rotate scanning nodes and keep activity slow enough to avoid rate-based alerts.

CYFIRMA captured a 216-host list and described operator claims of an expansion to 581 hosts. The captured figure is targeting evidence, not a list of confirmed victims. The operators reportedly used older PHP appearances and filtering behavior as selection clues. CYFIRMA also reported that nodes showing filtering or rate limiting were pulled from the active set.

The vulnerabilities are CVE-2026-109618 and CVE-2026-109619, both unauthenticated RCE flaws rated CVSS v4.0 9.2. PHP fixed them in 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21, 2026. The selection logic does not change the patch requirement. It does change how an organization should read its external exposure and detection signals.

What a broad product query can reveal

An all-scope ZoomEye query for app="PHP" returned 111,119,160 product-fingerprint observations at 2026-11-09T15:46:24Z. The result shows that PHP is widely visible as a product surface. It does not show which hosts advertise old versions, which are behind filtering or which have been patched.

That limitation is useful. It prevents teams from turning a broad search into an unsupported victim claim. It also shows why an attacker can use external reconnaissance at scale without having a precise vulnerability count. The attacker can rank candidates, test a few, and move on when a response looks uninteresting.

Use the external query to identify owned PHP services and to check for changes in their public behavior. Pair it with internal version and worker evidence. A service that stops advertising PHP is not necessarily fixed. A service that continues to advertise PHP may be fixed but still expose a version string.

Detection should assume rotation

CYFIRMA reported that the campaign used compromised scan nodes, low-volume pacing and node rotation. A detection program built around one source address will miss a campaign that moves to another node. A program that only counts requests will miss a slow scan spread across many addresses.

Behavioral signals become more useful:

• Repeated weakness checks across unrelated applications
• Small request volumes that change source addresses
• Probes that stop after a filtering response
• Multipart or upload-progress patterns outside the application baseline
• Origin failures or process events tied to the same request family

These signals still need a baseline. A membership site may accept multipart uploads all day. An internal API may never accept them. The alert should compare the request with the service's normal role.

Use filtering as a risk decision, not a disguise

Rate limiting and WAF rules can make a target less attractive. They can also reduce the chance that an attacker reaches a vulnerable path. Neither effect means the origin is fixed.

Cloudflare reported that it deployed PHP2Shell protections ahead of disclosure and continued updating them as payloads changed. Keep edge controls running while patching, with the understanding that they supplement a fixed origin. Attackers can find alternate routes, and a protected site can still be reached through an unproxied origin.

For exposed PHP, use filtering to buy time and to collect evidence. Use patching and worker replacement to remove the vulnerability. Use segmentation to reduce the number of paths an attacker can test.

Reduce the target set without hiding the problem

An organization can reduce unnecessary exposure by:

• Removing public access to administrative PHP interfaces
• Restricting upload endpoints to the sites that need them
• Keeping old PHP versions out of new deployments
• Removing development and test handlers from production
• Limiting request sizes and multipart complexity at the edge and origin

These controls change the attack surface. They should not be described as deception or as proof of security. If a host still serves a vulnerable PHP build through another route, the target remains relevant.

Build a better feedback loop

The attacker's selection process gives defenders a feedback loop. When a probe reaches an owned service, the team can ask whether the service actually needs to be public, whether the runtime is fixed, whether the worker was restarted and whether the edge logged the transaction.

The external product query supplies the map. The origin telemetry supplies the behavior. The asset owner supplies the decision. This is a more useful model than waiting for a confirmed victim report, because it lets teams act on exposure before compromise is established.

PHP2Shell also tests how accurately an organization can see its exposed runtime. Broad product visibility helps, but it becomes valuable only when it leads to version verification, worker replacement and evidence of a closed path.

References

• CYFIRMA PHP2Shell threat advisory
• Cloudflare PHP2Shell WAF research
• PHP security advisory and release archive
• CISA critical PHP advisory