{"id":6,"date":"2026-08-29T10:15:27","date_gmt":"2026-08-29T10:15:27","guid":{"rendered":"https:\/\/wp-opsec.eagleeye-intelligence.com\/?page_id=6"},"modified":"2026-08-29T10:35:19","modified_gmt":"2026-08-29T10:35:19","slug":"wp-opsec","status":"publish","type":"page","link":"https:\/\/wp-opsec.eagleeye-intelligence.com\/","title":{"rendered":"WP Opsec"},"content":{"rendered":"\n
\n \n \n \n \n \n <\/linearGradient>\n <\/defs>\n \n \n \n \n <\/svg>\n

A modular WordPress security plugin built around one idea: block what can be blocked before WordPress finishes loading<\/em>, and make everything else visible enough to act on.<\/p>\n<\/div>\n\n\n\n

Twelve independent modules \u2014 IP reputation, request scanning, login protection, file integrity, vulnerability scanning and more \u2014 each shipping in log-only mode until you trust what it catches.<\/p>\n\n\n\n

\n\n\n\n

Why this exists<\/h2>\n\n\n\n

The design follows what current data actually says about how WordPress sites get compromised, rather than what is easiest to write signatures for:<\/p>\n\n\n\n

    \n\n
  • 91%<\/strong> of the 11,334 WordPress vulnerabilities disclosed in 2025 were in plugins \u2014 not core, not themes.<\/li>\n\n\n
  • ~60%<\/strong> of infections exploit a flaw that already had a patch available<\/em>.<\/li>\n\n\n
  • Median time from disclosure to mass exploitation: about five hours<\/strong>.<\/li>\n\n\n
  • 43%<\/strong> of plugin vulnerabilities are exploitable without authenticating at all.<\/li>\n\n\n
  • Typical hosting-level defences blocked only 12%<\/strong> of WordPress-specific attacks.<\/li>\n\n<\/ul>\n\n\n\n

    Two consequences shaped the plugin. A human reading a report loses a five-hour race, so the update path is automated rather than merely reported. And because the 2026 supply-chain backdoors survived by creating hidden administrator accounts, detecting that<\/em> step matters more than detecting the obfuscated code that performed it.<\/p>\n\n\n\n

    \n\n\n\n

    The twelve modules<\/h2>\n\n\n\n

    Blocking the request<\/h3>\n\n\n\n
      \n\n
    • IP Blocklist<\/strong> \u2014 pulls CINS Army, DShield, Spamhaus DROP and FireHOL feeds daily, compiles them into a merged sorted-range file and binary-searches it with no database hit. Also enforces a shared local list that other modules escalate into.<\/li>\n\n\n
    • Query Guard<\/strong> \u2014 signature scanning for SQLi, XSS, traversal and command injection in query strings, plus a deliberately narrower set for POST bodies and file uploads. Optional xmlrpc.php blocking with a Jetpack exemption.<\/li>\n\n\n
    • Login Guard<\/strong> \u2014 per-IP failed-login rate limiting with lockout, escalating repeat offenders to the early gate so a bot stops receiving the login page at all.<\/li>\n\n\n
    • User Enumeration<\/strong> \u2014 blocks ?author=N<\/code> probing, anonymous REST user listing and oEmbed author leakage. A known-valid username halves the work of a brute force.<\/li>\n\n<\/ul>\n\n\n\n

      Detecting compromise<\/h3>\n\n\n\n
        \n\n
      • File Integrity<\/strong> \u2014 core verified against WordPress.org’s published checksums, which is authoritative even if the plugin was installed after<\/em> a compromise. Plugins and themes are compared against a local baseline, since no published checksums exist for them.<\/li>\n\n\n
      • User Watchdog<\/strong> \u2014 watches privileged accounts through WordPress hooks, and separately by hourly snapshot diff, which catches an administrator inserted straight into the database by raw SQL where no hook ever fires.<\/li>\n\n\n
      • Hardening<\/strong> \u2014 disables the dashboard file editor, blocks PHP execution in uploads, and finds plugins that hide themselves from the Plugins screen by filtering it.<\/li>\n\n\n
      • Vulnerability Scan<\/strong> \u2014 flags outdated components, plugins pulled from the .org directory, and anything unmaintained for two years or more. An optional WPScan token adds real CVE records.<\/li>\n\n<\/ul>\n\n\n\n

        Closing the loop<\/h3>\n\n\n\n
          \n\n
        • Auto Updates<\/strong> \u2014 installs what the vulnerability scan flagged, rather than waiting for someone to read the report. Only ever adds to what you already enabled per plugin; an explicit exclusion list is the one thing that turns an update off.<\/li>\n\n\n
        • Security Headers<\/strong> \u2014 CSP, HSTS, frame and referrer policy. The two that can genuinely break a site are off by default, and HSTS understands sitting behind a TLS-terminating proxy.<\/li>\n\n\n
        • Event Log<\/strong> \u2014 one filterable table every module writes to, so the answer to “what happened” is not an SSH session and a grep<\/code>.<\/li>\n\n\n
        • Telegram Alerts<\/strong> \u2014 real-time notification for events above a severity threshold, with a cooldown so a scanner cannot flood the channel.<\/li>\n\n<\/ul>\n\n\n\n
          \n\n\n\n

          How it works<\/h2>\n\n\n\n

          Blocking happens before WordPress loads<\/h3>\n\n\n\n

          The enforcement layer is a must-use plugin that runs before the rest of WordPress bootstraps. Modules drop individual check files into it, and a blocked request never reaches theme or plugin code. This is also why alerting is wired directly into the logging function rather than a WordPress action hook: a real block calls wp_die()<\/code> immediately, so plugins_loaded<\/code> never fires for exactly the requests most worth knowing about.<\/p>\n\n\n\n\n \n \n \n <\/marker>\n \n \n <\/marker>\n <\/defs>\n\n \n \n Request<\/text>\n from the internet<\/text>\n \n\n \n \n must-use plugin gate<\/text>\n runs before WordPress loads<\/text>\n IP blocklist \u00b7 query string<\/text>\n POST body \u00b7 uploads \u00b7 xmlrpc<\/text>\n\n \n \n blocked<\/text>\n \n 403 Forbidden<\/text>\n theme and plugins never run<\/text>\n\n \n \n allowed<\/text>\n\n \n \n WordPress loads<\/text>\n hook-based modules<\/text>\n login guard \u00b7 user watchdog<\/text>\n REST \u00b7 headers \u00b7 integrity<\/text>\n\n \n\n \n \n Event log<\/text>\n severity 1\u201320, filterable<\/text>\n every module writes here<\/text>\n\n \n \n blocked requests are logged too<\/text>\n\n \n \n above threshold<\/text>\n \n Telegram alert<\/text>\n real time, rate limited<\/text>\n\n Reserved and private IP ranges, plus an operator-supplied trusted-networks file, are exempt from every blocking path \u2014 no feed update can lock you out.<\/text>\n<\/svg>\n\n\n\n

          Every event carries a severity, 1 to 20<\/h3>\n\n\n\n

          Severity describes what an event implies<\/em>, not how confident the detection is. Anything at 18 or above means something already succeeded \u2014 a core file changed, an administrator exists that should not. A serious exploitation attempt that was stopped tops out at 17. That distinction is what makes the log sortable into “investigate now” versus “background noise from the internet”.<\/p>\n\n\n\n\n \n \n \n \n \n\n Info<\/text>\n Low<\/text>\n Medium<\/text>\n High<\/text>\n Critical<\/text>\n\n 1 \u2013 4<\/text>\n 5 \u2013 9<\/text>\n 10 \u2013 13<\/text>\n 14 \u2013 17<\/text>\n 18 \u2013 20<\/text>\n\n successful login,<\/text>\n baseline taken<\/text>\n failed login, author<\/text>\n scan, listed IP<\/text>\n brute-force lockout,<\/text>\n XSS attempt<\/text>\n SQLi, webshell<\/text>\n upload, RCE attempt<\/text>\n core file changed,<\/text>\n rogue admin account<\/text>\n\n \n already happened<\/text>\n \n attempted, and stopped<\/text>\n<\/svg>\n\n\n\n

          Nothing enforces until you say so<\/h3>\n\n\n\n

          Every blocking module ships in log-only mode. The intended sequence is to watch the Event Log until you trust what it is catching, then switch that module to enforce. Private and reserved IP ranges are permanently exempt from every blocking path, and an operator-supplied trusted-networks file (search-engine crawlers, monitoring) is exempt too \u2014 so no feed update or escalation can lock you out of your own site.<\/p>\n\n\n\n

          \n\n\n\n

          Honest limitations<\/h2>\n\n\n\n
            \n\n
          • A WordPress plugin only ever sees requests that reach PHP. If a file genuinely exists \u2014 an exposed .git<\/code> directory, for instance \u2014 the web server serves it directly and no plugin can intervene. That fix belongs in the server config.<\/li>\n\n\n
          • Probe detection for sensitive paths depends on the site’s permalink structure routing 404s into WordPress. Where it cannot work, it says so rather than implying coverage it does not have.<\/li>\n\n\n
          • Baseline comparison for plugins and themes detects change since the baseline was taken \u2014 not whether the current state was clean to begin with. Core checksums do not share that limitation.<\/li>\n\n\n
          • An IP allowlist only helps for services that publish stable ranges. Mobile apps, desktop clients and pingbacks arrive from arbitrary addresses and cannot be selectively permitted that way.<\/li>\n\n<\/ul>\n\n\n\n
            \n\n\n\n

            Status<\/h2>\n\n\n\n

            Under active development. Twelve modules implemented and tested against simulated attacks \u2014 including an administrator account inserted by raw SQL, a self-hiding backdoor plugin, webshell uploads and a deliberately downgraded plugin. A full code review produced ten findings, all since fixed and individually verified against the specific failure each one described.<\/p>\n\n\n\n

            Not yet released, and not yet running in enforcing mode on a production site.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

            A modular WordPress security plugin built around one idea: block what can be blocked before WordPress finishes loading, and make everything else visible enough to act on. Twelve independent modules \u2014 IP reputation, request scanning, login protection, file integrity, vulnerability scanning and more \u2014 each shipping in log-only mode until you trust what it catches. […]<\/p>\n","protected":false},"author":0,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-6","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/wp-opsec.eagleeye-intelligence.com\/index.php?rest_route=\/wp\/v2\/pages\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wp-opsec.eagleeye-intelligence.com\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/wp-opsec.eagleeye-intelligence.com\/index.php?rest_route=\/wp\/v2\/types\/page"}],"replies":[{"embeddable":true,"href":"https:\/\/wp-opsec.eagleeye-intelligence.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6"}],"version-history":[{"count":4,"href":"https:\/\/wp-opsec.eagleeye-intelligence.com\/index.php?rest_route=\/wp\/v2\/pages\/6\/revisions"}],"predecessor-version":[{"id":10,"href":"https:\/\/wp-opsec.eagleeye-intelligence.com\/index.php?rest_route=\/wp\/v2\/pages\/6\/revisions\/10"}],"wp:attachment":[{"href":"https:\/\/wp-opsec.eagleeye-intelligence.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}