A vulnerability in a hosted-only service can be recorded with a CVE ID, and the CVE Record Format has a tag for it called exclusively-hosted-service. The tag means every known affected product exists only as a hosted service. If the flaw also touches on-premises or downloadable versions, the tag should not be used.
What the tag says
The CVE Project publishes the list of CNA tags in its schema repository. The text for this one says it is used when all known affected software or hardware exists only in a hosted service, and that it should not be applied if the flaw affects both hosted and on-premises versions.
So the tag is a label on the record, not a rule about whether a record may exist. It tells a reader of the record that there is nothing for them to patch, because the vendor fixes the service on its side.
Why the label matters to customers
Consider what each audience does with a CVE for a hosted flaw:
| Audience | What they do with the record |
|---|---|
| Customers of the service | Learn the issue existed and was fixed, check for impact on their data |
| Auditors | Find a dated, public statement of the flaw and its fix |
| Scanner users | Should not see an alert for software they cannot update |
The third row is the practical one. Without the tag, a scanner has to guess whether a version string applies to anything you run. With it, tools can suppress the alert or route it differently.
When the tag is the wrong choice
Use plain records when any of these is true:
- A self-hosted edition exists and shares the vulnerable code.
- A client library, agent, plugin or CLI that customers install is affected.
- A container image or appliance built from the same code is shipped.
In each case something downstream must be updated, so the record should list those products and versions without the hosted-only label.
What a product team should do
If you run a SaaS product and fix a serious flaw before anyone can exploit it for long, you have a choice about publishing. Many teams write a short advisory with the timeline, impact, and the fact that customers need take no action. Whether that advisory also gets a CVE ID depends on the rules of whichever CNA you ask, so check with them first. The order of contact for CVE IDs is a good starting point.
Do not fake a version number to make a hosted bug look like a library bug. The affected field should describe what actually shipped.
Quick check
Does the tag mean a hosted flaw is less serious?
No. It describes where the vulnerable code lives, not how severe the issue is. A hosted flaw can expose a lot of data.
Can I use the tag if I also ship a self-hosted version?
No. The tag's description says it should not be used when the flaw affects both hosted and on-premises versions.
If you build an advisory process for your own product, Safeguard's policies, gates and compliance evidence automation can keep the disclosure steps recorded. A free scan shows what your dependencies already carry.
Sources
Last reviewed: 19 October 2026.
