sHub-Log Security Observability + Verified Bot Intelligence

Attacks on WordPress aren't
limited to the login screen.
Visualize invisible threats and block repeat attackers.

sHub-Log is a WordPress security plugin that classifies and logs more than unauthorized admin access—probing of plugin, theme, and WordPress core paths, config file exposure checks, web shell and uploads PHP probes, user enumeration, scanner User-Agents, bot impersonation, REST API abuse, REST path probes, malicious queries, and bursts of suspicious 404s—across 16 categories.

Instead of "something is hitting the site," see what is being targeted, from where, and how often in attack logs and charts. When the same IP repeats attacks, sHub-Log protects that IP on WordPress for a set period.

Plus, verify and log search bots like Googlebot and Bingbot, and AI bots like GPTBot and ClaudeBot—attack visibility and search/AI crawler visibility in one admin dashboard.

Free Official on WordPress.org GPLv2

sHub-Log admin dashboard preview
sHub-Log admin dashboard preview
41.2%
WordPress share of all websites worldwide
53%+
Automated web traffic from bots and similar sources
91%
Share of WordPress vulnerabilities in plugins
16
Attack categories for classification
The WordPress Threat Landscape

Three facts to understand
WordPress today

WordPress is the world's most widely used CMS. Because of its scale, it is targeted not only for brute-force login attacks but also for automated probing of WordPress vulnerabilities, plugin vulnerabilities, misconfigurations, exposed APIs, and non-existent attack paths.

And now, more than half of web access is not human. What you need is not to reject every bot outright, but to separate legitimate crawlers from malicious bots and automated vulnerability scanning.

41.2%

Of all websites worldwide

As of July 2026, WordPress powers 41.2% of all websites. Its CMS share is 59.1%.

W3Techs ↗
53%+

Automated traffic

Imperva's 2026 Bad Bot Report: in 2025, over 53% of web traffic was automated (bots, etc.). Human access was 47%.

Imperva ↗
91%

Plugin-origin

Patchstack: of 11,334 new WordPress ecosystem vulnerabilities in 2025, 91% were found in plugins.

Patchstack ↗

A bot is software that automatically crawls or interacts with websites on behalf of humans. Used for search indexing, AI crawls, monitoring—and also vulnerability scanning, credential stuffing, scraping, and spam.

The Attack Surface Has Changed

Login defense alone
won't reveal today's WordPress attacks.

Once, the central WordPress security concern was unauthorized login to wp-login.php and the admin area. Defending against brute-force attacks and credential stuffing with leaked IDs and passwords still matters today.

But attacks don't always start at the login screen.

Automated vulnerability scanners and malicious bots reach these targets directly—without logging in:

  • .env, wp-config.php, backup files, SQL files
  • Known or guessed paths under /wp-content/plugins/
  • WordPress core paths under /wp-includes/
  • Paths commonly associated with web shells, such as shell.php, wso.php, c99.php
  • REST API endpoints such as /wp-json/, and scans that vary install locations and REST routes
  • /xmlrpc.php
  • Queries intended for SQL injection, XSS, or path traversal
  • Large volumes of non-existent URLs

Viewed one at a time, each may look like a plain 404 or a few hits. But if the same IP probes multiple weak points in a short window, that is reconnaissance against your WordPress site. The same IP varying install locations and REST entry routes is one such pattern.

In the AI era, what grew isn't just vulnerabilities—it's the power to automate attacks

AI isn't creating WordPress vulnerabilities by itself. But Imperva reports that generative AI and LLMs lowered the bar for building bots, making large-scale automated attacks easier.

Targets aren't just the admin screen. Machines now continuously probe WordPress core, plugins, REST API, config files, and backdoor paths.

attack-log — 203.0.113.x / 10 min window
12:01:04 CONFIG_SCAN  /.env
12:02:37 CONFIG_SCAN  /wp-config.php.bak
12:03:55 PLUGIN_SCAN  /wp-content/plugins/…/readme.txt
12:05:12 CORE_SCAN    /wp-includes/…
12:06:48 REST_ABUSE   /wp-json/wp/v2/users
12:07:20 UA_EMPTY     (no user-agent)
score 40+40+25+25+20+15 = 165
→ RECORD (50) / PROTECT (100) — IP blocked

* Sample output for illustration purposes.

Catch low-volume reconnaissance that probes multiple weak points.

Simple request-rate limits catch attacks that hit hundreds of times per minute, but low-frequency reconnaissance across multiple weak points is easy to miss. sHub-Log risk scoring weights attack types and accumulates scores per IP within a time window.

By default, scores accumulate in a 10-minute window: 50 total records the attack, and 100 total protects the IP. Time window, point values, record threshold, and protect threshold are all configurable.

Look at combinations of attacks—not just counts. That is sHub-Log risk scoring.

* Risk scoring is OFF by default. Review your site's traffic before enabling it.

Detected behaviorPoints (default)
Backdoor probing50
Config file probing40
Malicious query parameters40
REST Path Probe35
Suspicious 404 bursts30
High request volume30
Plugin vulnerability scanning25
WordPress core vulnerability scanning25
REST API abuse attempts20
Admin hacking15
Spam and other15
Empty User-Agent15
Why We Built It

This plugin started from an experience that took two weeks to fully recover.

The founder of SyntaxCloud, which developed sHub-Log, has worked in creative production and SEO digital marketing since the internet-specialist agency days.

The turning point came when a WordPress site under our care was compromised in the 2010s. The first incident took about two weeks to identify the cause, assess tampering, recover, and prevent recurrence.

When another client site was hit afterward, lessons from the first incident helped us recover in a few days.

That experience showed us that running a site takes far more than content updates and server management alone.

sHub-Log is not a security product dreamed up on paper.

After real incidents and recovery work, we published on WordPress.org the "dashboard that shows what's happening now" we needed in day-to-day WordPress operations.

Detect · Record · Protect

Classify into 16 categories, record attacks, and protect repeat IPs.

sHub-Log classifies suspicious requests reaching WordPress into 16 categories.

High request volume REST API abuse attempts REST Path Probe Admin hacking Plugin vulnerability scanning Theme vulnerability scanning WordPress core vulnerability scanning Config file probing Backdoor probing User enumeration Malicious query parameters Scanner tool Bot impersonation Spam and other Suspicious 404 bursts Scoring detection
CategoryWhat we watch for
High request volumeConcentrated requests from the same IP in a short window
REST API abuse attemptsProbing of REST API endpoints intended to fetch user information and similar data
REST Path ProbeSame-IP scans that vary WordPress install locations and REST entry routes in a short window. Legitimate REST paths are not blocked by path alone
Admin hackingUnauthenticated access to admin-related URLs (soft category)
Plugin vulnerability scanningProbes under /wp-content/plugins/ that return 404
Theme vulnerability scanningProbes under /wp-content/themes/ that return 404
WordPress core vulnerability scanningProbes under /wp-includes/ that return 404
Config file probingAccess to .env, wp-config, .git, suspicious backup names, and similar paths
Backdoor probingKnown web shell names and PHP execution attempts under /wp-content/uploads/
User enumerationRepeated numeric ?author=N or user sitemap probing
Malicious query parametersBasic patterns for SQL injection, XSS, path traversal, and similar attacks
Scanner toolKnown scanner User-Agents such as sqlmap, nikto, and wpscan
Bot impersonationClaims a known crawler User-Agent but fails verification (soft category)
Spam and otherAccess to xmlrpc.php; PROPFIND/TRACE/TRACK methods
Suspicious 404 burstsMany non-existent URLs probed in a short window
Scoring detectionWeighted combination of multiple attack signals exceeding a threshold

Not "vulnerability scanning"—capturing signs you're being targeted

sHub-Log is not a CVE-matching vulnerability scanner for installed plugins, nor a server-side malware scanner.

Its role is to classify external probes and attack signals against WordPress and keep them as attack logs. Patching requires updating core, plugins, and themes. Then knowing what was targeted before/after updates and whether the same IP keeps probing informs your next operational decision.

Security Visibility

Explain with counts and categories—not just "looks risky"

sHub-Log makes WordPress security observability usable for small ops teams.

  • Attack trend graph
  • Select period and aggregation interval
  • Aggregation by 16 categories
  • Record IP, target URL, User-Agent, and timestamp
  • Filter logs by category
  • CSV download
  • Log retention settings and automatic cleanup (default 90 days)
  • List of protected IPs and manual release
  • IP whitelist
  • Trusted reverse proxy support (Cloudflare, etc.)

Ready for monthly reports

Agencies and MSPs can share detected attack types and trends in monthly reports instead of guessing that "nothing is happening" on client sites. In-house IT teams can explain status to leadership and stakeholders with numbers.

Email alerts

Spike alert: when attacks in a specific category surge in a short window.
Sustained-high alert: when total count within a set period exceeds a threshold.
Both are OFF by default. Enable only on sites that need them.

WordPress Core Vulnerability: wp2shell

It's not just plugins.
WordPress core can still see exceptionally severe vulnerabilities.

Most vulnerabilities reported in the WordPress ecosystem are in plugins. In 2025, 91% were plugin-origin. But core vulnerabilities—fewer in number—can affect large numbers of sites running standard configurations at once.

In July 2026, an attack chain called wp2shell emerged, combining two WordPress core vulnerabilities: CVE-2026-60137 and CVE-2026-63030. According to IPA, on affected WordPress 6.9 and later, the combination may lead to unauthenticated remote code execution. On July 21, 2026, it was added to the US CISA Known Exploited Vulnerabilities (KEV) catalog as actively exploited.

This was also reported in the US by BleepingComputer, Wiz, Tenable, Bitdefender, etc. Attackers abusing REST API batch processing could lead to code execution and web shells on vulnerable WordPress sites.

Legitimate REST routes are also used by WordPress itself, so blocking a path such as /batch/v1 at all times is not practical. sHub-Log instead detects REST Path Probe behavior: the same IP varying install locations and REST entry routes in a short window, then can protect repeating IPs. Mixed 401/404 responses still count as reconnaissance by method, not by a single path.

On July 22, 2026, sHub-Log added a detection category the same day

July 21 (US time)

Listed in CISA KEV catalog

July 22 (Japan time)

IPA published security advisory

July 22 (same day)

Added "WordPress core vulnerability scanning" category to sHub-Log

Same day

Completed safety checks on customer sites operated via sHub

The added capability classifies and records access that probes non-existent paths under /wp-includes/ as WordPress core probing.

This is not a signature that identifies wp2shell-specific REST API traffic or successful exploitation. After a major core disclosure, we added this category to visualize core probing independently—not only login-screen monitoring.

This does not replace updating WordPress

Fixing the wp2shell vulnerabilities requires WordPress security updates. sHub-Log does not diagnose wp2shell infection or virtually patch vulnerabilities.

Roles are divided as follows.

Required actionResponsible party
Fix the vulnerabilitiesUpdate WordPress to patched releases 6.8.6, 6.9.5, 7.0.2 or later
Preserve signs of probingsHub-Log detection, classification, and logging
Suppress repeat attacks from the same IPsHub-Log time-limited IP protect
Investigate compromised files and accountsProfessional incident response, malware inspection

Apply core updates without fail. Then shorten the time from disclosure to response and keep attack signals in logs before and after updates.

Bots Now Outnumber Humans

When more than half of web access is bots,
you need to tell bots apart.

Not every bot is malicious. Googlebot and Bingbot crawl sites to index pages in search results. AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot access the web under each service's purpose and rules.

Malicious bots also exist: bots that automatically scan WordPress and plugins for vulnerabilities, bots that brute-force the login screen, credential-stuffing bots that try leaked credentials, bots probing for .env and wp-config.php, bots scanning for web shells and backdoor paths, spam and unauthorized scraping bots, and impostors claiming to be Googlebot.

What you need is not to trust whatever name appears in the User-Agent.

Search SEO Layer

Googlebot, Bingbot, and more

Track verified search crawlers such as Googlebot, Bingbot, and DuckDuckBot. See total search bot access, breakdown by bot, crawl changes after site launch or redesign, and short-term signals after sitemap or internal link improvements.

AI Layer

GPTBot, ClaudeBot, PerplexityBot, and more

Track verified AI crawlers such as GPTBot, ClaudeBot, PerplexityBot, and OAI-SearchBot. See total AI bot access, breakdown by bot, whether AI crawlers arrived after content publication, and short-term changes in AI bot traffic.

"Access claiming to be Googlebot" is not the same as legitimate Googlebot.

User-Agent strings can be rewritten freely by the client. Malicious bots can easily claim to be Googlebot.

sHub-Log treats access as a legitimate bot only after these steps:

  • User-Agent matches a known search bot or AI bot
  • FCrDNS (reverse lookup, then forward confirmation of the IP) or verification against official IP ranges published by the operator

Only verified bots are written to bot access logs, so fake Googlebots and User-Agent copycats are less likely to mix into legitimate crawler totals.

Attack logs and bot logs live in separate tables and separate admin screens. Security records stay separate from search and AI crawler analysis.

Bots that fail verification aren't auto-blocked for that reason alone. They aren't excluded from rate measurement as legitimate bots; protect applies when attack patterns or frequency match your settings.

What you can and can't see

What you can see

  • How often verified search and AI bots visited your site
  • Breakdown by bot type
  • Access trends for up to 14 days
  • Whether crawl patterns changed after site changes or new posts

What you can't see

  • Whether content was actually cited in ChatGPT or Perplexity answers
  • Whether Google search rankings improved
  • How content is evaluated inside AI services

More AI bot traffic does not prove better AI search performance. Long-term search outcomes belong in Google Search Console; recent verified crawler activity belongs in sHub-Log—a practical division of roles.

Free Version

Free: attack visibility and bot verification included.

The free version of sHub-Log includes:

  • 16-category attack detection and attack logs
  • Automatic protect for repeat IPs
  • IP protect based on failed login count
  • Attack trend graph
  • Filter by category
  • CSV download
  • Risk scoring (enable in settings)
  • Verified search and AI bot access logs (up to 14 days)
  • Spike and sustained-high email alerts (enable in settings)
  • IP whitelist
  • Trusted reverse proxy settings (Cloudflare, etc.)
  • Multilingual admin UI including Japanese and English

Safe defaults from day one

To limit false positives, risk scoring, bot access logs, and email alerts are OFF by default. Start with basic settings, review traffic, then tune advanced options.

If unsure, you can return to Recommended settings.

Install from the WordPress admin and activate—that's all it takes.

Pricing

Priced like one cup of coffee a month

The same capabilities at a price that fits local cost of living. Pricing is designed to track the price of a cup of coffee by country and region.

Free
¥0

Official on WordPress.org / GPLv2

  • 16-category attack detection, logging, and blocking
  • Attack trend graph / CSV download
  • Legitimate bot access logs (up to 14 days)
  • Email alerts and risk scoring

Paid — planned August 2026
¥692 / month
¥8,300 / year

United States cup of coffee (¥692)

Monthly billing is planned for the future. In 2026, annual billing only.

  • Bot access ranking by URL
  • Pages with sudden spikes
  • Bot breakdown per page (search / AI)
  • All free features remain available

Security visibility and search/AI crawl visibility. If that runs about the cost of one cup of coffee a month, the decision shouldn't be hard.

Who It's For

For teams that can't treat WordPress
as "build and forget"

For teams that can't treat WordPress as "build and forget."

WordPress agencies and digital studios

Add attack logs, IP protect, and CSV reports to post-delivery maintenance. Explain status to multiple clients on the same basis.

MSPs and managed WordPress hosting

Classify probing and suspicious 404s on client sites for support and monthly reporting. Works behind reverse proxies such as Cloudflare.

In-house IT teams

Even without dedicated security staff, share attack types and trends via the admin UI or CSV.

WooCommerce and online businesses

On sites where downtime or tampering hits revenue and trust directly, see probing beyond the login screen.

Publishers and digital media

Alongside WordPress security, review trends for verified search and AI crawlers.

SEO firms and content operations teams

Use verified crawler access right after publish or redesign as supplementary data that's hard to see in Google Search Console alone.

Also a fit for these teams

WordPress agencies and dev shops … easy to add to post-delivery maintenance menus Owned media and content teams … verify crawls when content is written for AI consumption E-commerce (WooCommerce, etc.) … frequent attack targets; downtime hits revenue directly Healthcare, clinics, professional services … trust matters; tampering impact is high Education and public-sector related sites … multi-site operations and audit needs Managed hosting providers … added value for customers, lighter support load IT generalists without web specialists … materials to explain what's happening
Day-2 Operations

So you're not lost after install

A security plugin's value is decided by whether you can keep using it after install.

  • Simple (settings) and advanced admin views — start minimal, go deeper when ready
  • Recommended settings button — return to defaults when unsure
  • Admin UI in Japanese, English, and more — easy to share with overseas teams and partners
  • Automatic log cleanup — set retention; deletion runs automatically
  • CSV download — export for reports and external analysis
  • Trusted proxy settings — real IP detection behind Cloudflare and similar services

Detailed usage guides are available on a separate page.

Privacy and Transparency

Attack logs are not sent to external services.

sHub-Log is a GPLv2 plugin distributed through the official WordPress.org directory.

Attack logs, IP addresses, user information, and site content are not sent to SyntaxCloud. Logs are stored in the WordPress database. External communication is limited to these purposes, depending on settings and features:

  • Fetch signed alert definitions, email templates, and score definitions
  • Fetch official IP range JSON published by each vendor for legitimate bot verification

Bot IP ranges are cached for 24 hours. If fetch or signature verification fails, built-in defaults, local backup, or admin-configured values are used.

The paid version is a service provided on syn-c.jp. The free version continues to work after the paid release. We do not plan to move existing free features behind a paywall.

Get Started

First, see what's hitting
your WordPress site.

Protecting the login screen alone is not enough.

Plugin paths, WordPress core paths, config files, REST API, REST path probes, backdoor candidates, suspicious 404s—classify external probing, record it, and protect repeat attackers.

At the same time, don't trust search and AI bots by User-Agent alone—verify with FCrDNS and official IP ranges, and view that activity on a separate screen. Attack visibility and legitimate crawler visibility in one WordPress admin.

sHub-Log was born from an experience that took two weeks to recover. What we wanted then wasn't more features—it was a dashboard that shows what's happening.