The Most Common Security Vulnerabilities in UK Small Business Websites (2026)

What the data shows

Most security advice is written for large organisations with dedicated security teams. This post is different. It is based on real findings from vulnerability scans run on UK small business domains — the actual issues appearing most frequently on the kinds of websites operated by businesses with 1–50 employees.

The picture is consistent. The same handful of issues appear again and again, across different industries, different hosting providers, and different technology stacks. They are not sophisticated vulnerabilities. They are the unglamorous basics that accumulate when nobody is looking at infrastructure from the outside.

Here is what we find most often.

1. Missing or weak DMARC record

Frequency: very common

The single most frequent finding across UK small business domains. DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving mail servers what to do when an email claims to come from your domain but fails authentication checks.

Without a DMARC record at p=quarantine or p=reject, anyone can send an email that appears to come from your domain. Your customers can receive convincing phishing emails that look exactly like they are from you.

Many businesses have a DMARC record at p=none — monitor-only mode — which generates reports but does not block spoofing. A DMARC record only provides real protection at p=quarantine (sends spoofed emails to spam) or p=reject (blocks them entirely).

Fix time: 30–60 minutes once SPF and DKIM are confirmed working.

2. Missing HTTP security headers

Frequency: very common

HTTP security headers are instructions your web server sends to browsers that control how they behave when loading your pages. They protect your visitors from several categories of attack. The most commonly missing:

• X-Frame-Options — prevents your site from being embedded in an iframe on another site, blocking clickjacking attacks
• X-Content-Type-Options — prevents browsers from interpreting files as a different MIME type than declared
• Strict-Transport-Security — tells browsers to always use HTTPS for your domain, even if someone clicks an HTTP link
• Referrer-Policy — controls what referrer information is sent when visitors click links away from your site

None of these require significant technical work. They are typically added in a single block in your web server configuration or hosting control panel.

Fix time: Under an hour for a technical person with server access.

3. Outdated software with known vulnerabilities

Frequency: common

WordPress powers a significant proportion of UK small business websites. WordPress itself updates frequently and automatically for minor releases — but plugins and themes do not always update automatically, and many sites are running plugins that have not been touched in months or years.

Known CVEs (Common Vulnerabilities and Exposures) against popular WordPress plugins are published publicly. Automated scanners probe for them constantly. A plugin vulnerability disclosed six months ago that you have not patched is an open door.

Beyond WordPress: PHP versions below 8.1 are end-of-life and no longer receive security patches. Old versions of server software (Apache, nginx, OpenSSL) accumulate known vulnerabilities over time.

Fix time: Plugin updates take minutes. PHP version upgrades can require testing but are typically straightforward on modern hosting.

4. Unnecessary open ports

Frequency: common

Ports that were opened for a specific purpose and never closed when that purpose ended. The most frequent examples:

• Port 8080 — often an admin panel or development server left running
• Port 3306 — MySQL database accessible directly from the internet (should always be firewalled)
• Port 21 — FTP server from a previous hosting setup
• Port 22 — SSH open to the entire internet rather than restricted to specific IP addresses

Each of these represents a service that is either unnecessary or misconfigured. An open database port with no firewall restriction is a critical finding — it means an attacker can attempt to connect directly to your database from anywhere in the world.

Fix time: Minutes to add a firewall rule; longer if the underlying service needs to be assessed and potentially decommissioned.

5. SSL certificate expiring within 30 days

Frequency: common

Certificates that are still technically valid but approaching expiry. By the time the certificate actually expires, browser warnings have already driven visitors away and search rankings have been affected. The 30-day threshold is the actionable warning point.

Most hosting providers automate Let's Encrypt certificate renewal — but automation can fail silently. A server configuration change, a DNS record update, or a hosting migration can break the automated renewal process without triggering any notification.

Fix time: Certificate renewal itself takes minutes once the issue is identified. Fixing broken automation may require investigation.

6. Exposed configuration files or sensitive paths

Frequency: occasional

Files that should not be web-accessible but are. Common examples: .env files containing database credentials and API keys, phpinfo() pages exposing server configuration, backup files (backup.zip, db_backup.sql) sitting in the web root, and .git directories exposing source code.

These are typically the result of files being in the wrong place when a site is deployed, or test files left in production. Automated scanners check for these paths constantly.

Fix time: Immediate — move or delete the files, and configure the web server to deny access to sensitive paths.

7. Subdomain pointing to unclaimed service

Frequency: occasional

DNS records pointing to external services — Heroku, GitHub Pages, Netlify, AWS S3 — where the underlying deployment has been deleted but the DNS record was never removed. This creates subdomain takeover vulnerability.

Common in businesses that have had developers work on projects over the years and have not audited DNS records since. A staging. or dev. subdomain pointing to a long-deleted Heroku app is the typical pattern.

Fix time: Removing the DNS record takes minutes once identified.

The pattern

Looking across these findings, the common thread is not sophistication — it is drift. Infrastructure that was set up correctly at one point and then not reviewed. Records and services that accumulated over time without anyone checking whether they were still needed or still configured correctly.

A vulnerability scan is useful not because it finds exotic zero-day vulnerabilities — it almost never does — but because it catches exactly this kind of drift before it is exploited.

Scan your domain with Olimpio to see which of these findings are present on your infrastructure. Results in around 15–20 minutes, with plain-English explanations and remediation steps for everything found.