by
manuelgalan
0 (0 reviews)
Vulnity Security
Security monitoring and SIEM integration that keeps your WordPress sites safe in real time.
Vulnity Security ranks #22,307 among WordPress.org plugins with 40+ active installations, is #1,282 of 4,572 in the Security category, and was last updated Sep 6, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Tested up to WP 6.9.9 (Current: 7.1.2)
v1.4.2
Current Version v1.4.2
Updated 2 weeks ago
Last Update on 06 Sep, 2026
Refreshed 7 hours ago
Last Refreshed on
#1,282 of 4,572 in Security
Top 50% by installs
Downloads +10.7% this week
Actively maintained
Rank
#22,307
—
No change
Active Installs
40+
+11.1%
KW Avg Position
51
3.7 worse
Downloads
1.5K
+2 today
Support Resolved
0%
—
No change
Rating
0%
Review 0 out of 5
0
(0 reviews)
Next Milestone 50
40+
50+
2,309
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 6 more installs to reach 50+
Rank Changes
Current
#22,307
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
0.0
0 reviews
Overall
0%
5
0
(0%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 1.4.2
- Last Updated
- Sep 06, 2026
- Requires WP
- 6.2+
- Tested Up To
- 6.9.9
- PHP Version
- 7.4 or higher
- Author
- manuelgalan
Support & Rating
- Rating
- ☆ ☆ ☆ ☆ ☆ 0
- Reviews
- 0
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade NowSimilar Plugins
Adminify – White Label, Admin Menu Editor, Login Customizer
6K+ installs
#2,760
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,009
LiteSpeed Cache
7M+ installs
#5
Akismet Anti-spam: Spam Protection
5M+ installs
#8
Wordfence Security - Firewall, Malware Scan, and Login Security
5M+ installs
#11
Really Simple Security - Simple and Performant Security (formerly Really Simple SSL)
3M+ installs
#17
Hostinger Tools
3M+ installs
#20
WPS Hide Login
2M+ installs
#27
Limit Login Attempts Security – Login Security, 2FA, Firewall, Brute Force Prevention
1M+ installs
#33
WP Super Cache
1M+ installs
#37
Frequently Asked Questions
Common questions about 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.
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().
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.
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.
