Cyber Security

How a Casino Domain Hijacked My Clients SEO Through nginx Host Header Abuse

Client: Bhumi Interior Solution Industry: Interior Design Domain: bhumiinteriorsolution.in The Challenge: Google was indexing the client’s website unde…

By Hitarth Shah · May 12, 2026 · 11 min read

How a Casino Domain Hijacked My Clients SEO Through nginx Host Header Abuse

Client: Bhumi Interior Solution
Industry: Interior Design
Domain: bhumiinteriorsolution.in
The Challenge: Google was indexing the client’s website under a spam casino domain
Root Cause: nginx host header misconfiguration enabling SEO poisoning
Outcome: Spam domain neutralised, infrastructure hardened, Google reindex initiated, brand integrity restored

A routine Google search for a client’s website turned up something that shouldn’t have been there. Their real content — the actual pages, the legitimate interface — was loading, but the domain Google displayed was a spam casino site. There was no malware. No injected scripts. The server looked clean on every standard check. The culprit turned out to be a subtle nginx misconfiguration that almost no one talks about, yet quietly affects thousands of VPS-hosted sites. Here is what happened, how we diagnosed it, and the fix any developer can apply.

The Discovery

While running a routine SEO check on the client’s website, we expected to see their familiar domain in Google’s search results:

bhumiinteriorsolution.in

Instead, Google was displaying a completely unrelated domain:

top10casinogame.cc

Even stranger, clicking through to that casino result did not lead to a casino site at all. It loaded the client’s real website — the same pages, the same content, the same design — just served under a fake domain. Every URL on the spam domain, including paths like top10casinogame.cc/contact, returned the legitimate frontend.

For a customer-facing business that depends on search traffic and brand credibility, this was a serious issue. Visitors arriving from Google would see a casino domain in their address bar, hurting both rankings and trust. We needed to understand what was happening — and fast.

Initial Hypothesis: A Compromised Server

The first instinct was the obvious one: the server had been breached. Malware. Backdoor scripts. Cloaking. Injected redirects. We started by looking for anything modified in the last week — a common signature of recent compromise:

find /var/www -type f -mtime -7

This command lists every file in the web root modified within the last seven days. If an attacker had recently dropped a payload, it would surface here. Nothing suspicious appeared.

Next, we looked for stray PHP files. The site doesn’t use PHP, so any .php file in the web root would be a red flag:

find . -name "*.php"

Nothing turned up. We then scanned for classic malware fingerprints — the obfuscation patterns attackers love to use:

grep -R "eval(base64" /var/www
grep -R "gzinflate" /var/www
grep -R "shell_exec" /var/www

These three patterns — eval(base64, gzinflate, and shell_exec — together cover the vast majority of webshells and PHP-based malware. A recursive grep across the entire web root for all three came back completely clean.

We expanded the audit:

Cron jobs — no unfamiliar scheduled tasks
PM2 process logs — no suspicious child processes
nginx rewrite rules — no rogue redirects
Source code — no hidden iframes or injected JavaScript

Every check came back clean. That was the first real clue — this was not a traditional compromise. Something else entirely was happening.

The Real Culprit: Host Header Abuse and SEO Poisoning

The breakthrough came from the nginx access logs. Buried in the traffic, we found requests arriving with the spam domain in the Host header:

https://top10casinogame.cc/

The fake domain was pointing directly at our server’s IP address — and nginx was happily serving the client’s real frontend in response. The implication was clear:

nginx was configured to accept any Host header at all.

A request arriving with Host: top10casinogame.cc was being served identically to a request with Host: bhumiinteriorsolution.in. The server didn’t care which domain was being requested — it returned the same content for both. That is exactly why Google was indexing the client’s content under the spam domain.

This isn’t a website hack in the traditional sense. The codebase is untouched. The server is technically functioning correctly. But the SEO surface has been silently hijacked by anyone with a domain name and the ability to point it at the right IP address.

Anatomy of the Attack

The attack flow is deceptively simple:

An attacker registers a spam domain (e.g. a casino, pharmacy, or gambling site)
They point that domain’s DNS A record to the victim’s VPS IP address
Google’s crawler resolves the spam domain, finds it points to the victim’s server, and sends a request
The victim’s nginx accepts the request regardless of Host header and serves the legitimate website
Google indexes the content under the spam domain, attributing the site to the attacker’s URL

The damage compounds quickly: SEO poisoning, fake mirrors of the real site appearing in search, spammy indexing crowding out legitimate listings, and a slow erosion of brand trust. Worst of all, the victim’s server appears entirely unhacked. Most developers never realize this is happening until they happen to search for their own site.

Why nginx Was Vulnerable

The vulnerability stems from how nginx is configured by default in many tutorials and quick-start guides. Two specific directives create the problem:

server_name _;

The underscore is a catch-all — it tells nginx to match any host name. Combined with:

listen 80 default_server;

…which makes that server block the default for any unmatched request, the result is an nginx instance that will serve your website’s content to anyone with a domain pointing at your IP. There is no host validation. Any Host header is acceptable. This is fine on a fresh server with no public traffic, but on a production VPS it leaves a wide-open door for SEO hijacking.

The Fix: Strict Host Validation

The solution is to make nginx strict about which domains it will respond to. We added an explicit host check inside the main server block:

if ($host !~ ^(bhumiinteriorsolution\.in|www\.bhumiinteriorsolution\.in)$ ) {
    return 444;
}

This rule examines the $host variable for every incoming request. If the host doesn’t exactly match one of the legitimate domains, nginx returns HTTP status 444 — a special nginx code that closes the connection immediately without sending any response. To a Google crawler hitting the spam domain, the server now appears unreachable.

We then added default reject servers as a belt-and-braces measure. These catch any request that doesn’t match a named server block at all:

server {
    listen 80 default_server;
    return 444;
}

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

The first block handles plain HTTP and instantly drops any unrecognised request. The second handles HTTPS using ssl_reject_handshake — an nginx directive that refuses the TLS handshake itself, so the connection never even gets to the application layer. Together, these two server blocks act as a perimeter wall: any request arriving with a Host header we don’t explicitly recognise is rejected before it can do any harm.

Verifying the Fix

The verification test is simple. From the server itself, we send a request with a deliberately fake Host header and see how nginx responds:

curl -H "Host: fakecasino.com" http://127.0.0.1

Before the fix, this command returned the full HTML of the client’s website. nginx happily served the real frontend in response to a fake domain.

After the fix, the same command returns exactly what we want to see:

curl: (52) Empty reply from server

This is curl’s way of saying the connection was closed without any response — exactly the behaviour we configured with return 444. Unknown hosts now get nothing.

Defense in Depth: Additional Hardening

Fixing the host header issue closed the main door, but we used the opportunity to harden the wider attack surface as well.

Security headers

We added the standard set of browser-enforced security headers to the nginx config:

X-Frame-Options — prevents the site from being embedded in iframes on other domains (defeats clickjacking)
X-Content-Type-Options — stops browsers from MIME-sniffing responses, reducing the risk of malicious content type confusion
Content-Security-Policy — declares which sources can load scripts, styles, and resources, blocking injected third-party assets
Referrer-Policy — limits how much referrer information leaks to other sites when users click outbound links

Blocking hidden files

Dotfiles like .env, .git, and .htaccess should never be web-accessible — they often contain secrets or sensitive metadata. This rule denies access to anything starting with a dot:

location ~ /\. {
    deny all;
}

Disabling PHP execution

The site is a Node-based React application — there is no legitimate reason for PHP to ever execute on this server. Blocking all PHP-related extensions prevents a future malware drop from being executable, even if one somehow lands on disk:

location ~* \.(php|phtml|phar)$ {
    return 403;
}

Canonical tags

To explicitly tell Google which domain is the authoritative source, we set a canonical link tag in the site’s HTML head:

<link rel="canonical" href="https://bhumiinteriorsolution.in/" />

Even if the spam domain somehow got around the nginx rules in future, this canonical tag would tell Google to attribute the content back to the real domain.

Updated robots.txt

Finally, a clean robots.txt that allows full crawling of the legitimate site and points to the correct sitemap:

User-agent: *
Allow: /

Sitemap: https://bhumiinteriorsolution.in/sitemap.xml

Cleaning Up Google’s Index

Locking down the server stopped the bleeding, but Google’s index still held the poisoned entries. To clean it up, we worked through Google Search Console:

Used the Remove Outdated Content tool to request removal of the spam-domain URLs from Google’s cache
Resubmitted the legitimate sitemap to encourage Google to recrawl the real domain
Requested fresh indexing of the canonical URLs to accelerate the cleanup

This kicks off Google’s natural reindexing cycle, which typically resolves over the following days and weeks as the spam URLs return 444 errors on recrawl and get dropped from the index.

A Bonus Discovery: Deployment Pipeline Issues

While auditing the infrastructure, we uncovered a separate set of deployment problems that had been quietly degrading the site:

Stale Docker images being reused across deployments
Old frontend builds lingering in the serving directory
Cached distribution folders shadowing the latest build
Mismatched canonical tags between builds
Service-worker caches serving stale content to returning visitors

Rather than patch around these issues, we rebuilt the deployment pipeline with five concrete improvements:

Atomic frontend deploys — new builds either go live entirely or not at all, eliminating half-deployed states
Build verification steps — automated checks run against every build before it can be promoted
Strict nginx serving rules — only the current build directory is served; old artifacts are inaccessible
Deterministic Vite builds — locked dependencies and reproducible build outputs
Zero-downtime PM2 reloads — process restarts happen without dropping any in-flight requests

The result is an infrastructure that is not only more secure, but also more predictable for future updates.

Outcomes Delivered

After the engagement, every concrete deliverable was in place:

✅ Fake domains blocked at the nginx level — verified with curl tests
✅ HTTPS handshake rejection for any unrecognised host
✅ SEO poisoning vector closed
✅ Canonical tags pointing to the legitimate domain
✅ Clean robots.txt and sitemap published
✅ Security headers added (X-Frame-Options, CSP, Referrer-Policy, X-Content-Type-Options)
✅ Hidden files and PHP execution blocked
✅ Deployment pipeline rebuilt for atomicity and reproducibility
✅ Google reindexing initiated through Search Console
✅ Infrastructure stabilised end-to-end

The Bigger Lesson: “Loading Fine” Isn’t “Secure”

The most important takeaway from this engagement is a quiet assumption many developers carry:

“If the site loads fine, everything is fine.”

It isn’t. If nginx accepts arbitrary Host headers:

SEO can be silently hijacked without any visible site issue
Content can be mirrored under spammy domains without server compromise
Google can index legitimate work under fake URLs
Spammy operators can piggyback on someone else’s traffic and authority

All of this can happen while every uptime check, performance test, and malware scan returns green.

Quick Self-Audit: Is Your Site Vulnerable?

If you run your own VPS, you can test for this vulnerability in under a minute. Run this single command from the server itself:

curl -H "Host: fakecasino123.com" http://127.0.0.1

If the response contains any of the following, your server is vulnerable to host header abuse:

Your site’s HTML
A redirect to your real domain
Any frontend content at all

A secure server, by contrast, should return:

curl: (52) Empty reply from server

If you’re vulnerable, the nginx config snippets earlier in this article will fix it.

Final Thoughts

This whole investigation looked, at first, like a serious compromise — malware, SEO spam injection, cloaking, casino-domain hacks. The kind of incident that usually means restoring from backup. The actual cause turned out to be something much more subtle: a single line of nginx config working exactly as advertised, just not as intended.

We suspect this same misconfiguration is silently in place on thousands of VPS-hosted React, Next.js, and other modern web app deployments right now. If you run your own server, take five minutes today to:

Check your nginx Host header validation
Add explicit reject rules for unknown domains
Set canonical tags and audit your robots.txt
Search Google for your site to confirm no spam domains are riding on your content

A site that loads correctly is not the same as a site that is secure. The difference, in this case, was one config block away.