The 5 Vulnerabilities Hackers Look for First on Small Business Websites

Tactical Guide Website Security

April 2026  ·  8 min read

Before a hacker spends a single minute on your business, automated tools have already done a scan. Here's exactly what they're looking for — and what to do about each one.

---

There's a common misconception about how small businesses get hacked. People imagine a skilled attacker sitting at a keyboard, manually probing a specific company they've decided to target. In reality, most attacks against small businesses start with automation — bots that crawl the internet around the clock, cataloguing every vulnerability they find and flagging the easiest targets for follow-up.

The good news: these bots are looking for the same things, over and over. The vulnerabilities that get small businesses compromised aren't exotic or sophisticated. They're well-known, well-documented, and — most importantly — fixable. Here are the five your website is most likely to be scanned for right now.

30K+ websites are hacked every day globally, the vast majority automated attacks

95% of successful breaches exploit known vulnerabilities that had available patches

6 hrs median time for a new vulnerability to be actively scanned after public disclosure

1

Outdated software and unpatched CMS Critical

WordPress, Joomla, Drupal, plugins, themes

If your website runs on a CMS like WordPress — and roughly 43% of the web does — outdated core software, plugins, or themes are the single most common entry point for attackers. Bots actively scan for version numbers exposed in page source code or HTTP headers and cross-reference them against databases of known CVEs.

A plugin that hasn't been updated in six months may have a publicly disclosed exploit with a working proof-of-concept freely available online. The attacker doesn't need skill — they just need a list of vulnerable sites, which the bot builds automatically.

Fix Enable automatic updates for CMS core, plugins, and themes. Audit installed plugins quarterly and remove any that are abandoned or unused. Consider a managed WordPress host that handles patching automatically.

2

Exposed admin login pages Critical

/wp-admin, /admin, /login, default paths

Default admin URLs are one of the first things automated scanners check. WordPress sites running at /wp-admin, admin panels at /admin, and login pages at /login are trivially discoverable. Once found, they become the target for credential stuffing — automated attempts using username/password combinations leaked from other breaches.

Billions of valid credential pairs are freely available on the dark web from previous breaches. If any of your employees have reused a password from another service that was compromised, that combination will be tried against your admin login automatically.

Fix Change your admin URL to something non-default. Enable multi-factor authentication on all admin accounts. Add IP allowlisting to restrict admin access to known locations. Implement login attempt rate limiting to slow credential stuffing.

3

Missing or expired SSL/TLS certificates High

HTTP instead of HTTPS, weak cipher suites

An expired SSL certificate or a site still running on HTTP isn't just a trust signal problem — it's a security vulnerability. Unencrypted connections allow man-in-the-middle attacks where traffic between your visitors and your site can be intercepted and modified. Weak cipher suites in older TLS configurations can be exploited to decrypt traffic retroactively.

Search engines penalize non-HTTPS sites, modern browsers flag them with warnings, and attackers actively scan for them as indicators of generally poor security hygiene — if you haven't handled the basics, what else have you missed?

Fix Ensure your SSL certificate is valid and auto-renewing (Let's Encrypt offers free certificates). Force HTTPS via redirects. Disable TLS 1.0 and 1.1 — support TLS 1.2 minimum, 1.3 preferred. Use an SSL testing tool to check your cipher configuration.

4

Sensitive files and directories left exposed Critical

.env files, backup files, configuration directories

This one causes disproportionate damage relative to how easy it is to prevent. Developers frequently leave .env files, database backups, or configuration files accessible at predictable URLs. Scanners probe for hundreds of known patterns: /.env, /backup.sql, /wp-config.php.bak, and dozens more.

A single exposed .env file can hand an attacker your database credentials, API keys, and email service passwords in one request. This is one of the most common causes of complete site takeovers for small businesses.

Fix Audit your web root for any files that shouldn't be publicly accessible. Block access to sensitive file types and directories via your web server configuration. Never store credentials in files within your web root. Rotate any credentials that may have been exposed.

5

Missing security headers High

CSP, X-Frame-Options, HSTS, referrer policy

HTTP security headers are instructions your web server sends to browsers telling them how to behave when handling your site's content. They're free to implement and take minutes to configure — but the majority of small business websites are missing most or all of them. Automated scanners flag their absence as a signal of low security maturity, and certain attacks (clickjacking, cross-site scripting injection, protocol downgrade attacks) are significantly easier without them.

A Content Security Policy (CSP) header alone can prevent an entire class of cross-site scripting attacks. HSTS forces browsers to use HTTPS even if a user types the HTTP address. X-Frame-Options prevents your site from being embedded in an iframe for clickjacking attacks.

Fix Add security headers at your web server or CDN level. At minimum: Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy. Use securityheaders.com to scan your current configuration and see exactly what's missing.

The uncomfortable reality: if your website has any of these vulnerabilities, it's already been catalogued by automated scanners. The question isn't whether attackers know about it — it's whether you fix it before someone decides to act on what the bot found.

How to know where you stand

Reading a list like this is useful. Actually knowing which of these vulnerabilities exist on your own website is what matters. That requires scanning — the same kind of automated assessment that attackers use, run on your behalf so you see what they see.

A few free tools can help with individual checks: securityheaders.com for header analysis, SSL Labs for certificate and TLS configuration, and WPScan for WordPress-specific vulnerabilities. The limitation is that each tool covers only one slice of your attack surface, and none of them give you a prioritized picture of what to fix first based on current real-world exploitation activity.

Platforms like Veriti Spottr are built to give you the full picture — scanning your web presence and infrastructure continuously, mapping findings to severity and active exploit data, and surfacing the fixes that matter most in plain language. The goal isn't a list of 200 findings. It's a clear answer to the question: what do I fix first?

The bottom line

None of the five vulnerabilities on this list require advanced attacker skills to exploit. They're the low-hanging fruit — the open windows and unlocked doors that automated tools find in seconds. Fixing them doesn't guarantee you'll never face a security incident, but it removes you from the easy-target category that accounts for the overwhelming majority of small business breaches.

Start with what's on this list. Scan your own site. Know what's there before someone else does.

See exactly what hackers see when they scan your website. Veriti Spottr's beta is free — get your full vulnerability report in minutes.

Join the free beta →

VS

Veriti Spottr Team AI-powered cyber risk clarity for SMBs  ·  veritispottr.com