Vulnity Security

Yes. The plugin requires an active Vulnity SIEM account to collect and analyze events.

No. Event collection runs asynchronously and offloads processing to the Vulnity cloud platform.

Absolutely. Use the Alert Policies section within the plugin settings to mute or reclassify events.

Vulnity's remote update settings and exclusions control updates requested by the Vulnity service. WordPress keeps its own automatic-update preferences for plugins and themes. Disabling an update or excluding a component in Vulnity does not disable native WordPress updates; manage those separately in WordPress. From 1.4.4, pairing no longer overrides previously saved WordPress preferences. Remote updates continue through WordPress's own upgrader and return a retryable failure while a native background update is running.

The /sso gate and the plugin's HTTPS shim only believe forwarded headers (X-Forwarded-Proto, X-Forwarded-SSL) when the immediate network hop (REMOTE_ADDR) is a trusted proxy. Trusted means: an entry you configured in the vulnity_trusted_proxies option (IPs or CIDRs — recommended, keep it to the minimal real ranges of your proxy/CDN), or a private/reserved address, which is auto-trusted by default for compatibility with same-host reverse proxies. X-Forwarded-Proto is authoritative and fail-closed: any non-https segment rejects the request and X-Forwarded-SSL: on cannot override it. If a client could reach your origin directly from the private network, disable the automatic trust by returning false from the vulnity_trust_private_proxies filter (e.g. in a mu-plugin) and declare your proxies explicitly. Direct internet connections must satisfy is_ssl(). Cloudflare detection and the proxies declared in the Vulnity panel (see the next question) only affect which client IP is used; they never make the HTTPS shim or the /sso gate trust forwarded headers.

By default (mode "Automatic"), when the connecting address (REMOTE_ADDR) is in Cloudflare's published IP ranges, the client IP is taken only from CF-Connecting-IP (or CF-Connecting-IPv6 when Cloudflare sends a pseudo-IPv4 address); X-Forwarded-For, X-Real-IP and Forwarded are ignored, and Cloudflare Worker subrequests (CF-Worker header) keep the connecting address. Separately, the plugin samples public requests (about one per minute) and marks the site as behind Cloudflare once at least 20 of them in 24 hours arrive through Cloudflare with a visitor CF-Connecting-IP (Worker subrequests are not counted) and the site's own host name (the WordPress address stored in the database) resolves in public DNS only to Cloudflare addresses. The DNS check runs in WP-Cron, at most once a day and only on sites that see Cloudflare traffic, and keeps someone else's traffic from switching this on or off. If the host name cannot be resolved (no outbound DNS, or WP-Cron disabled), the site is never marked automatically: use "Always Cloudflare" in the panel. It returns to normal when the host name stops resolving to Cloudflare or after 7 days without Cloudflare traffic. On a site marked behind Cloudflare, Cloudflare edge addresses and the proxies declared in the panel are never auto-blocked. Residual risk: a Cloudflare Worker or Snippet in a zone that points at your origin can set CF-Connecting-IP; Worker subrequests are excluded through the CF-Worker header, and if the site does not use Cloudflare you can switch detection off from the panel. From the Vulnity panel you can force the mode on ("Always Cloudflare"), switch it off (1.4.6 behaviour) and declare your own proxies (up to 32 IPs or CIDRs). The read-only "IP detection" card in Vulnity > Mitigation shows the current mode, whether Cloudflare was detected and the IP the plugin sees for you. HTTPS detection is not affected.

When TLS terminates at a trusted proxy and the origin receives plain HTTP, WordPress' is_ssl() is false, and session cookies would be written (and later read) with the wrong scheme. On load, the plugin applies the standard WordPress reverse-proxy shim — setting $_SERVER['HTTPS'] — but only after the same fail-closed validation as the SSO gate (trusted hop + all-https forwarded chain; never from an untrusted direct client). This keeps is_ssl() consistent site-wide so delegated-login cookies always carry the Secure attribute and remain readable in wp-admin. To disable it, set the option vulnity_https_proxy_shim to 0 or return false from the vulnity_https_proxy_shim filter; the canonical X-Forwarded-Proto shim in wp-config.php remains a valid alternative. Deliberate fail-closed: with the shim disabled and TLS only at the proxy, /sso answers 400 rather than ever issuing a non-Secure admin cookie. One-time note: on a site behind a TLS-terminating proxy that did not already have an is_ssl() shim, activating or updating to this version flips is_ssl() to true, so WordPress starts using the secure auth cookie. Any admin sessions established before the update are invalidated once and those users are asked to log in again — a single expected re-login, not a recurring one. If you already run the X-Forwarded-Proto shim in wp-config.php, nothing changes.

With the renamed login enabled, anonymous visitors get a 404 from wp-login.php and wp-admin, and WordPress no longer sends them to the renamed URL. Logged-in users still see it (for example in the log-out link), and so does anyone you show a "Log in" link to. Valid password-reset and personal-data links that point at wp-login.php still work. If a single sign-on or social login plugin needs to reach wp-login.php directly, return true from the vulnity_allow_direct_wp_login filter (arguments: the action WordPress will run and the request method) in a mu-plugin or early plugin code; it is evaluated on init priority 10. To send wp-admin pages that ask to log in again to the renamed URL as before, return true from vulnity_reveal_login_on_auth_redirect. The password form of protected posts and the confirmation link of personal-data requests use wp-login.php, so if your server, firewall or host blocks wp-login.php, let ?action=postpass (POST) and ?action=confirmaction (GET) through.

Set the option vulnity_delegated_login_enabled to 0, or return false from the vulnity_delegated_login_enabled filter from code you control (a mu-plugin or your theme). The filter is the last-resort guarantee: it works locally even if the central panel were compromised, so it will never be removed. While disabled, /sso answers 403 and no session can be created.

Each redemption attempt atomically reserves one slot for the real client identity (resolved through the trusted proxy chain; IPv6 grouped by /64, IPv4 per host) in a fixed 300-second window, with a hard cap of 10 admitted attempts per identity and window — a concurrent burst cannot exceed it. A successful login refunds its slot, so only failures consume budget. The number of live rate-limit rows in wp_options is capped (oldest buckets are evicted deterministically, never merged into a shared bucket), and closed windows are swept hourly.