pH7Builder administrators can use this checklist to compare their recorded release with four CNA version-status records. pH7Builder is a PHP social CMS, not WordPress. The records are useful for maintenance prioritization, but they do not establish the state of any particular installation. Across these four records, 19.3.0 is the highest observed unaffected boundary. It is not a statement that 19.3.0 is the latest release, a supported or compatible release, or a universal fix.
Start with an inventory
- Record the installed pH7Builder release, deployment owner, and the normal maintenance window used by your organization.
- Identify public pages, member sign-in and registration where enabled, account functions, member-data workflows, and integrations that should be checked after an approved change.
- Confirm that ordinary recovery arrangements and change approval are available before beginning maintenance.
- Use the organization’s normal vendor, hosting, and change-management process to decide whether a change is appropriate.
The relevant version boundaries are CVE-2026-108902 and CVE-2026-108904 for versions below 18.5.0, CVE-2026-108905 for versions below 18.6.0, and CVE-2026-108903 for versions below 19.3.0, with 19.3.0 marked unaffected in that record. The CNA records reviewed do not establish active exploitation. A separate current CISA KEV catalog read did not list these four identifiers, but absence from that catalog cannot prove that exploitation has not occurred.
Prioritize the review
Give priority to systems that expose member-facing functions or process sensitive member information, then consider the operational importance of the service and the organization’s ability to test it safely. The records retain different conditions and impact descriptions, including authenticated low-privilege conditions for two records and no-privilege conditions for two others. That information helps frame a review; it is not an exposure assessment, a compromise finding, or a protection claim.
Make and verify an approved change
- Choose a maintained, compatible release through the organization’s approved process; do not treat the observed 19.3.0 boundary as a compatibility guarantee.
- After the change, verify the public pages and the member and account workflows the organization actually operates.
- Check expected member-data behavior and review ordinary application and authentication records for unexpected activity.
- Use the established incident process if evidence needs investigation. A version change by itself does not prove compromise or safety.
Communicate with customers responsibly
Tell affected stakeholders what was reviewed, what was changed if anything, the verification scope, and any follow-up owner. Avoid saying that all customers are unaffected or protected unless that conclusion is independently supported. If you need WordPress help, see our separate WordPress support services; they do not make pH7Builder a WordPress product or promise pH7Builder support.
Sources and related guidance
Use the official pH7Builder release index as a release listing, not as a support, compatibility, or CVE-fix claim. Browse related PHP guidance and security guidance.
Illustration: server administrator reviewing a completed Linux security maintenance check in a data center; not a pH7Builder interface or proof of protection.
