Hosting Reputation Flagged? What It Means and How to Fix It

What hosting reputation actually measures

GuardHound's Hosting Reputation dimension answers a single question: are the IP addresses your domain currently points at known to be involved in bad activity? Every domain you monitor is resolved on a rolling schedule, every IP that comes back is checked against AlienVault OTX — the largest open threat-intelligence community — and the worst pulse count across all of those IPs becomes your hosting score.

A pulse is a community-shared report linking an IP, domain, file hash, or URL to a specific threat campaign — phishing kits, malware command-and-control infrastructure, botnet members, scanning hosts, spam senders, and so on. When an IP collects three or more active pulses, GuardHound surfaces a warning finding so you can decide what to do.

What counts as “active”? Pulses age out. GuardHound only counts pulses that the OTX community considers current threat-intel, not historical reports from years ago.

Why an IP can be flagged

There are three distinct reasons your IP might be sitting on a pulse list, and the right response depends entirely on which one applies to you.

1. Shared infrastructure noise (most common)

If you host on Cloudflare, Vercel, Netlify, AWS, Squarespace, Shopify, WordPress.com, or any other shared platform, hundreds or thousands of unrelated tenants can route through the same egress IP that your domain resolves to. If a single neighbor on that IP runs a phishing kit or gets compromised, the IP picks up pulses that have nothing to do with your domain. This is by far the most common cause of a hosting reputation warning.

2. A genuine compromise on your origin

If you run on a dedicated server, a VPS, or a small-tenant cloud host, your IP is meaningfully “yours.” Pulses on that IP are far more likely to be about you specifically — a defaced page, a webshell, an exposed admin panel, an outbound spam relay, or something using your server as a staging point. This is the case that matters and it warrants immediate investigation.

3. Inherited reputation from a previous tenant

If you recently migrated to a new IP that was previously occupied by a bad actor, you can inherit their reputation problem until the pulses age out. This is common with cheap VPS providers and recycled cloud IPs. The fix is usually a fresh IP from your provider rather than ongoing remediation.

How to investigate: noise or real?

The hosting_reputation finding in your portal includes the actual pulse evidence — the IP, the active pulse count, and the names of the pulses themselves. Read those names. The decision tree is short:

Probably noise — dismiss

None of the pulse names mention your hostname or origin

The pulses are about other domains, other malware families, or generic "scanning host" / "open proxy" reports. You are on shared infrastructure and inherited a neighbor's bad reputation. Dismiss with a brief reason and your score will recover on the next scan.

Real — investigate now

A pulse name references your domain, hostname, or a URL on your site

Treat this as an active incident. Check your access logs, look for new files in your webroot, audit any admin or API credentials that were active in the last 30 days, and consider rotating credentials before doing anything else. The pulse name is itself the lead.

Three remediation paths

Once you know which case you are in, there are three real options. Pick the one that matches the evidence — not the most aggressive one.

  1. Verify and dismiss (shared-CDN noise) By far the most common path. You confirmed the pulses do not name your hostname, you are on shared infrastructure, and the egress IP is not actually under your control. Click × Dismiss on the finding row, write a one-sentence reason like “Cloudflare shared egress; pulses reference unrelated tenants”, and the score recovers immediately. The dismissal stays scoped to your org and this domain — it does not silence the same finding on other domains, and it will resurface if the situation gets materially worse.
  2. Request a fresh egress IP (inherited reputation) You are on a dedicated or small-tenant host and you suspect the previous tenant. Open a support ticket with your hosting provider, reference the pulse evidence, and ask for a fresh IP. Most providers will rotate your IP within a business day at no charge if you can show concrete reputation damage (mail bouncing, blocklist hits, GuardHound finding). On AWS / GCP, this is a cheap and routine operation — release the elastic IP and allocate a new one.
  3. Migrate origin to a different provider (real compromise or chronic issue) Reserve this for the case where the pulses genuinely name your hostname, where a fresh IP from the same provider would just collect new pulses (because the provider's whole IP range has a poor reputation), or where you have already tried path 2 without lasting improvement. Migration is disruptive — do incident response first, then plan the move.

If pulses name your hostname, do incident response before migrating

Moving servers does not remove a webshell or stolen credentials — it just relocates them. Audit, rotate, clean, then move.

When and how to dismiss the finding

Dismissing a finding in GuardHound is a first-class action, not a workaround. A dismissal records your team's judgement that “this finding is not a real issue for our domain,” greys it out in the portal so you do not see it as an outstanding issue, and zeros out its contribution to your score so the headline number reflects your real posture.

The dismissal is scoped to your organization, the specific domain, and the specific finding key. It does not affect other domains, and it does not hide the underlying evidence — the pulse list stays expandable beneath the dismissed row so a teammate can audit your reasoning later.

If the situation changes — pulse counts grow significantly, or new pulses appear that name your hostname — the next monitored scan will surface a fresh finding so you can re-evaluate. You can also restore a dismissal at any time using the “Restore” button on the same finding row.

Run a free scan to see your hosting reputation

Get a 0–100 score across eight dimensions, including hosting reputation, with the actual pulse evidence so you can decide whether it is noise or a real incident.

Frequently Asked Questions

What does it mean when GuardHound flags my hosting reputation?
It means at least one of the IP addresses your domain currently resolves to is cited in three or more active threat-intelligence (OTX) pulses. A pulse is a community-shared report linking an IP to malicious activity. The IP itself was flagged — that does not necessarily mean your website is compromised.
Why is my IP flagged when my site is fine?
On shared hosting, CDNs, or platforms like Cloudflare, Vercel, and AWS, hundreds of unrelated tenants can share the same egress IP. If a neighbor runs a phishing kit or gets compromised, the IP collects pulses that have nothing to do with your domain. Always read the pulse names — if none mention your hostname, it is almost certainly noise.
Should I move hosting providers if my IP is flagged?
Not as a first response. Start by reading the pulse evidence. If the pulses look like neighbor noise on shared infrastructure, dismiss the finding with a brief reason. Migrating origin or requesting a fresh IP is the right move only when the pulses specifically reference your hostname, or when you are repeatedly being shadow-flagged by mail providers.
How does GuardHound source this threat-intelligence data?
GuardHound queries AlienVault OTX (Open Threat Exchange), a free community threat-intelligence feed used by security researchers and incident responders worldwide. Every IP your domain resolves to is checked on a rolling schedule, and the pulse counts and pulse names you see are the live data returned by OTX.
Will dismissing this finding hide the warning forever?
Dismissals are scoped to your org, domain, and finding key. If the underlying pulse count grows or new pulses name your hostname, the finding will surface again on the next monitored scan. You can also restore a dismissal at any time from the same finding row in the portal.