Start with a verified advisory

If you receive a report about a compromised update or network incident, confirm it through the software publisher’s official channels. This guide does not establish that a particular historical incident affected your node. Record the advisory and the systems it actually names.

Preserve useful evidence

Record installed versions, update times and relevant logs. Avoid repeated updates or cleanup actions before understanding what they would change. Keep customer credentials and unrelated personal information out of diagnostic messages.

Assess the affected environment

Compare the advisory scope with your host and update history. If compromise is suspected, involve the responsible administrator and plan containment, credential handling and recovery using verified guidance. Treat host access and customer virtual-machine access as separate parts of the investigation.

Separate service support from security response

Use LicenseCage support for your license and activation questions. A working license is not evidence that a server is uncompromised. Infrastructure recovery and software-publisher advisories require their own checks.

A practical example

A report about networking or an update can mix together provider routing, control-panel software and an individual compromised host. Establish which component the evidence concerns before taking action. A missing route does not by itself establish a BGP hijack, and a software upgrade does not by itself prove that a routing incident is resolved.

Checks to make

  • Record the observed symptom, affected addresses and time of the event.
  • Compare the provider's network status with the host and guest configuration.
  • Use the vendor's current notices to establish any affected software release.
  • Preserve relevant logs and a recovery route before making production changes.

Making the decision

Keep unverified claims separate from confirmed observations when briefing customers or support. This guide intentionally provides a verification process rather than alleging a current incident. The right response depends on whether the evidence identifies a provider route, a local configuration error or a software issue.