PHP Site AuditLinux distributions
How do RHEL, Rocky, and AlmaLinux owners verify PHP package fixes?
Red Hat commonly backports security fixes while retaining an older upstream version, but that policy does not establish the status of every RHEL-like distribution, repository, module stream, or third-party PHP build. Identify the exact vendor, OS release, PHP stream and installed package revision; check that vendor’s CVE advisory and update metadata; then verify installation and restart of the process serving the site. Treat missing or ambiguous package evidence as unknown.
Understand Red Hat backport numbering
Red Hat explains that backporting applies a security correction to a package version it already distributes. As a result, a vendor package can contain a fix while its embedded upstream PHP version appears older than the upstream fixed release. Red Hat recommends using its security advisories and CVE references to understand how a specific issue was addressed, rather than deciding from the version string alone.
Do not generalize across derivatives
That practice is not a blanket statement that every compatible or derivative operating system receives the same patch on the same schedule. Rocky Linux, AlmaLinux, third-party PHP repositories, control-panel builds, and custom images have their own package production and advisory processes. The exact package, repository, enabled module stream, and OS release matter. Do not declare a fleet fixed because one RHEL advisory exists or because a sibling distribution has published a notice.
Trace the package to an advisory
Collect the OS name and release, architecture, enabled PHP module stream or repository, package name and full installed release string, and whether the site runs from a container. Search the distribution’s own security page for CVE-2026-109618 and CVE-2026-109619. Confirm whether the advisory marks the exact package stream as affected and fixed, and note the update package or errata reference. If you use a derivative, consult that project’s advisory rather than inferring its status from Red Hat’s record.
Request package-specific evidence from its maintainer
For a managed hosting panel or third-party repository, ask its maintainer for a statement tied to the exact package build and supported OS release. The support response should name the patch or advisory, package revision, repository, affected environments, install time and any required service activation. If the vendor cannot match the installed package, record that gap and seek an authoritative escalation instead of translating the upstream version into a yes/no answer.
Record only the scope evidence supports
After installation, verify the package inventory on each web-serving node or confirm the deployed image digest. Then identify the process manager and restart or replace the handler using its documented procedure. Separate CLI PHP from PHP-FPM, Apache modules, LSAPI handlers, container tasks and background consumers where they are independently deployed. The package manager may report the package updated while a long-running process continues to use mapped code from before the upgrade.
Attach the inventory and restart evidence to the change record, along with application smoke checks and any region or node that remains outstanding. A public HTTP response can help show the service remains available after rollout, but cannot validate an RPM’s contents, prove which repository built it, or show that all nodes are covered. Report fixed only for the package scope backed by evidence; mark unsupported streams and unconfirmed builds as unresolved or unknown.
For images rebuilt from a vendor base, retain the image build date and digest in addition to the host package query. A container may be running an older immutable image even after the underlying host received updates. Ask the build owner to publish and roll out a new artifact, then check deployment inventory rather than assuming a host-level package update changed the container.
Common questions
Can an older PHP version be patched on RHEL?
Yes. Red Hat documents backporting, so use the matching advisory and package revision instead of upstream version comparison alone.
Does Red Hat’s advisory automatically cover Rocky or AlmaLinux?
No. Check the derivative’s own advisory and exact package stream; do not assume identical builds or release timing.
What if PHP came from a third-party repository?
Ask that repository or hosting vendor for package-specific evidence and confirm the installed source and revision.