Check a public website, review local configuration and logs, or find maintained response tools. Each result explains its evidence and its limits.
01 / URL
Check your website
Enter your own public website. We inspect one page and up to two redirects for PHP headers and platform clues. This does not test exploitation.
PHP / ?
Not sure which PHP you use?
WordPress: open Tools > Site Health > Info > Server and record the PHP version privately. A control panel: select the exact domain and its PHP handler, not the panel’s default. With SSH, compare php -v with the FPM or Apache service and container actually serving that domain. Different sites, command-line jobs and replicas can use different versions. Do not publish a phpinfo page.
02 / LOG
Review suspicious log signals
Paste an excerpt or choose a text file. We highlight memory errors, worker crashes, HTTP errors and unusual PHPSESSID values using counts and line numbers. Matches do not prove intrusion, and no matches do not rule it out.
Was it an attempt, or a successful intrusion? →03 / PHP INI
Review PHP configuration
Paste relevant php.ini or FPM pool settings. This reviews text only: it cannot see inherited values, request overrides or prove that a setting is active. These measures never replace patching.
Memory controls and recycling have limits →GitHub response directory
OpenAI PHP checker
Apache-2.0. A Node.js version-inventory helper for local systems or public headers, with JSON output. Read the README before running it on authorized assets. Hidden headers, vendor backports and CLI/Web differences limit its conclusions. It does not certify that a site is unexploitable.
openai/php2shell-checker ↗Corelight Zeek / Suricata rules
BSD-3-Clause. Defensive network rules; Zeek 7+ supports request/session correlation and separate version inventory. Installing the Zeek package does not install Suricata rules. Validate the sensor configuration, TLS visibility and false positives. Set notice_body_sample_bytes=0 if notice samples would expose sensitive content.
corelight/php2shell-detect ↗NCSC-NL response information
EUPL-1.2. Maintained incident-response information and affected-software inventory, useful for assigning owners and tracking vendor fixes. It is not a fleet scanner and the list may be incomplete. Retain your own package and deployment evidence.
NCSC-NL/php2shell ↗Trivy container and SBOM review
Apache-2.0. General image/package inventory and vulnerability tooling. Useful for finding embedded PHP packages and reviewing rebuilt images. Detection depends on the vulnerability database, package identification and vendor data; do not assume a clean report specifically proves both PHP2Shell fixes.
aquasecurity/trivy ↗Composer audit
MIT. Reviews advisories for Composer-managed application dependencies. Use it as an additional application check. The PHP interpreter is not a Composer library: a clean composer audit does not patch PHP, inspect a host or rule out this incident.
composer/composer ↗Syhunt Apache mitigation examples
MIT. Community examples of request restrictions and multipart blocking. These cover selected paths, can break uploads and require testing. Apache php_value examples do not apply unchanged to CGI/FastCGI. Treat them as reviewed temporary controls, never as complete protection.
syhunt/php2shell-protection ↗Can a free scanner tell me whether I was hacked?
Not conclusively. Public headers can suggest a version, and local log rules can surface clues. Neither sees the full runtime, missing history or memory-only disclosure. Start with the guided inventory, preserve available evidence and correlate logs. If there are unauthorized accounts, unexpected processes or unexplained sensitive-data exposure, isolate and involve your host or incident team.
Ask your host for evidence, not reassurance
Please confirm whether the PHP Web runtime for my domain has fixes for BOTH CVE-2026-109618 and CVE-2026-109619. Please provide the full package/build revision, vendor advisory or changelog, and confirmation that every relevant FPM/Apache worker, container replica and long-running process was replaced or restarted. Also confirm whether you can review retained access, PHP and process logs for suspicious activity.Primary sources & further reading
PHP security teamRead the original ↗CVE-2026-109618Read the original ↗CVE-2026-109619Read the original ↗Research & practical guides
PHP2Shell tools
Check a public website, review local configuration and logs, or find maintained response tools. Each result explains its evidence and its limits.
01PHP2Shell in plain language
PHP is the engine running your website; WordPress, Laravel and plugins sit above it. Updating a plugin does not update PHP. Two runtime memory-safety flaws can turn abnormal request cleanup into disclosure or code execution. A public website check can find clues, but only the host or server administrator can verify the actual Web runtime and its patch.
02Was it an attempt, or a successful intrusion?
An unusual multipart request or a WAF alert can indicate an attempt. OOM messages, SIGSEGV/SIGABRT and bursts of HTTP 500 can also have ordinary causes. Unexpected PHP child processes, outbound connections, modified files or unauthorized accounts warrant urgent investigation, but attribution still needs evidence. Memory disclosure may leave no webshell or new file. A clean file scan cannot rule it out.
03Preserve evidence before changing the host
Record discovery time, domain, instance, runtime, current symptoms and the last known good state. Export original access/error/WAF and process logs with their timezone; preserve cloud audit records and authorized disk or memory snapshots when available. Store copies with restricted access and hashes. Do not upload cookies, tokens or customer data to public scanners. Avoid clearing logs or deleting suspicious files before evidence is captured.
04Reading Wiz and Calif without overgeneralizing
Wiz and Calif explain why request-lifecycle failures can outlive the request that caused them. The official advisory for CVE-2026-109618 demonstrates mod_php RCE; FPM susceptibility is source-based, without a complete demonstrated FPM exploit for that CVE. CVE-2026-109619 separately confirms an application-dependent FPM upload-progress path. Read each GHSA for its precise evidence instead of treating every SAPI as an identical proven exploit.
05Cloudflare: why response visibility matters
Cloudflare describes full-transaction detection using both request and origin response, allowing a matched response to be blocked before potential data leaves the proxy. This is useful for disclosure paths that do not launch a shell. The article’s rollout time is a historical snapshot, not a guarantee for your account: verify rule availability, routing, exclusions and event logs. Direct-origin paths and unproxied hosts still need patching and review.