When a critical vulnerability is announced, the first question is straightforward: Where are we exposed? Answering it can be harder than applying the patch. An organization may have a current server inventory while overlooking an older website, a temporary cloud deployment, or an application maintained by a contractor.
The newly disclosed PHP vulnerabilities make that discovery work urgent. Censys can help teams find externally visible PHP services and build a prioritized investigation list. Determining whether those systems are vulnerable requires confirmation of the deployed software, configuration, and patch status.
What the PHP Announcement Means
On October 21, 2026, the PHP project released security updates for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities rated CVSS 9.2 that can allow remote code execution without authentication.
PHP identifies installations serving web requests as at risk, including PHP-FPM, Apache mod_php, PHP-CGI, FrankenPHP, and LiteSpeed. It considers mod_php the highest risk, with demonstrated exploitation before application code runs.
The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Organizations using distribution packages should verify whether their vendor has supplied backported fixes. PHP states that updating is the only complete solution; temporary configuration changes reduce specific attack paths without fully resolving the vulnerabilities.
Finding Exposed PHP with Censys
Censys has published discovery queries for this announcement. Its Platform query searches for PHP software observations across hosts and web properties:
host.services.software: (vendor=”php” and product=”php”) or web.software: (vendor=”php” and product=”php”)
Platform users should scope their investigation to assets their organization owns or is authorized to assess. A broad internet search is not an organization-specific vulnerability report.
For customers using Censys Attack Surface Management, the advisory provides a separate query for searching their ASM inventory:
host.services.software.product=”PHP” or web_entity.instances.software.product=”PHP”
These queries identify observed PHP deployments for investigation. They do not establish that either vulnerability is exploitable on every returned asset.
Compare the findings with internal records. Does each asset have an owner? Is it still required? Who patches it? An unexpected result could reveal a gap in the response plan, particularly when responsibility is divided among application teams, infrastructure teams, and service providers.
Turning Discoveries into Remediation
A practical response should connect each finding to a verified outcome:
- Validate ownership and freshness. Confirm that the asset belongs within your assessment scope and review when Censys observed it. Resolve uncertain ownership before assigning remediation.
- Check the running environment. Ask administrators or hosting providers to verify the PHP runtime actually serving requests, its configuration, and the installed package’s security status. A command-line PHP version may differ from the runtime used by the website.
- Prioritize by exposure and consequence. Address reachable systems supporting sensitive data, authentication, or essential services promptly. Record dependencies that could complicate an update.
- Apply the fix. Install the supported PHP update or vendor-confirmed patched package. Where immediate patching is impossible, evaluate restricting access or temporarily removing exposure while arranging remediation.
- Verify closure. Confirm that the patched runtime is active, test application functionality, and compare refreshed external observations with internal evidence. Keep an accountable owner until closure is documented.
Censys ASM also provides CVE risk context for detected software, with some enrichment depending on subscription level. Teams should check current coverage and configuration before assuming a dedicated finding exists for these two CVEs.
Understanding the Visibility Limits
External observations provide useful leads, but hidden version information, reverse proxies, and content delivery networks can obscure the underlying runtime. Vendor backports can also make an apparently older version fully patched. Conversely, a missing PHP fingerprint does not establish that PHP is absent.
For that reason, combine external discovery with authenticated assessment, software inventories, and application-owner validation. Internal services and embedded PHP dependencies require attention even when they do not appear in an external search.
Know What’s Exposed. Take Action with Confidence.
Identifying potentially vulnerable assets is only the first step. RavenTek helps organizations turn external attack surface visibility into actionable security priorities, connecting discovery, validation, and remediation to reduce risk.
Contact RavenTek to discuss your organization’s external exposure and vulnerability management strategy.
