Website and Email Security Mistakes We Keep Seeing
August 2026
- 5 minute read
Security problems are not always caused by the absence of security controls. Quite often, the controls are there, but something around them has been trusted too easily.
August gave us several examples of this. Websites remained exposed while security updates were available. Unnecessary plugins increased the number of components that needed to be trusted and maintained. A legitimate WordPress vendor became part of the attack path after its own infrastructure was compromised. Elsewhere, phishing emails passed through working email authentication controls because a trusted vendor had been placed on a safe-sender list.
Even multi-factor authentication was not enough when users were persuaded to participate in a legitimate authentication process on behalf of an attacker.
The common problem is not that trust is inherently bad. Websites, email systems and users all need to trust something in order to operate. The mistake is allowing that trust to become unconditional.
Mistake 1: Delaying Critical Website Security Updates
Where this shows up.
A WordPress website appears to be working normally, so available updates are left for later. Sometimes administrators are concerned that an update could break the site. In other cases, nobody is actively checking whether a security update has been released.
August provided a useful reminder of the risk. WordPress released version 7.0.3 on 6 August with multiple security fixes and recommended immediate updating. Only six days later, WordPress 7.0.4 addressed another security issue involving remote code execution under specific conditions.
How this happens.
Website maintenance is often treated as a periodic task rather than an active security responsibility.
An organisation may update the website once a month, wait until somebody notices the WordPress notification, or rely entirely on automatic updates without checking whether those updates actually succeeded.
The problem becomes worse when nobody distinguishes between an ordinary feature update and a security update.
Why this causes damage.
Once a vulnerability becomes publicly known, attackers do not need to discover it independently. They can begin identifying websites that still run affected versions.
Plugin vulnerabilities can be particularly serious. An August vulnerability in Elementor Pro, for example, could under specific configurations allow an attacker to upload executable files and run code on the server. Updating the plugin fixed the vulnerability, but importantly, updating alone would not remove malicious files if exploitation had already occurred.
A delayed update therefore creates two problems: an unnecessary period of exposure and uncertainty over whether the website was compromised during that period.
How to avoid this mistake.
Security updates should have a different priority from normal functionality updates.
Monitor WordPress core, plugins and themes for security advisories, apply important patches promptly, maintain tested backups before major changes, and verify that updates complete successfully.
If a serious vulnerability affected a component before it was patched, do not assume that installing the update automatically reverses anything an attacker may already have done.
Mistake 2: Keeping Plugins That Are No Longer Necessary
Where this shows up.
A plugin was installed for a feature that was needed months or years ago. The feature is no longer used, but the plugin remains installed because somebody might need it again.
Sometimes it is simply deactivated and forgotten.
How this happens.
WordPress makes adding functionality extremely easy. Over time, this can produce websites containing page builders, forms, translation tools, analytics plugins, SEO plugins, migration tools and other extensions added by different administrators at different stages of the site’s life.
Removing them receives far less attention than installing them.
The result is gradual accumulation.
Why this causes damage.
Every additional plugin introduces another piece of software that must be maintained, monitored and trusted.
August demonstrated this across widely used WordPress software. A vulnerability disclosed in TranslatePress affected versions up to 3.3.1 and, under the relevant conditions, could allow an unauthenticated attacker to obtain an administrator password-reset link and take over the account. The developer released a patched version shortly after disclosure.
The important lesson is not that TranslatePress, Elementor or WordPress plugins generally are unsafe. It is that software which provides no current value still contributes to the website’s attack surface.
A plugin that is not required can still become vulnerable.
How to avoid this mistake.
Review installed plugins periodically and ask a basic question about each one: does the website still need this?
Remove plugins and themes that are no longer required rather than simply deactivating them indefinitely.
For the software that remains, confirm that it is actively maintained, still receives security updates and comes from a source you are prepared to trust.
A smaller plugin inventory is usually easier to maintain and easier to understand.
Mistake 3: Assuming a Trusted Plugin Vendor Cannot Become the Attack Path
Where this shows up.
A website administrator carefully avoids questionable plugins and downloads software only from established developers.
That is good practice, but it can create another assumption: if the software vendor is legitimate, anything coming from its infrastructure must also be legitimate.
How this happens.
Modern plugins frequently communicate with infrastructure outside the WordPress website itself.
They may retrieve updates, licence information, promotional content, configuration data or other resources from systems operated by the vendor.
This creates a supply-chain relationship. The website does not only trust the plugin code already installed. It may continue trusting infrastructure controlled by the plugin developer.
Why this causes damage.
In August, attackers compromised infrastructure belonging to WordPress plugin developer BdThemes.
Rather than modifying a plugin package and waiting for customers to install an update, the attacker altered data being delivered from the vendor’s infrastructure. According to the investigation, malicious content could execute when an administrator accessed WordPress, creating rogue administrator accounts and attempting to hide them from the normal user list.
The website owner could therefore have installed legitimate software from the legitimate vendor and still become exposed because the trusted supplier itself became compromised.
How to avoid this mistake.
Using reputable vendors remains important. The answer is not to distrust every software supplier.
The answer is to avoid making vendor trust your only defence.
Keep independent website backups, monitor unexpected administrator accounts, watch for unusual file and database changes, use appropriate web application firewall controls, and minimise unnecessary external dependencies.
When a vendor announces a security incident, check whether your own website may already have been affected. A supplier fixing its infrastructure does not necessarily undo actions that occurred on your website beforehand.
Mistake 4: Whitelisting an Email Sender So Broadly That Authentication Stops Mattering
Where this shows up.
An organisation regularly receives legitimate email from an important supplier.
Some of those messages are occasionally blocked or classified as spam, so the supplier’s domain is added to a safe-sender or allowlist.
The problem appears solved.
How this happens.
Email exceptions are often created to solve an immediate operational inconvenience.
Instead of identifying why legitimate messages are failing authentication or filtering, somebody creates a broad rule effectively saying that messages claiming to come from the supplier should be trusted.
That distinction matters.
In August, researchers analysing the Greatness phishing platform investigated emails impersonating RingCentral. The victim organisation genuinely used RingCentral and had created a safe-sender exception for it.
Why this causes damage.
The phishing messages failed SPF and DMARC and did not contain a valid DKIM signature. Those controls therefore identified exactly the sort of inconsistency they were designed to detect.
The messages were nevertheless delivered because the RingCentral safe-sender configuration overrode those signals.
The attackers did not defeat SPF, DKIM or DMARC.
They found a configuration that had already been instructed not to care.
This is an important difference because buying another email-security product would not necessarily solve a problem created by an overly broad trust exception.
How to avoid this mistake.
Avoid broad domain-level email allowlisting whenever possible.
If an exception is genuinely required, make it as narrow as technically practical and periodically review whether it is still needed.
More importantly, do not allow a sender’s claimed identity alone to override contradictory authentication evidence.
SPF, DKIM and DMARC cannot protect an organisation if another rule effectively tells the email system to ignore their result.
Mistake 5: Assuming MFA Means an Authentication Request Must Be Safe
Where this shows up.
A user receives an email, message or phone call asking them to authenticate.
They are directed to Microsoft, Google or another genuine identity provider, enter their credentials, complete MFA and assume that the authentication must therefore be legitimate.
After all, they were not entering their password into an obviously fake website.
How this happens.
Phishing has moved beyond simply copying login pages.
The Greatness phishing platform documented in August supports adversary-in-the-middle attacks and device-code phishing. Device-code phishing can send the victim to a legitimate Microsoft authentication page and ask them to enter a code controlled by the attacker.
The website can genuinely belong to Microsoft.
The authentication itself can genuinely succeed.
The problem is that the user is authorising the attacker’s session.
Why this causes damage.
MFA proves that the person completing the authentication possesses the required authentication factors.
It does not automatically prove that the session being authorised was initiated for the reason the user believes.
In the campaigns examined by researchers, attackers could obtain authentication tokens and subsequently access Microsoft 365 resources such as Outlook, Teams, SharePoint and OneDrive.
This means that teaching users merely to check whether the login page looks legitimate is no longer sufficient.
Sometimes the login page really is legitimate.
How to avoid this mistake.
Treat unexpected authentication requests as suspicious even when the authentication page itself is genuine.
Users should understand why they are being asked to authenticate, what application or device they are authorising, and whether they initiated the process themselves.
Where technically possible, organisations should move towards phishing-resistant authentication methods and restrict authentication flows that are not required for normal business operations.
MFA remains essential. It simply should not be mistaken for proof that every authentication request is legitimate.
Conclusion
The five mistakes from August look different on the surface.
One concerns updates. Another concerns unnecessary plugins. A third concerns software suppliers. The fourth concerns email filtering, and the fifth concerns authentication.
Underneath them, however, the same weakness appears repeatedly: trust becomes dangerous when it stops being questioned.
A website trusts software that no longer needs to be there. An administrator trusts a supplier’s infrastructure because the supplier itself is legitimate. An email system trusts anything claiming to come from an approved vendor. A user trusts an authentication request because Microsoft is genuinely asking them to authenticate.
None of these decisions are irrational on their own.
The mistake is allowing one signal of trust to cancel every other warning.
Good security therefore requires more than adding controls. It also requires periodically examining the exceptions, assumptions and trusted relationships surrounding those controls.
Because sometimes the attacker does not need to break through your security.
They only need to find something you have already told it not to question.
This month, many of the security problems we saw had one thing in common: too much trust.
Security controls were often present and working. The problem was that another setting, an old piece of software, or a trusted relationship weakened those controls.
Here are five mistakes worth checking.
Mistake 1: Waiting Too Long to Install Security Updates
WordPress and its plugins regularly receive security fixes.
In August, WordPress itself released multiple security updates, while serious vulnerabilities were also identified in popular plugins.
A website can appear to be working perfectly while still running vulnerable software.
Do not treat security updates like ordinary feature updates.
Keep reliable backups, monitor available security fixes and install important patches promptly.
If a serious vulnerability existed before you updated, remember that installing the patch does not automatically remove anything an attacker may already have done.
Mistake 2: Keeping Plugins You Do Not Need
Every plugin adds more software to your website.
That means another component that needs updates, maintenance and trust.
Even a plugin that you rarely use can later contain a vulnerability. A deactivated plugin can also remain installed and eventually be forgotten.
If a plugin no longer serves a purpose, remove it rather than leaving it there indefinitely.
Review your WordPress plugins regularly and keep only what the website actually needs.
Fewer unnecessary components means a smaller attack surface.
Mistake 3: Trusting a Plugin Vendor Too Much
Downloading software from reputable developers is still important.
But a trusted vendor can also be compromised.
In August, attackers compromised infrastructure belonging to WordPress plugin developer BdThemes. Websites using legitimate plugins from the legitimate company could still become exposed because the supplier itself became part of the attack path.
This is known as a supply-chain risk.
You do not need to distrust every software company. But you should avoid making vendor reputation your only defence.
Keep independent backups, monitor unexpected administrator accounts and watch for unusual changes to your website.
If a vendor reports a compromise, check whether your own website was already affected.
Mistake 4: Putting Entire Email Domains on a Safe-Sender List
An email can look trusted and still be fake.
Safe-sender rules are often created because legitimate emails are being blocked or sent to spam.
The problem begins when the rule becomes too broad.
In one August phishing campaign, fake RingCentral emails failed SPF and DMARC checks and had no valid DKIM signature.
Those security controls detected that something was wrong.
The messages were still delivered because RingCentral had been placed on a safe-sender list.
The attackers did not defeat the email authentication controls.
The exception overruled them.
Avoid broad domain-level whitelists whenever possible.
If an exception is genuinely necessary, keep it as narrow as possible and review it regularly.
A familiar company name should never automatically make an email trustworthy.
Mistake 5: Believing MFA Makes Every Login Safe
MFA remains one of the most important account-security controls.
But MFA does not mean every authentication request is legitimate.
Modern phishing can send a victim to the real Microsoft login page.
The website is genuine. The authentication can genuinely succeed.
The problem is that the user may be approving the attacker’s session.
This means checking whether a login page “looks real” is no longer enough.
If you receive an unexpected authentication request, ask:
Did I start this login?
Do I know what application or device I am authorising?
Why am I being asked to authenticate now?
Where possible, organisations should use phishing-resistant authentication and restrict authentication methods they do not actually need.
MFA is essential.
It simply does not prove that every request for MFA is safe.
Conclusion
The five mistakes from August look different, but the same problem appears repeatedly:
trust without enough verification.
A website trusts software it no longer needs.
An administrator trusts a supplier because the supplier is legitimate.
An email system trusts a claimed sender because somebody placed the domain on an allowlist.
A user trusts an authentication request because the Microsoft page is real.
Security controls still matter.
But we also need to examine the exceptions, assumptions and trusted relationships around those controls.
Sometimes attackers do not need to break through your security.
They only need to find something you have already told it not to question.
Need expert help protecting your environment?
Get Started