We Scanned 174 Live LearnDash Sites in 2026: The Security Findings

43% of the 174 live LearnDash sites we scanned in May 2026 were running a version with at least one known critical CVE.

That is the headline finding of an external, non-intrusive security scan of 174 publicly reachable LearnDash deployments. This page documents the numbers, explains why we ran the scan now, and lays out the methodology in enough detail that you can cite it, replicate it, or challenge it. It is a data report, not a product review. If you operate a LearnDash site, the What it means for LearnDash operators section is written to be neutral and factual.

Why we ran this

Two things changed the risk math for LearnDash operators in a way that motivated a fresh, measured look at the installed base.

First, the dissolution of StellarWP (LearnDash's parent organization) reshaped who is responsible for the product's long-term maintenance. When the corporate structure behind a plugin changes, the practical question for site owners is simple: who ships the next security patch, and how fast?

Second, and more concretely, there is a known patch cliff in April 2027. After that date, the organization's ability to help patch LearnDash on the timelines operators have come to expect is frozen. A plugin that sits in the authentication and payment path of a course business is exactly the kind of software where a patch-response gap matters, because a single unaddressed critical vulnerability can expose user accounts, course content, and transaction data.

We wanted a baseline measurement of where live sites actually stand today, before that cliff, rather than relying on anecdote. The 174-site scan is that baseline. You can compare all the ways off LearnDash in our migration hub if the findings below change your planning.

Key findings

Each finding below is its own subsection with a bold, standalone number so it can be quoted independently.

43% were running a version with at least one critical CVE

About 75 of the 174 sites (43%) were running a LearnDash version associated with at least one publicly disclosed critical CVE. A CVE (Common Vulnerabilities and Exposures) is a catalogued, publicly known security flaw. "Critical" here refers to the highest-severity tier (see the Methodology section for the exact CVSS threshold used). This is the single most consequential number in the dataset because a known critical CVE on a public-facing site is, by definition, a vulnerability that an attacker can look up.

About 50% were on an out-of-support WordPress core

Roughly half of the scanned sites were running a WordPress core version that is no longer in the supported release window. LearnDash does not run in isolation. An out-of-support core means the platform underneath the plugin is itself no longer receiving the same security attention, which compounds any plugin-level exposure.

77% of sites exposing a PHP version were on end-of-life PHP

Of the sites that disclosed a PHP version, 77% were running an end-of-life PHP release. End-of-life (EOL) means the PHP version no longer receives official security fixes. Note the qualifier: this percentage is calculated only over sites that exposed their PHP version in response headers, not over all 174 sites.

The median site ran about 7.5 third-party plugins

The median scanned site ran roughly 7.5 third-party plugins alongside LearnDash. Each additional plugin is additional code in the trust boundary of the site. This figure is a measure of attack surface, not of quality. A higher plugin count is not inherently insecure, but it does mean more independently maintained components that each need their own patch cadence.

90% had no HSTS header

90% of sites sent no HTTP Strict Transport Security (HSTS) header. HSTS tells browsers to only ever connect over HTTPS, which closes a class of downgrade and interception attacks. Its near-total absence across the sample is notable because HSTS is a one-line server configuration, not a code change.

87% had no Content-Security-Policy

87% of sites sent no Content-Security-Policy (CSP) header. CSP is the primary browser-level defense against cross-site scripting and content-injection attacks. Its absence does not mean a site is exploited, but it removes a major mitigating layer for a platform that renders user-influenced content.

81% had no X-Frame-Options header

81% of sites sent no X-Frame-Options header. This header defends against clickjacking, where a site is loaded invisibly inside an attacker's page to trick users into clicking. Like HSTS, it is a server-level setting rather than a code fix.

Uncanny Owl Toolkit appeared on about 25% of sites

The most common LearnDash add-on, the Uncanny Owl Toolkit, was detected on roughly 25% of scanned sites. This is an ecosystem observation, not a security claim about that specific add-on. It is included because the concentration of a single add-on across a quarter of the sample is a useful fingerprint of how the LearnDash ecosystem is actually deployed.

Findings at a glance

What it means for LearnDash operators

These findings describe the installed base, not any single site, and they are reported without editorializing. Read straight, three things stand out.

The first is that version currency is the dominant variable. The 43% critical-CVE figure is almost entirely a function of how recently a site updated its LearnDash version. Keeping the plugin current is the highest-leverage action available to an operator, and it is the action most directly affected by the April 2027 patch cliff: a freeze on patch capability matters most for the operators least able to update on their own.

The second is that the cheapest wins are at the HTTP-header layer. HSTS, CSP, and X-Frame-Options were absent on the large majority of sites, and all three are server-configuration changes rather than code changes. They do not require touching LearnDash, WordPress, or any plugin. For most operators, these are same-day fixes.

The third is that the stack underneath LearnDash matters as much as the plugin. The out-of-support-core and end-of-life-PHP numbers show that a meaningful share of risk lives in the hosting and runtime layer. An operator who updates the plugin but stays on an EOL PHP release has only addressed part of the exposure.

None of this requires changing platforms. An operator can update LearnDash, update WordPress core, move to a supported PHP release, and add three response headers, and most of the findings above would no longer apply to their site. For operators who would rather not own that maintenance burden, consolidating the stack is one option (see the footer); migrating the runtime, the headers, and the patch cadence to a single managed platform is another. The data here does not prescribe either path.

Methodology

Data source and scan posture

Every figure in this study comes from a single source: Shodan, the internet-wide device search engine. This is the most important thing to understand about our method, so we will state it plainly.

We never connected to, probed, scanned, logged into, or sent a single packet to any of the 174 sites. We did not run a vulnerability scanner against them. We did not fetch their pages. Shodan independently crawls the public IPv4 address space on a fixed set of common ports (HTTP/HTTPS among them), records the banner each service voluntarily returns to any ordinary client, and stores it in a searchable index. We queried that pre-existing index and analyzed the records. Nothing we did touched the sites themselves.

This makes the study passive and non-intrusive by construction. Banner data is information these servers already broadcast publicly to every visitor. We did not access anything a site operator had not already exposed to the open internet, and we performed no act that could be characterized as unauthorized access. The unit of analysis is "a public banner Shodan already holds," not "a site we tested."

How the 174 LearnDash sites were identified

LearnDash ships as a WordPress plugin whose internal slug is sfwd-lms. When a LearnDash site renders a page, it enqueues CSS and JavaScript assets from under wp-content/plugins/sfwd-lms/, and those asset URLs appear in the HTML that Shodan captures in its http.html banner. That asset-path string is a high-confidence fingerprint: a generic WordPress site does not reference sfwd-lms paths, so its presence in the captured HTML is a strong positive signal for LearnDash.

We located candidate sites using Shodan's HTTP content filters, which match against the HTML and component metadata Shodan already stored for each host:

• http.html - matches literal strings in the captured page source (for example, the sfwd-lms asset path or LearnDash-specific markup and class names).
• http.component - matches Shodan's own technology fingerprints (for example, that the host is WordPress).
• http.favicon.hash - matches the MurmurHash3 of a site's favicon, usable as a secondary asset fingerprint.

An illustrative query of the shape we used (shown for transparency, not as the literal production string) is:

http.component:"WordPress" http.html:"wp-content/plugins/sfwd-lms"

From the raw matches we deduplicated to unique live hosts (collapsing multiple banners or ports belonging to the same site), discarded records that did not resolve to a reachable LearnDash front end, and arrived at the final sample of 174 publicly reachable live LearnDash sites. All banner data reflects Shodan's index as of the May 2026 data pull.

The 174 sites are the complete set that met our criteria in Shodan's index at that time; they are a sample of Shodan-indexed LearnDash sites, not a census of all LearnDash sites on the internet (see Limitations).

How each finding maps to a Shodan data field

Every published number is derived from a specific, named field in the Shodan banner. We did not infer anything we could not read directly from the captured record.

• Security response headers (HSTS, CSP, X-Frame-Options). Shodan stores the full HTTP response headers a server returns. We checked each captured banner for the presence of Strict-Transport-Security, Content-Security-Policy, and X-Frame-Options. A header was counted as "missing" only when it was absent from the banner Shodan recorded. Findings: 90% had no HSTS, 87% had no CSP, 81% had no X-Frame-Options.

• PHP version. When a server discloses PHP, it typically appears in the X-Powered-By (for example, PHP/7.4.33) or Server header. We read the version from those headers. Many sites suppress this header, so this finding is reported only over the sites that actually exposed a PHP version, and the headline figure is stated that way: of those sites, 77% were on an end-of-life PHP release.

• WordPress core version. WordPress version strings surface in the captured HTML through the tag and through ?ver= query parameters appended to enqueued core assets. We parsed those strings from the http.html banner. About 50% of sites were on a WordPress core version that is no longer in the actively supported branch.

• LearnDash version and plugin inventory. Plugin presence and versions are read the same way: from wp-content/plugins// asset paths and their ?ver= strings in the captured HTML. Counting the distinct third-party plugin slugs referenced per site gave a median of about 7.5 plugins per site. The same parsing identified that about 25% of sites referenced the Uncanny Owl "Toolkit for LearnDash" add-on via its plugin asset path.

• CVE association. Shodan attaches a vulns object to a banner when a detected product/version maps to known CVEs. Each entry carries a cvss score, a summary, references, and a verified boolean. We used the detected WordPress/LearnDash/PHP versions and Shodan's CVE mapping to determine whether a site was running a version associated with a known critical CVE. On that basis, 43% of the sample (about 75 of 174) was running at least one component version associated with a critical CVE.

What "critical" means here

We define a vulnerability as critical using the standard CVSS v3.1 qualitative scale published by FIRST, under which a base score of 9.0 to 10.0 is rated Critical. Shodan's vulns entries carry CVSS scores, so a site was placed in the "critical" bucket when at least one CVE associated with one of its detected versions had a CVSS v3.1 base score of 9.0 or higher.

Honest framing of the CVE finding

This is a version-inference result, and we have worded the finding deliberately to reflect that. The 43% figure means "43% were running a version that has a known critical CVE," not "43% are confirmed exploitable."

Shodan itself distinguishes verified: true vulnerabilities (actively confirmed) from verified: false ones (implied from the version number alone), and it explicitly warns that version-inferred associations can carry false positives. The mapping is based on the disclosed version string, not on a successful exploit. A site flagged this way may in fact be protected: it may have backported a security patch without changing its public version number (a patch that does not bump the version is invisible to Shodan), it may sit behind a WAF or CDN that blocks the relevant attack path, or the vulnerable code path may not be reachable in its configuration. We did not, and could not, test exploitability without touching the sites, which we chose not to do. The careful phrasing throughout this study - "running a version with a critical CVE" - is exact and intentional.

Limitations

• Shodan is an index, not a census. Our sample is limited to LearnDash sites that Shodan had already crawled and indexed on the ports it scans. Sites Shodan had not yet visited, sites on non-standard ports, and sites that block or evade Shodan's crawlers are not represented. The 174 sites are a sample of Shodan-indexed LearnDash installs, not the entire population of LearnDash sites on the internet, and they should not be read as a statistically random sample of it.

• Fingerprint and version detection can miss or misclassify. LearnDash, WordPress, and plugin identification depend on version strings and asset paths appearing in the captured HTML. Sites that strip the generator meta tag, remove ?ver= parameters, rename assets, or otherwise obfuscate these markers may be undercounted or have their versions misread. Conversely, cached or stale markup could in rare cases misattribute a version.

• Sites behind a CDN, reverse proxy, or WAF may hide data, so several findings are lower bounds. Cloudflare and similar layers frequently rewrite or suppress Server / X-Powered-By headers and can strip version markers from HTML. Where a protective layer hid a version or a header, the underlying software may still be outdated or the header may still be absent at origin - but we did not count what we could not see. The header-absence and end-of-life percentages should therefore be treated as conservative lower bounds, not ceilings.

• The CVE mapping is version-based, not exploit-confirmed. As detailed in the Methodology, a "critical CVE" association means the detected version is one for which a critical CVE is known. It does not confirm the site is exploitable. Backported patches (which do not change the public version), WAF protection, and non-reachable code paths can all render a flagged site non-exploitable in practice.

• Header and version findings are a point-in-time snapshot. Each banner reflects the single moment Shodan last crawled that specific host, and different hosts were last crawled on different dates. Shodan's crawl cadence means some records may be days or weeks old. A site may have added security headers, upgraded PHP, or patched WordPress after its banner was captured, and that change would not be reflected here.

• Restricted-base percentages are stated over their base, not the full sample. The PHP figure (77% on end-of-life PHP) is calculated only over the subset of sites that actually exposed a PHP version in their headers, because PHP version disclosure is optional and many sites suppress it. It is not 77% of all 174 sites. All other percentages are over the full 174 unless explicitly noted.

Cite this study

This page is intended to be citable. If you reference these findings, please link to the source URL so readers can review the methodology and limitations.

Plain citation

APA style

The underlying aggregate findings on this page are released under a Creative Commons Attribution 4.0 International (CC BY 4.0) license. You may share and adapt the data, including for commercial use, with attribution to Cubite and a link to this page.

Run by Cubite

Ready to get started?

This scan was run by Cubite. If the findings have you reconsidering who owns your stack's patch cadence, you can - course content, users, and enrollments move through a one-click migration pipeline - or. Cubite is a managed LMS at a flat $290/month (unlimited users and courses, hosting, maintenance, and support bundled, 0% transaction fees, SCORM and xAPI, SSO, white-label, certificates, and analytics), so the version updates, runtime, and security headers measured above are handled for you

book a free migration assessmentmigrate from LearnDash to Cubite without losing data