What a VulnVerify report looks like
This is an illustration of how we write up a finding — the reasoning, the evidence and the remediation you get. The organisation has been anonymised. The vulnerability is real and publicly documented. Your own report is a PDF written by the researcher who reproduced the finding, so its headings follow the finding rather than a fixed template.
Unauthenticated remote code execution on a public-facing host
staging-cms.example-corp.com
- Finding ID
- VV-2026-0418
- Severity
- Critical
- CVSS v3.1
- 9.8
- CVE
- CVE-2017-9822
- CWE
- CWE-502 · Deserialization of Untrusted Data
- Status
- Unresolved at time of disclosure
1 · How we found it
The part you cannot see from inside your own network
This host surfaced on 14 July 2026 in our monitoring of sources where exposed infrastructure is collected and circulated — in a list of hosts grouped by the exact software version running here.
That is the whole point of the finding. A vulnerability you have is a problem you can schedule. A vulnerability already sitting on somebody else's list is a problem with a clock on it — and that list lives outside your perimeter, so nothing you run inside it will ever tell you that you are on one.
2 · What it is
Written for the engineer who has to fix it
The host runs a Kentico CMS release that exposes the staging synchronisation endpoint at /CMSPages/Staging/SyncServer.asmx without authentication. The endpoint accepts a serialised .NET object and deserialises it before any identity check runs, so a request from the open internet is executed with the privileges of the application pool.
The result is remote code execution by an unauthenticated caller. There is no configuration that mitigates it while the endpoint remains reachable, and the affected version is listed in public exploitation databases, which is why it is rated 9.8 rather than merely high.
3 · Proof it is real
Redacted on this page — see the note
Withheld from this public page, deliberately.
Your report contains the evidence that this endpoint is exposed and reachable, with a timestamped capture — enough for your team to confirm it themselves in one step before they touch anything.
We are not publishing that request here. This page has no login, and the vulnerability is real: printing a working exploit on it would help the people we exist to warn you about. A security vendor that would publish it to win your business would publish yours too.
4 · How to fix it
Specific, ordered, and testable
- Block external access to
/CMSPages/Staging/at the edge. This closes the exposure in minutes and buys time for the rest. - Upgrade to a Kentico release where the endpoint enforces authentication, or disable staging synchronisation entirely if the environment does not use it.
- Treat the host as suspect until proven otherwise. Unauthenticated RCE that has been publicly listed should be assumed reachable by others, so review application-pool process history and outbound connections for the period since it first appeared.
- Re-test. Reply to the report and we re-check the host at no charge and confirm in writing that it is closed.
Want to know whether anything of yours is on a list?
Enter your domain. We will tell you how many verified findings we hold for it, how many of those are critical, and when we last verified one — before you pay anything. The findings themselves, including the affected hosts, come with a plan or a single unlock.