OpenCloud Security Scanner Logo Security scan for OpenCloud

CLI documentation

Version and lifecycle disclosure checks explained

How the OpenCloud Security Scanner checks that a version was determined at all, and whether it leaks in a header or webfinger.

These checks establish whether the scanner knows the running version and whether the instance publishes it in unnecessary places. They complement end-of-life detection and the update check, both of which need a reliable version number.

1. Could the running version be determined at all: versionDetection

/status.php reports up to three version-shaped fields, and only one of them is the real release - see Reading the version correctly for what the other two are and why they exist, and Why OpenCloud still answers /status.php for where the endpoint and its hardcoded fields come from. This check fails when productversion is missing and only the legacy compatibility version/versionstring fields came back.

Without the actual version, the scanner cannot match advisories or determine support status and available updates. These checks do not run when the version is missing, so their results remain unknown.

If this fails: check whether something in front of the instance rewrites or strips fields from the /status.php response, and whether the release is old enough that it predates productversion being reported at all. Until a real version comes back, treat every version-dependent part of the result as unknown rather than as clean.

2. Does a response header publish the version: versionDisclosure:<header>

The Server and X-Powered-By response headers are each checked for anything that looks like a version number (a digit, a dot, another digit). Publishing a version number is not a vulnerability by itself, but it helps attackers identify known vulnerabilities to target. Both findings are rated low.

Fix: strip or flatten the header in the reverse proxy - server_tokens off in Nginx, ServerTokens Prod in Apache - or unset it outright. See Reverse proxies for the equivalent directive on Caddy, Traefik and HAProxy.

3. Does the webfinger document publish the version: webfingerVersionDisclosure

/.well-known/webfinger is requested unauthenticated (as any federation client would) and its response is checked for the running version, the same way the two response headers above are. It is the same class of finding as versionDisclosure - low-severity information disclosure, not a vulnerability - just read from a JSON document instead of a header.

Fix: strip the version from the webfinger response in the reverse proxy, or accept the disclosure and prioritise keeping the instance current instead: the version only matters as intelligence while a known advisory against that exact release is still unpatched.

Severity and rating impact

All three are extraChecks, reported and rating-capped on every scan - versionDetection at medium (caps the rating at A), the two disclosure checks at low (caps it at A+) - see the extra-checks table in the main README. None require --check-hardening, and none of them are the same thing as the end-of-life rating: a current, fully disclosed version and an end-of-life, well-hidden one are graded on entirely different axes.