Version Extraction: Reading a Tech's Exact Version

## Why it matters

Knowing the version often matters more than knowing the technology exists. A site running WordPress 6.0 is three major releases behind the current stable version, which means it carries known vulnerabilities. A jQuery version mismatch between your test and production can cost hours of debugging. The version is often the most actionable fact a detector produces.

But detection should never guess versions. If a script URL includes no version string, you can't know what's running. Minified assets stripped of version info, third-party embeds that don't expose their version, and version-agnostic CDN URLs all defeat version extraction. That's the honest answer: absence of a version means the page didn't expose one, not that the version is unknown or doesn't matter.

## How it works

Version extraction is pattern-driven. The fingerprint database records not just what to look for, but where in the matched text the version lives. When a match fires, regex capture groups extract the version substring.

Take jQuery loaded from a CDN. The script URL might be https://code.jquery.com/jquery-3.6.0.min.js. The fingerprint pattern looks for the sequence jquery followed by a version pattern, and capture groups extract the 3.6.0 part. When multiple version candidates show up in the same match, the most specific one wins.

WordPress exposes the version in the generator meta tag. The matched text is WordPress 6.4.2, and a capture group in the fingerprint pattern yields 6.4.2. Script URLs with version query strings like ?ver=3.6.0 also yield the version this way.

JavaScript globals can carry version too. A library might store window.jQuery.fn.jquery = "3.6.0". Scalpel Stack walks the object and extracts the value.

The capture syntax is defined in the open fingerprint database. Every version that appears was read from the page, never synthesised or guessed.

## What does not matter

A missing version is not a failure or an error. It means the page didn't expose it. Many modern build systems strip version strings from bundles for security or size reasons. A site using a JavaScript bundler that minifies and re-exports libraries under new names exposes no version to detect. That's fine, and it's real. Scalpel Stack shows what's on the page, not what you wish was there.

Also, the absence of a version chip doesn't mean detection is wrong. You might be looking at a technology that doesn't expose its version on the page at all. A PHP-based site detected by PHPSESSID cookie might be running PHP 8.2, but the cookie name alone doesn't tell you which.

## Code example

Here are three real examples of how versions are extracted:

Script URL with version in the path:

<script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
Copy

The fingerprint pattern looks for jquery and a semantic version pattern in the URL, and the capture group extracts 3.6.0.

Meta generator tag with version:

<meta name="generator" content="WordPress 6.4.2" />
Copy

The pattern captures the substring after "WordPress " and yields 6.4.2.

Query string parameter:

<script src="/js/bootstrap.min.js?ver=5.3.0"></script>
Copy

The pattern matches the ?ver= parameter and extracts 5.3.0.

## How Scalpel shows it

When Scalpel Stack detects a technology with a version, a version chip appears on the row next to the name, showing the exact string that was extracted. In the expanded evidence list, the legend row reads "Version X" only when a version was captured. If no version chip appears, the technology was detected but the page didn't expose the version in any of the traces Scalpel Stack reads.

This is one of the extensions' strengths: you see what the page actually reveals, not a guess or a stub like "latest" or "unknown". That honesty is what makes the data trustworthy for real decisions.