Your Client’s Server Is Exposing MySQL to the Internet Right Now. Here’s How to Find It.

The web surface attackers actually probe

Most monitoring setups answer one question: is the site up? The more sophisticated ones add a second: is the SSL certificate valid? Both are worth checking. Neither is what an attacker checks.

Automated attack infrastructure scans the full HTTP response — every header returned, every port listening on the server’s IP address, every technology fingerprint embedded in the page HTML. This reconnaissance happens continuously, not once. Tools like Shodan and Censys index the entire public internet on a rolling basis, logging every service that responds on every port. Shodan alone indexes millions of internet-connected MySQL instances every week.

The threat is not sophisticated. It is automated and indiscriminate. A shared hosting server that has MySQL bound to a public interface isn’t targeted by a motivated attacker who found it manually — it’s found within hours by a crawler, added to a list, and queued for automated credential stuffing. The hosting admin who thought the server firewall was protecting it didn’t know that the firewall rule had a gap. Nobody checked.

This is the gap hosting security monitoring fills. Not “is the site responding?” but “what does an attacker see when they look at this server?” The answer is often alarming — and almost always fixable once you know about it.

Security headers — the silent configuration mistakes

Security headers are HTTP response headers that instruct the browser how to handle the page. They are set in the web server or application configuration — a single line per header — and they have no visible effect on the user experience. They are also almost universally misconfigured or missing on client sites that were set up and never revisited.

Each missing header represents a specific class of attack that becomes trivially viable:

HSTS deserves particular attention. Without a Strict-Transport-Security header, a browser that visited your client’s site once over HTTPS will happily accept a plain HTTP connection on the next visit if an attacker is in a position to intercept it — a coffee shop, a shared office network, a hotel Wi-Fi. SSLstrip exploits this: the attacker silently downgrades the connection to HTTP and reads everything in transit. The fix is a single response header. The risk of not having it is a live man-in-the-middle attack every time a user connects from an untrusted network.

Content-Security-Policy is more complex to configure correctly but has the highest attack-surface impact. Without it, any injected script — whether via a compromised third-party library, a stored XSS payload in a CMS comment, or a malicious ad — executes with full access to the page’s DOM, cookies, and local storage in your client’s origin context. With a properly scoped CSP, injected scripts are blocked before they execute.

Dangerous open ports — what’s listening that shouldn’t be

A web server needs to listen on port 80 and 443. It does not need to expose its database port to the public internet. Yet on shared hosting environments — and on VPS instances where the firewall was configured hastily or not at all — this happens constantly. The database service binds to 0.0.0.0 (all interfaces) instead of127.0.0.1 (localhost only), and suddenly the entire internet has a direct TCP connection to the database.

Redis is worth highlighting separately. Redis was designed as an in-memory data structure store for local use — its original default configuration had no authentication at all. A Redis instance exposed on port 6379 is not just a data exfiltration risk; it enables remote code execution. An attacker can issue a CONFIG SET dir andCONFIG SET dbfilename command sequence followed by SLAVEOF to write arbitrary files anywhere on the server filesystem — including SSH authorized_keys, cron jobs, or web-accessible PHP files.

MongoDB’s history is instructive. When MongoDB became popular in the mid-2010s, its default installation bound to all interfaces with no authentication. Hundreds of thousands of databases were left completely open. Automated tools found them, exfiltrated the data, deleted it, and left ransom notes. The databases were not targeted — they were found by the same kind of automated scanning that runs against every IP block on the internet today.

Technology fingerprinting and CVE scanning

Before an attacker exploits a vulnerability, they find one. The fastest path is reading what the server tells them for free: the technology stack, exact versions, and software components — all broadcast in HTTP response headers and page HTML by default.

Server: nginx/1.18.0
X-Powered-By: PHP/8.1.2
X-Generator: WordPress 6.3.1
X-WP-Total: 47

These four headers tell an attacker: the web server is nginx version 1.18.0 (patch notes for known CVEs are public), PHP is version 8.1.2 (check NVD for PHP/8.1.2 vulnerabilities), this is WordPress 6.3.1 (search the WordPress vulnerability database for that exact version and all installed plugins), and there are 47 posts (useful for enumeration). This reconnaissance took zero effort — the server volunteered it.

AIDE detects 50+ technologies from HTTP headers, HTML meta tags, JavaScript includes, and page content patterns. For each detected technology where a version is identifiable, AIDE cross-references the version against a CVE database. The result is not a vague “consider keeping your software updated” suggestion — it’s a concrete finding: “WordPress 6.3.1 with plugin X version Y has CVE-2025-XXXXX (CVSS 8.8 — authenticated arbitrary file upload).”

Removing version-disclosing headers — Server, X-Powered-By, X-Generator — costs nothing operationally. The application runs identically with or without them. But their presence or absence has a measurable effect on the attack cost: a scanner that can’t identify the exact version has to try every known exploit payload rather than targeting the specific CVE. Removing the headers does not fix underlying vulnerabilities, but it removes the easiest first step in the exploit chain.

Infrastructure intelligence and supply chain risk

Beyond the server itself, AIDE builds a picture of the infrastructure context around each domain: the hosting provider, CDN provider, WAF presence, ASN, geolocation, and IP neighbourhood. This matters because the server is rarely the only risk factor — the infrastructure it sits in poses its own risks.

Shared hosting environments are particularly relevant for agency-managed client portfolios. A client domain on a shared hosting plan sits on the same server as potentially hundreds of other tenants it has no relationship with. A compromised neighbour on the same IP block can affect your client’s domain in several ways:

• IP reputation: Spam sent from a compromised neighbouring site on the same IP address degrades the shared IP’s reputation — affecting your client’s email deliverability even though their own configuration is clean.
• Blacklist contamination: IP-based blacklists block the entire address — meaning your client site may be unreachable to users behind enterprise firewalls that use IP reputation filtering.
• Cross-site scripting via server misconfiguration: Shared hosting environments with poorly isolated PHP execution have historically allowed file-level access across tenant boundaries.

WAF and CDN detection matters for security posture assessment. A domain behind Cloudflare or a comparable WAF has a meaningfully different exposure profile than a domain with a direct A record pointing at a hosting server. The WAF absorbs the first layer of probe traffic, prevents many vulnerability scanners from reaching the origin, and provides DDoS mitigation. AIDE records WAF presence as a positive infrastructure signal and adjusts the hosting security assessment accordingly.

How hosting security integrates with the domain risk score

AIDE generates a Domain Risk Score from 0 to 100 — a composite score across five monitoring pillars. Understanding how the hosting pillar interacts with the overall score explains why hosting security findings that look like “minor” configuration issues can produce dramatic drops in the overall domain score.

At first glance, a 10% weight might suggest hosting security is a secondary concern. It isn’t — because of the critical cap rule.

The specific hosting findings that drive the score down fastest:

• Exposed database port (MySQL/MongoDB/Redis): Immediate −20 points from the hosting sub-score, triggering the cap threshold in combination with even minor header gaps.
• Critical CVE detected (CVSS ≥ 9.0): −25 points — a single unpatched WordPress core vulnerability with a critical CVSS score can floor the hosting score on its own.
• Missing HSTS: −10 points — combined with a missing CSP (−10) and an open port, the hosting score is in critical territory.

For agencies reviewing client domain risk scores, a hosting score below 50 is an immediate action item, not a “nice to fix eventually” note. The findings that produce a sub-50 hosting score are the kind of exposures that appear in incident reports — not best-practice recommendations.

For an agency managing 30, 50, or 200 client domains, running this checklist manually — even once per quarter — is not realistic. Port exposure changes when a hosting provider updates a control panel. CVEs for installed WordPress plugins are published daily. Security headers set at launch get quietly stripped by a CDN configuration change or a WordPress plugin that outputs its own headers.

The only way to know what an attacker sees when they look at your client’s server is to look continuously — with the same automated perspective attackers use, and with alerting that fires the moment the exposure appears, before someone else finds it first.