Wordpress detection change it too loose and causing false positives

[lauren-rmtech]

Platform

Wappalyzer browser extension / core detection engine (WordPress technology detection)

Describe the bug

After a recent update, the WordPress detector now produces false positives.
The DOM selectors were previously combined into a single rule, but they have been split into multiple independent selectors:

– div[class*=‘wp-block-group’] > div[class*=‘wp-block-’]
– link[rel=stylesheet][href*=’/wp-content/’]
– link[rel=stylesheet][href*=’/wp-includes/’]
– link[href*=’.wp.com’]

Because each selector is now evaluated independently, any single weak indicator (for example a single /wp-content/ or .wp.com reference) is enough to detect WordPress.

This causes false positives when third-party scripts (such as Google Tag Manager or CDNs) inject resources that match these patterns.
This behaviour did not occur prior to the rule change.

To Reproduce
1. Visit a non-WordPress website where Google Tag Manager injects a resource containing /wp-content/, /wp-includes/ or .wp.com.
2. Open Wappalyzer.
3. WordPress is detected even though the site is not running WordPress.

Example of what gets unintentionally matched (conceptually):
[src^=’/wp-content’], meta[name=‘generator’][content^=‘WordPress ‘], link[rel=‘dns-prefetch’][href=’//s.w.org’]

Expected behavior

WordPress should only be detected when multiple strong indicators are present, such as block-editor DOM structure, the WordPress generator meta tag, or both /wp-content/ and /wp-includes/.

Third-party injected resources should not trigger detection alone.

Additional context

The regression seems to come from splitting the original combined selector into several stand-alone selectors, making the detector overly permissive.
A more robust detector would group related signals or require more than one to match before identifying WordPress.

The commit that introduced this change was 7316fe9#diff-0e44086638908c6c3d6cd9e5418f5e94ec1063b006ce13c193aa38118a2f2dab

[enthec-opensource]

The DOM selector has been refactored from a single comma-separated string

"div[class*='wp-block-group'] > div[class*='wp-block-'], link[rel=stylesheet][href*='/wp-content/'], link[rel=stylesheet][href*='/wp-includes/'], link[href*='.wp.com']"

to an array of individual selectors
[
"div[class*='wp-block-group'] > div[class*='wp-block-']",
"link[rel=stylesheet][href*='/wp-content/']",
"link[rel=stylesheet][href*='/wp-includes/']",
"link[href*='.wp.com']"
]

Both should give the same results since comma-separated DOM selectors work as an OR operator in CSS. The paths wp-content, wp-includes, and wp.com are pretty standard WordPress identifiers.

This new array structure lets implementations decide whether to use AND or OR logic based on their needs as well as different confidence to each making it more flexible. We could use the confidence tag to mark patterns that are less reliable and avoid false positives when these paths show up in other libraries that aren't WordPress https://github.com/enthec/webappanalyzer?tab=readme-ov-file#tags

Got any examples of websites where you're seeing this behavior? That'd help us fine-tune the pattern.

[lauren-rmtech]

Thanks for looking into this.

We are seeing it on our main website, https://hexiosec.com/ and it seems to be because the google tag manager script, gtm.js has the wp-content string, which seems to be code to detect wordpress.

[enthec-opensource]

Okay, now I see,

This is an "unofficial fork" of Wappalyzer, which went private about 2 years ago. We try to sync with the official Wappalyzer as well as other sources.

The false positive detection you are seeing is probably linked to the official Wappalyzer extension in Chrome/Firefox. That version is closed source right now, and it fully depends on their private regex and how they use them.

We also maintain a library for detections, but ours should not give those false positives because we are not running DOM selectors over files that are not... well... a DOM (this seems to be a .js file).

Could you tell me if you are using a detection library or the official Wappalyzer?

If you are using either our library or another open source one, we will try to fix this ASAP. However, if this is about the official Wappalyzer, I think there is no other solution than to talk to them directly, since we are not the maintainers of that version.

[lauren-rmtech]

We use your technology definitions, and we run them with our own maintained build of the open-source Puppeteer driver that Wappalyzer previously published before moving to closed-source.

[enthec-opensource]

Is that build running the dom selectors against js files?, because i see the official wappalyzer also reporting a wordpress on your website from the browser extension (at least on chrome) with their own private regex and processors, so that makes me think the false positive has more to do with how they process the website, since they have their own patterns and confidence, our library is not compatible with puppeteer or selenium so it won't help anyways.

[lauren-rmtech]

Ah, interesting that Wappalyzer is reporting it too. We use the technology definitions from this repo with the DOM selectors, and they’ve worked great so far.

I’ve raised a story in our backlog to review the WordPress detection and look at improving the definition. We may also submit a fix once we’ve tested an approach that avoids the false positives.

Thank you for looking into this.

[kerimkaraca]

@enthec-opensource I'm having the same issue. It detects Wordpress on https://bayegan.net which is false positive. Google Tag Manager js content matches with "scripts" matcher.

Maybe the "scripts" part can be updated to exclude GTM scripts like:

"scripts": [
  "^(?:(?!googletagmanager).)*wp-content"
] 

Thanks in advance.