Open24 Security

變更記錄

1.3.0

• Added: PHP version check. The settings screen shows the PHP version and whether it has known security flaws: the “php2shell” remote code execution flaws (CVE-2026-109618 and CVE-2026-109619, fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35), branches that no longer receive security fixes (8.1 and older), a branch close to its end of support, and session.upload_progress.enabled still on while CVE-2026-115560 has no fix. An optional setting, off by default, also shows a notice to administrators across the admin, adds a Site Health check and sends a daily alert email when there is a problem.
• Added the o24s_php_branches filter to update the list of fixed PHP versions without waiting for a plugin release.
• Tested with PHP 8.5.
• Fixed: with “Disable the /wp-json/ index” on, every WP-CLI command printed PHP warnings from WooCommerce and the wp wc commands were missing. WP-CLI is now exempt from that restriction.

1.2.0

• Added: administrator account protections. Block the admin file editor, block installing and uploading plugins and themes (updates keep working), disable application passwords, limit how long administrator sessions last, restrict administrators to a list of IPs or CIDR ranges, and reject leaked passwords with Have I Been Pwned. All of them apply to administrators and WooCommerce shop managers.
• Added: email alerts when an administrator signs in from a new IP or with a non-browser user agent, when a correct administrator password is used from a blocked IP, and on sensitive actions: plugin or theme installs, activations, deactivations and deletions, saves from the admin file editor, new administrator accounts, role changes, settings changes and deactivation of this plugin.
• Added: activity log of those actions with IP and user agent. The log now keeps 500 entries and is no longer loaded on every request.
• Added: daily file integrity checks: WordPress core and wordpress.org plugins against their official checksums, and a change watch for themes, mu-plugins, drop-ins and other plugins. Results, an on-demand run and a way to accept legitimate changes are in the settings screen.
• Added: configurable Content-Security-Policy for the storefront, report-only by default, with the browser reports collected in the settings screen.
• Added: Active sessions tool to see and close the open sessions of administrators and shop managers.
• Added: O24S_LOCK_SETTINGS constant to lock the settings from wp-config.php, and O24S_DISABLE_IP_RESTRICTION to get back in after an IP change.
• Added filters: o24s_is_privileged, o24s_admin_ip_allowed, o24s_allow_cron_request.
• Every new option is off by default. Nothing changes on existing sites until you turn something on.

1.1.2

• Fixed: “Require auth on sensitive endpoints” could be bypassed. The check looked for allowed routes anywhere in the request URL, query string included, so adding something like ?x=/oembed to a protected /wp/v2/ route let an anonymous request through. Requests made with ?rest_route= instead of /wp-json/ were not checked at all. The plugin now checks the route WordPress actually dispatches, regardless of how it was requested.
• Fixed: the same ?rest_route= gap in “Reject anonymous requests to /wc/v3/”.
• Fixed: “Block external wp-cron.php” stopped WP-Cron altogether on most hosts. WordPress triggers its own cron with an HTTP request to its public URL, which arrives from the server’s public IP or from Cloudflare, not from 127.0.0.1, so it was being blocked as external. The internal request is now recognised by the one-time lock value WordPress sends with it, which an outside caller cannot know. A system crontab on the same server is also allowed, and the new o24s_allow_cron_request filter covers anything else, such as an external uptime service you trust.
• Fixed: with the custom login URL enabled, logging out stopped the request inside wp_logout. Any redirect_to was ignored and other plugins hooked to wp_logout, such as WooCommerce, did not get to run. Logging out now finishes normally; without an explicit destination it still lands on the home page instead of the blocked login screen.
• Changed: an anonymous request that reaches /wp-admin/ while the custom login URL is enabled now gets the same 404 or “Restricted access” response as wp-login.php, instead of a redirect to the custom login slug.

1.1.1

• Fixed: “Hide the WordPress version” no longer strips the ?ver= parameter from script and style URLs. That parameter is how WordPress tells browsers and CDNs to fetch an asset again after it changes; removing it meant an updated theme or plugin could keep serving the old cached file indefinitely. On themes that load webpack chunks the result was a broken front end, because the chunks are requested outside wp_enqueue_script and did arrive updated, leaving a stale bundle trying to resolve new module IDs. The option now only hides the generator meta tag and the version in feeds, which is what its name promises. No action is needed after updating: asset URLs go back to normal on their own.
• Fixed: the login attempt limiter could be bypassed. The visitor IP was taken from the CF-Connecting-IP and X-Forwarded-For headers whenever they were present, and those are sent by the client. On a site without a proxy in front, an attacker could send a different IP on every request and never reach the lockout threshold, or send someone else’s IP to get them locked out. The IP is now read from the connection itself, and a new setting under Login lets you pick a proxy header when the site genuinely sits behind Cloudflare, a load balancer or an Nginx proxy. The settings screen shows the IP currently detected for you so you can verify the choice.
• Fixed: with the custom login URL enabled, anonymous requests to admin-post.php were redirected to the login slug. That endpoint lives in /wp-admin/ but is public by design: it dispatches the admin_post_nopriv_* actions used by contact forms, payment gateway callbacks and other plugins. Those requests silently turned into a redirect. admin-post.php, admin-ajax.php, WP-Cron and WP-CLI are now excluded from the redirect.
• Changed: every option now starts disabled on a new install. Until 1.1.0 a group of them was enabled out of the box, which meant activating the plugin changed how the site behaved before anyone had chosen anything, and made those changes hard to trace when something broke. Existing sites keep exactly the settings they had, including sites that never opened the settings screen.
• Added the o24s_client_ip filter for setups whose IP header is not one of the four offered.

1.1.0

• The plugin is now fully translatable. Every user-facing string goes through the WordPress i18n functions with the open24-security text domain.
• Source strings are now in English, so the plugin can be translated on translate.wordpress.org.
• Added a complete Spanish (es_ES) translation, plus the .pot template in /languages.
• Added the Domain Path header and loading of the bundled translations on init.

1.0.9

• Security keys are now written through the WP_Filesystem API instead of direct file writes.
• Removed the wp-config.php backup file that was left in the site root. It is no longer created.
• File permissions of wp-config.php are now preserved when rotating keys.
• All admin styles are now properly enqueued instead of being printed inline.
• Hardened input handling: all superglobals are unslashed and sanitized.
• All output is now escaped at the point of output.
• Internal redirects now use wp_safe_redirect().
• Readme and plugin headers translated to English.

1.0.0

• Initial release.