Website and Email Security Mistakes We Keep Seeing
October 2026
- 7 minute read
October’s security news offers a useful reminder: a website or mailbox depends on more than the application people see. Its mailbox rules, email gateway, certificate chain, release process and domain account each have a separate owner and a separate failure mode. Here are five mistakes worth checking this month.
Mistake 1: Resetting a Mailbox Password but Leaving Forwarding Rules Behind
Where this shows up
Business mailboxes being recovered after suspected unauthorised access.
How this happens
A password reset becomes the final recovery step, while changes inside the mailbox remain unchecked. An attacker may have created rules that forward selected messages to an external address or move replies out of sight. Microsoft’s recovery guidance includes reviewing both mailbox forwarding settings and inbox rules, including hidden rules.
Why this causes damage
A forwarding rule can continue sending incoming messages to an attacker after a password reset. This can expose correspondence and support further fraud. MITRE documents this technique as email collection through forwarding rules.
How to avoid this mistake
Make a forwarding and inbox-rule review part of mailbox recovery. Have the administrator inspect hidden rules as well as ordinary forwarding settings, preserve relevant evidence and remove unauthorised changes. Complete the provider’s recovery procedure, including revoking active sessions and reviewing authentication methods. Treat the password reset as one step in that process.
Mistake 2: Treating the Email Security Gateway as a Safe Boundary
Where this shows up
Organisations that route inbound mail through a dedicated filtering appliance before it reaches users’ mailboxes.
How this happens
The gateway is treated as the control that inspects risky attachments, so attention centres on the mail it blocks. Cisco’s 14 October advisory described a flaw in Secure Email Gateway’s attachment handling when its file reputation service is enabled. A crafted email passing through an affected device could let an unauthenticated attacker write files and execute commands with root privileges. Cisco issued software fixes and reported no workaround that resolves the flaw; CERT-EU reported active exploitation.
Why this causes damage
The filtering device itself becomes the attack surface. Its position in the mail path can give a compromise serious operational and security consequences even before a recipient opens an attachment.
How to avoid this mistake
Maintain an inventory of the appliances and services in the mail path. Subscribe to their security advisories, establish who patches each one, and review vendor instructions when exploitation is reported. Keep administrative access narrow and preserve logs useful for investigation. Cloud mail users should check the products actually in their path rather than assuming this Cisco-specific issue affects every email service.
Mistake 3: Assuming a Valid Certificate Ends the Trust Check
Where this shows up
HTTPS websites, customer portals and systems whose operators equate an encrypted connection with an entirely trustworthy certificate chain.
How this happens
Certificates depend on trusted issuers and their private keys. Cloudflare reported on 21 October that private keys associated with eight eMudhra intermediate certificates had been compromised. Its analysis said the keys could be used to forge certificates and impersonate servers, with the practical risk depending on trust-store and revocation behaviour. This was an issuer-level incident, rather than evidence that every site using HTTPS had been breached.
Why this causes damage
A certificate can support an encrypted connection while the wider trust chain is being remediated. Website owners may miss urgent notices from a certificate provider, while visitors on outdated software may continue to rely on stale trust information.
How to avoid this mistake
Know who issues and manages your certificates. Monitor notices from that provider, keep browsers and operating systems updated, and act on replacement or revocation instructions affecting your own certificates. Check the precise impact before making emergency changes. For critical systems, document how to replace certificates promptly.
Mistake 4: Putting a Preview Release on a Live Website
Where this shows up
Production WordPress sites where a new version’s features look attractive, or where a testing plugin or update channel has been left enabled.
How this happens
WordPress 7.2 Beta 1 arrived on 20 October. Its announcement explicitly reserves the beta for testing and development and advises against installation on production or mission-critical websites. A beta is useful for checking themes and plugins ahead of release; it is still in the stage where bugs are being found and fixed.
Why this causes damage
An unfinished release can disrupt checkout, forms, sign-in or editorial work. A hurried rollback may also lose changes made after the preview was installed. The risk here is release discipline, rather than a claim that this particular beta contains a known exploitable flaw.
How to avoid this mistake
Use a separate test site with access controls and safe test data. Check the site’s update channel before approving changes, test key workflows, and schedule the stable release for production after compatibility checks. Keep a restorable backup and a documented rollback plan.
Mistake 5: Securing the Website but Neglecting the Domain Account
Where this shows up
Registrar accounts that control the domain used by the website, business email and DNS records.
How this happens
Teams focus on website administrator accounts and mailbox sign-ins while one registrar login remains shared, difficult to recover or protected by a weak password. That login sits upstream of the services: changes to nameservers or DNS records can redirect visitors and disrupt or reroute email. ICANN advises registrants to protect and recover their accounts, enable multifactor authentication where supported and consider registrar locks.
Why this causes damage
Control over a domain can affect several services at once. A transfer lock helps protect against unauthorised transfers, but its protection depends on the registrar’s implementation and it does not replace account security or monitoring of DNS changes.
How to avoid this mistake
Name an accountable domain owner, use a unique password and multifactor authentication, limit account access, and secure recovery details. Enable suitable transfer protection, review DNS changes and maintain an independent route to contact the registrar if business email becomes unavailable.
Conclusion
October’s five checks cover separate responsibilities: review mailbox forwarding after a compromise, patch security infrastructure in the mail path, respond to certificate-chain notices, keep preview software in a test environment and protect the account that controls the domain. Together, they help teams see the services beneath a working website and a functioning inbox.
Five October reminders show where website and email protection can slip between owners.
Mistake 1: Leaving Email Forwarding Behind After a Password Reset
Where this shows up
After someone gains unauthorised access to a business mailbox.
How this happens
The password is changed, but a rule created by the attacker keeps copying incoming messages elsewhere.
Why this causes damage
New emails can keep reaching the attacker, even after the password changes.
How to avoid this mistake
Ask your administrator to check forwarding settings and inbox rules, including hidden rules. Remove unauthorised changes and complete the email provider’s account recovery steps.
Mistake 2: Overlooking the Email Gateway
Where this shows up
Where a security device scans email before delivery.
How this happens
The device is trusted to stop malicious messages, while its own software needs security fixes. Cisco disclosed an actively exploited gateway flaw in October.
Why this causes damage
A crafted message can target the filtering device itself.
How to avoid this mistake
List the systems in your mail path. Assign someone to watch vendor alerts and apply fixes. Check whether your product is affected.
Mistake 3: Ignoring Certificate Notices
Where this shows up
On HTTPS websites and portals.
How this happens
Certificates depend on trusted issuers. In October, an issuer’s intermediate private keys were reported compromised.
Why this causes damage
Forged certificates can create impersonation risks. The response depends on the exact certificate chain and device updates.
How to avoid this mistake
Know your certificate provider. Follow its notices, update browsers and operating systems, and replace affected certificates when instructed.
Mistake 4: Using Preview Software on a Live Site
Where this shows up
On production WordPress websites.
How this happens
A beta release is mistaken for an ordinary update. WordPress says its October 7.2 beta is for testing.
Why this causes damage
Unfinished changes may break forms, checkout or sign-in.
How to avoid this mistake
Test betas on a separate site. Check the update channel and key workflows before a stable release reaches production.
Mistake 5: Forgetting the Domain Account
Where this shows up
At the registrar that controls the website and email domain.
How this happens
Website and mailbox passwords get attention. The registrar login and its recovery details receive less.
Why this causes damage
Someone who controls the domain can disrupt or redirect several services.
How to avoid this mistake
Use a unique password and multifactor authentication. Limit access, review DNS changes and keep a recovery contact outside the affected business email.
Conclusion
Check the layers underneath: mailbox forwarding, the mail gateway, certificates, software release channels and the domain account.
Need expert help protecting your environment?
Get Started