ModelGain PHP Security Monitor

ModelGain PHP Security Monitor provides conservative PHP vulnerability evidence, optional scheduled checks, and actionable hosting-side remediation guidance. It does not modify PHP or promise continuous protection.

Tools > PHP Security shows the PHP_VERSION and PHP_SAPI serving the actual admin request. It never executes shell commands, displays phpinfo, probes exploits or changes PHP configuration.

After explicit opt-in, Check now retrieves WPVulnerability’s PHP branch advisories and lifecycle. The plugin locally applies both minimum and maximum version predicates; the API returns the entire branch history, not only advisories affecting your exact version.

A matching upstream version is labelled potentially affected, never confirmed exploitable. Operating system, SAPI, extensions, application usage, configuration and vendor backports may change applicability. Advisory severity is not a measure of verified server exposure. No matches are not a guarantee of security. App-level code cannot independently verify distributor backports.

Lifecycle is provider-reported, separate from vulnerability severity and applicability. There is no bundled offline lifecycle table: without usable evidence it is unknown. Consult https://www.php.net/supported-versions.php and your hosting provider for independent support/build information.

The copyable host-support report includes evidence, timestamps and questions about package/backport status and conditional applicability. It is never sent by the plugin. Remediation belongs with the hosting provider; updating WordPress cannot patch the PHP interpreter. Test compatibility in staging before changing PHP, then recheck the web runtime.

Optional monitoring requires separate explicit scheduled-query AND email consent after manual consent. WP-Cron checks approximately every six hours; traffic, disabled cron or failures may delay checks indefinitely. CLI/phpdbg cron is skipped because it cannot establish the web runtime. The first complete fresh scan establishes a baseline and sends one initial alert when potential vulnerability matches or upstream EOL exist; an initial scan without these findings is silent. Later fresh state changes send event summaries for new potential matches, records no longer matched/listed (not proof of a fix), and upstream EOL. Unknown/partial evidence never proves resolution. After 48 hours without fresh evidence, one failure alert is attempted per incident, rearmed only by fresh evidence. A cron outage cannot notify about itself.

Emails use core wp_mail and go only to the site administration address. True means accepted by the transport, NOT delivered. Check inbox/spam and configure WordPress mail independently. Automatic attempts are claimed before sending: failed or interrupted sends are not retried, preventing spam but potentially losing an alert. Use the administrator Test email button (once per minute). Tools > PHP Security shows last run, freshness, next scheduled check and last mail status. Disable monitoring cancels its schedule and email state while retaining manual consent; deactivation disables it too.

There is no automatic update/fix mechanism, telemetry, account, SaaS dependency, paid feature or custom database table. Normal WordPress core update behavior is unchanged.

External services

WPVulnerability manual queries are disabled by default. After explicit opt-in, Check now sends the actual web PHP version to https://www.wpvulnerability.net/php// and exposes the server IP and a generic plugin User-Agent to that provider. This plugin does not send the site URL, administrator details, cookies or credentials. Separate monitoring AND email consent permits scheduled queries to the same fixed endpoint. Core wp_mail sends event/test notifications only to the site administration address; acceptance does not prove delivery. Activation and page views never initiate requests or emails.

Service: https://www.wpvulnerability.net/
API documentation: https://docs.wpvulnerability.com/
Provider privacy: https://www.wpvulnerability.com/privacy/

Enabling queries alone does not send a request. Withdraw consent to delete this site’s stored evidence. Withdrawal also cancels monitoring and removes notification state. Consent is rechecked after HTTP and before sending. No new query or email is initiated after withdrawal is observed; already in-flight HTTP/mail cannot be recalled.

Cache and limitations

• Manual queries and separately opted-in scheduled queries, at most once per minute, with atomic owner-checked request locks.
• Eight-second HTTP timeout, no redirects, verified HTTPS via the WordPress safe HTTP API.
• Response strictly below 1 MiB, at most 1,000 advisory records.
• One non-autoloaded snapshot per site, bound to the exact PHP_VERSION. An upgrade invalidates the old snapshot.
• Both retrieval time and provider update time must be less than 24 hours old for fresh evidence. From 24 hours results are stale; at seven days they are expired and unusable. Expired bytes can remain stored until another check, consent withdrawal or uninstall; there is no background cleanup.
• HTTP/JSON failures preserve usable last-good evidence but label it stale, not current. Invalid/unsupported ranges or incomplete evidence count as unknown, not clean. Malformed envelopes and unsupported runtime strings produce unknown evidence.
• Conditional advisory descriptions are displayed for host review, not automatically inferred as confirmed applicable or inapplicable.
• Only a stable upstream version is compared. Vendor suffixes do not prove backports; unrecognized/prerelease versions cannot be checked.
• A web request cannot identify every node in a load-balanced fleet or another CLI PHP binary.