Research by ResaHost · 10 September 2026 · Updated 14 September 2026
Fake invoices and website break-ins: what an audit can reveal
Your customer receives an invoice in your company's name, but the money goes to a fraudster. Or an unpatched plugin lets an attacker change your website. A study of 209 retained ResaHost audit reports found settings and software-version signals that warrant investigation before damage occurs.
The audit examines publicly visible email settings, software information and browser protections. It does not log in to the website, prove that a vulnerability is exploitable or certify the site as secure. The incidents described below are possible consequences, not breaches established by this research.
The reports covered 165 domains. Each percentage below states its own eligible sample size. This is a selected set of audit reports, not a representative survey of businesses in Finland or Europe.
1. Someone could impersonate your business by email
A familiar sender address can make a fraudulent payment request look plausible. In this dataset, 51 of 85 email domains (60%) had no DMARC record found at the queried DNS name. Another 22 had p=none, a policy that does not ask the recipient to quarantine or reject a failing message.
Together, that is 73/85, or 85.9%, with no record found at that name or a policy requesting neither quarantine nor rejection. It does not prove that a forged message would reach the inbox: receiver filtering and an inherited parent-domain policy can affect the outcome.
What the audit gives you: a reason to check who can send using your domain, including invoicing, CRM and newsletter systems. Correctly configured sender authentication helps address direct domain spoofing. A similar-looking domain or a message sent from a compromised real account is a different problem. See the DMARC specification and our SPF, DKIM and DMARC guide.
2. A plugin needing attention can leave a route into the site
A website can look normal while running a plugin with a known flaw. If the flaw is exploitable, an attacker might alter content, introduce malicious code or obtain administrative access. Recovery can mean downtime, investigation and lost sales.
46 of 73 eligible sites (63%) had at least one detected plugin version older than its reference version. An older version is not proof of a vulnerability. Public version strings must be checked against the actual installed software and available fixes.
A historical example shows why the check matters: the Really Simple Security authentication-bypass flaw disclosed in 2024 could allow administrative access in affected versions and configurations. Our study did not establish that flaw on any sampled website. The example comes from Wordfence, which discovered the vulnerability.
What the audit gives you: detected versions for the maintainer to verify. The next work is to confirm the installation, take a usable backup, update where necessary and test afterwards. Read why WordPress updates matter.
3. A working site can run software past its original support period
PHP runs applications such as WordPress on the server. When the PHP project ends support for a branch, it no longer supplies that branch with security fixes. Normal page loading does not tell you whether the underlying software still receives patches.
9 of 25 identified PHP versions (36%) belonged to branches outside PHP-project support at the study date. These comprised seven PHP 5/7 findings and two PHP 8.0 findings. The findings included PHP 5.3, 5.4, 7.2, 7.4 and 8.0. PHP 8.0, the last of these branches to lose project support, reached end of life on 26 November 2023. See PHP's unsupported branches.
A supplier may still backport fixes to older software. The audit did not verify such extended support. Nor can we infer the PHP version, or even PHP use, on the other 103 sites. Red Hat explains backporting.
What the audit gives you: an identified version and a question for the provider. Ask which software package is installed, what fixes it receives and who is responsible for moving it to a supported configuration.
Find out what needs checking on your website
If you need help interpreting a result, contact ResaHost. We can review the findings and discuss the maintenance work involved.
The detailed evidence follows. Readers who want the practical first step can begin by assigning responsibility for email authentication, plugin updates and server software support.
Browser protections need context
The Content-Security-Policy header was absent from 102/127 responses (80.3%). A suitable CSP can restrict script and content sources and reduce the impact of some cross-site scripting attacks. Its absence alone does not establish an injection flaw; this metric also excludes policies set in an HTML meta element. See MDN's CSP guide.
X-Frame-Options was absent from 92/127 responses (72.4%). Embedding restrictions can help prevent clickjacking, but CSP frame-ancestors can provide a corresponding control. X-Content-Type-Options was absent from 88/127 (69.3%); its nosniff value helps prevent inappropriate MIME-type interpretation when content types are configured correctly. See X-Frame-Options and X-Content-Type-Options.
Referrer-Policy was absent from 113/127 responses (89%), and Permissions-Policy from 115/127 (90.6%). These are configuration observations, not equivalent numbers of data leaks. Browsers have defaults, and an absent Permissions-Policy does not bypass the user's permission for a camera. See Referrer-Policy and Permissions-Policy.
HTTPS and page resources are separate checks
HSTS was absent from 84/127 responses (66.1%). HSTS tells a browser to use HTTPS for a domain. Without an applicable policy, an initial HTTP connection may be exposed to network interference in some circumstances. A previously stored policy, a parent-domain setting or browser preload can still provide protection. See MDN on HSTS.
Six of 127 reports (4.7%) contained HTTP resource references in the retrieved HTML. A resource actually loaded without encryption can be read or altered in transit. Browsers upgrade some requests and block others, so an outcome could instead be a missing image or broken function. The audit did not verify what the browser loaded. See MDN on mixed content.
There was also a positive observation: 120/127 connections (94.5%) used TLS 1.3; the other seven used TLS 1.2. Encrypted transport does not answer whether plugins are maintained or email senders authenticated.
Public information and older protocols are not automatically vulnerabilities
59 of 80 eligible WordPress sites (73.8%) exposed author information or redirected to an author page. Public names can inform a targeted scam, but publishing an author's name may be intentional. This does not prove that a login identifier or password was disclosed.
93/125 domains (74.4%) had no AAAA record found, and 9/121 test connections (7.4%) did not use HTTP/2. Neither result alone establishes a security threat or a slow website.
All 20 findings and research methods
How the research was conducted
ResaHost examined reports retained by its own audit service, extracted on 10 September 2026 at 13:24:59 Europe/Helsinki. The 209 reports were stored between 12 August and 10 September 2026 and covered 165 distinct domains. The latest stored report for each domain was selected; 128 had structured diagnostics suitable for these calculations.
Domain names were normalised for letter case, a leading www and a trailing dot. Other subdomains were not merged. The unit is a domain, and the number of separate businesses cannot be established from these records.
The latest stored report is not necessarily the latest measurement. Older records may have been deleted under retention rules, so 209 is not the number of all audits ever performed. No target site was scanned again for this article.
Each denominator contains only reports eligible for that particular calculation. Missing diagnostics were not counted as missing protection. The six stored header statuses were compared with separately saved raw responses: each comparison included 127 records and found zero discrepancies. Successful HTML retrieval could not be verified for all negative resource findings.
We did not use the audit's plugin vulnerability classification, general outdated-WordPress flag or uncertain missing-cookie-management findings to calculate threat prevalence. PHP support was interpreted as of 10 September 2026. The additional derived calculations are 73/85 = 85.9% and 9/25 = 36.0%.
This is not a random sample. ResaHost sells website maintenance, so the research also has a commercial connection to its business. Counts and header totals do not measure the probability of an attack, establish real fraud losses or support claims about all European businesses.
All 20 findings
A domain may appear in several rows. Do not add the percentages together. The second number in each fraction is the eligible sample for that observation.
| Observation | Count | Share |
|---|---|---|
| 1. No DMARC record found at the queried DNS name. | 51/85 | 60.0% |
| 2. DMARC policy was p=none. | 22/85 | 25.9% |
| 3. DMARC policy requested quarantine or rejection. | 12/85 | 14.1% |
| 4. No SPF record found in the audit DNS query. | 5/85 | 5.9% |
| 5. DKIM record found with at least one tested selector. | 36/128 | 28.1% |
| 6. HSTS header absent from the recorded HTTP response. | 84/127 | 66.1% |
| 7. Content-Security-Policy header absent. | 102/127 | 80.3% |
| 8. X-Frame-Options header absent. | 92/127 | 72.4% |
| 9. X-Content-Type-Options header absent. | 88/127 | 69.3% |
| 10. Referrer-Policy header absent. | 113/127 | 89.0% |
| 11. Permissions-Policy header absent. | 115/127 | 90.6% |
| 12. WordPress identified by the technology detector. | 89/128 | 69.5% |
| 13. At least one detected plugin version was older than its WordPress.org reference version. | 46/73 | 63.0% |
| 14. Public author information or a redirect to an author page found. | 59/80 | 73.8% |
| 15. A numeric PHP version was identified. | 25/128 | 19.5% |
| 16. Identified PHP version belonged to the PHP 5 or 7 series. | 7/25 | 28.0% |
| 17. No IPv6 AAAA record found for the audited domain. | 93/125 | 74.4% |
| 18. HTTP/2 was not used in the test connection. | 9/121 | 7.4% |
| 19. Retrieved HTML contained references to unencrypted HTTP resources. | 6/127 | 4.7% |
| 20. The audit TLS connection used TLS 1.3. | 120/127 | 94.5% |
Calculation rules and limitations by observation
1. No DMARC record found at the queried DNS name.
An MX record was found and the DMARC query returned a result; module and query errors were excluded. This concerns the queried name, not the absence of every possible email defence.
2. DMARC policy was p=none.
The same MX population as observation 1. The p field did not request quarantine or rejection. Message delivery was not tested.
3. DMARC policy requested quarantine or rejection.
The same MX population: 11 quarantine policies and one reject policy. Receiver behaviour, any legacy pct setting and SPF/DKIM alignment were outside this calculation.
4. No SPF record found in the audit DNS query.
An MX record was present and the SPF check returned a result. This is not evidence of successful email impersonation.
5. DKIM record found with at least one tested selector.
A positive DNS finding from 128 reports with results. Failure to find a record does not demonstrate missing DKIM: the detector tried a limited list of selector names.
6. HSTS header absent from the recorded HTTP response.
127 reports had HTTP status 200–399 and stored headers. This describes the response, not every mechanism through which a browser might enforce HTTPS.
7. Content-Security-Policy header absent.
The same 127-response set. HTML CSP meta elements and other defensive measures are outside this metric.
8. X-Frame-Options header absent.
The same response set. CSP frame-ancestors can provide a corresponding embedding restriction.
9. X-Content-Type-Options header absent.
The same response set. This measures header presence, not whether content can be exploited.
10. Referrer-Policy header absent.
The same response set. Browser defaults and HTML meta policies are outside this calculation.
11. Permissions-Policy header absent.
The same response set. Absence does not show that the site obtained permission to use a visitor’s devices.
12. WordPress identified by the technology detector.
128 latest reports had a technology-detector structure. Other platforms and undetected WordPress installations are possible.
13. At least one detected plugin version was older than its WordPress.org reference version.
73 sites had a detected version and a WordPress.org reference for at least one plugin. Both versions needed two or three numeric components and a successful comparison. One older version was sufficient for a finding. Installed versions inferred from public files were not verified through an administrative login.
14. Public author information or a redirect to an author page found.
80 WordPress sites had a positive result or neither checked route was left untested. This does not mean a password leak or disclosure of a login identifier.
15. A numeric PHP version was identified.
25 out of 128 diagnostic reports exposed an identifiable numeric version. Unknown and non-numeric values were not findings. The other 103 sites remain unresolved.
16. Identified PHP version belonged to the PHP 5 or 7 series.
Only the 25 identified versions are in the denominator: two PHP 5 and five PHP 7 findings. This is not a count of all unsupported PHP branches.
17. No IPv6 AAAA record found for the audited domain.
125 explicit DNS results. Timeouts and unknown results were excluded. This is not an assessment of the entire organisation’s IPv6 capability.
18. HTTP/2 was not used in the test connection.
121 explicit protocol results. This says nothing about every connection to the site or its perceived speed.
19. Retrieved HTML contained references to unencrypted HTTP resources.
127 reports had a resource-check result and HTTP status 200–399. An HTML reference does not show that the browser loaded the resource or that every resource was examined. Successful HTML retrieval could not be verified for all negative resource findings.
20. The audit TLS connection used TLS 1.3.
127 reports had an identified TLS version; the remaining seven used TLS 1.2. TLS 1.2 is not classified as unsafe by this observation.
Put the findings into a maintenance plan
Our interpretation is to begin with legitimate email senders and the update or support status of detected software. Name the people responsible for each task. Then review browser protections against the website's real functionality, including embedded services and the subdomains affected by HSTS.
Back up before changes and verify that the website and email still work afterwards. The useful result is an agreed fix with an owner, rather than a higher count of security headers. See managed WordPress maintenance and website security.