Patching Isn't Enough: 12-Point Website Security Checklist (Fall 2026)

CVE-2026-75650, nicknamed StyleSmuggler by e-commerce security firm Sansec, is a maximum-severity (CVSS 10.0) flaw that lets an attacker with no login run code on Adobe Commerce and Magento Open Source stores. Sansec confirmed exploitation from September 4, 2026. Adobe released a hotfix in security bulletin APSB26-146 on September 7, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 8.

The attack plants PHP code in Magento's template system and gets it executed. In one route, the code runs while Magento renders a failed-payment email, so nobody has to open anything. BleepingComputer lists "Payment Transaction Failed Reminder" emails as one sign of compromise.

Why patching isn't enough:
• Backdoors survive the patch. In Sansec's words, "Patching closes the hole but does not clean a store that was already hit." One attacker deployed a Linux backdoor; a second, unrelated actor dropped a small PHP web shell.
• Keys must be rotated at the source. Per Sansec, Adobe recommends rotating the store's encryption key and every credential it protected. Rotating the key alone "does not invalidate anything an attacker already read," so payment gateway, API and integration credentials must also be changed at the provider.
• The hotfix had a sequel. Sansec says a second CVSS 10.0 flaw, BlockStrap (CVE-2026-103849), gets past the September hotfix; Adobe fixed it in APSB26-153 on October 13. The October patch does not include the September hotfix (VULN-39341), so stores need both. Sansec's write-up reported no BlockStrap exploitation observed yet.

What to do:
1. Install hotfix VULN-39341 and the October 2026 security update (or Adobe's isolated BlockStrap patch).
2. Check for implants. Sansec lists PHP files under pub/media and unexpected cron entries among its indicators.
3. Rotate the encryption key, admin passwords, integration tokens, payment gateway credentials, database credentials and SSH keys.
4. If you can't patch today, ask your host about a web application firewall rule as a stopgap; Sansec says Cloudflare and Imperva shipped rules on September 10.

UpdraftPlus is a WordPress backup plugin with over four million active installations, per The Hacker News. Its maker, TeamUpdraft, says it found unauthorized access to teamupdraft.com over the weekend of October 17–18, 2026, and believes its customer database was read. That database held hashed passwords, two-factor settings and connection keys for UpdraftCentral, the cloud dashboard that manages many WordPress sites from one place.

Those keys were the real prize. Security firm Patchstack reported attacks starting at 15:32 UTC on October 18 that used valid UpdraftCentral keys to push at least 99 differently named backdoor plugins, disguised as maintenance tools, onto connected sites (BleepingComputer). The backdoors could run arbitrary code and create administrator accounts. The attackers did not need a software bug: security firm Nethemba found the commands were signed with valid dashboard keys.

What TeamUpdraft says to do:
• Update to UpdraftPlus 1.26.13 (free) or 2.26.13 (Premium), published on October 19. They disconnect every UpdraftCentral connection made before 13:07 BST on October 18, so old keys stop working. WordPress.org pushed the update automatically.
• Look outside the dashboard. Some malicious plugins hide from the Plugins screen, so inspect wp-content/plugins/ and wp-content/mu-plugins/ over SFTP, SSH or your host's file manager.
• Delete carefully. Some plugins "contain mechanisms designed to remove evidence when deleted through WordPress." Deactivate them and delete their folders directly.
• Hunt for hidden accounts. Check the database, not just the Users screen, for admin or editor accounts you don't recognize.
• Reset credentials. Change admin and editor passwords, reset WordPress security keys and salts to end existing sessions, and reset your teamupdraft.com password and 2FA.
• Restore if in doubt from a backup taken before October 17, then still revoke keys and reset credentials.

Self-hosted UpdraftCentral was not affected. But TeamUpdraft's October 29 update reported a small number of compromised sites with no visible signs, so check every site that was ever connected to UpdraftCentral Cloud, free or Premium.

On October 6, 2026, Google disclosed that attackers had compromised the operators of three country-code top-level domains (ccTLDs): .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). They changed authoritative DNS records and, with DNS under their control, obtained unauthorized HTTPS certificates for several Google domains and for domains belonging to other organizations. Google's own systems were not breached.

The Hacker News found at least 12 certificates issued between September 22 and 27 for Google and YouTube names under the three ccTLDs, 11 from Let's Encrypt and one from ZeroSSL. Google said it had no reason to believe the certificate authorities did anything wrong: they checked DNS, and DNS said yes.

Why it matters to a small business: a padlock proves that whoever requested the certificate controlled your domain's DNS at that moment, not that it was you. If your registrar account, DNS host or registry is compromised, an attacker can get a valid certificate and serve a convincing copy of your site.

What to do:
• Monitor Certificate Transparency (CT) logs, the public record of every certificate issued, for all your domains, including parked and regional ones, as Google recommends. Free services can email you when a new certificate appears.
• Publish restrictive CAA records, the DNS entries that tell certificate authorities who may issue certificates for your domain. Google notes CAA cannot stop issuance during an active hijack, but it limits misuse once DNS is restored.
• Protect your registrar account with multi-factor authentication and change notifications, and ask your registrar whether it offers a registry lock.

This pattern involved no flaw in the victims' own websites.

• Brevo (marketing email): an attacker abused a flaw in how Brevo handled SAML single sign-on to reach 138 customer accounts, Brevo says. Trezor's subscribers received a phishing email from Trezor's real newsletter address that passed the usual email authentication checks; Trezor says about 347,000 people received it.
• Ribon (BigCommerce app): attackers used a compromised BigCommerce application key held by the Ribon storefront app to pull customer names, emails, phone numbers and addresses from merchant stores between September 13 and 17 (SecurityWeek).

Both follow the same logic as UpdraftCentral: a trusted third party held a key, and the key was enough. You can't patch a vendor, but you can limit what each one holds.

What to do:
• List every app, plugin and SaaS tool with an API key or login to your store, CMS or customer data, and remove anything unused.
• Turn on MFA or single sign-on for every marketing, email and e-commerce account, and remove former staff and agencies.
• Rotate API keys whenever a vendor announces an incident, even if it says you weren't affected.
• Tell customers in plain language what you will never ask for by email, so a perfect-looking phishing message still looks wrong.

Work through these 12 items in order. The first four take minutes; the rest deserve a calendar block this month.

1. Turn on automatic updates for your CMS core, plugins and themes where your platform allows it, and confirm they actually ran.
2. Subscribe to security advisories for every platform, plugin and hosting panel you rely on, so a critical patch reaches a person, not just an inbox.
3. Enforce MFA on every admin login: CMS, hosting, registrar, DNS, email marketing and payment accounts.
4. Scan your public site for HTTPS problems, missing security headers, and exposed admin pages or files like .env.
5. Patch actively exploited flaws within days, not at the next maintenance window. StyleSmuggler was exploited three days before a fix existed.
6. After any emergency patch, check for compromise: unknown admin users, unfamiliar plugins or files, and new scheduled tasks.
7. Rotate secrets after any incident, including encryption keys, API keys, integration tokens and payment credentials, and change them at the provider, not only inside your site.
8. Revoke remote-management connections you no longer use (backup dashboards, agency tools) and re-issue the ones you keep.
9. Lock down your domain with registrar MFA, change notifications and, if offered, a registry lock.
10. Monitor Certificate Transparency for certificates issued for your domains, and publish CAA records naming the certificate authority you use.
11. Audit third-party apps and vendor access every quarter: remove unused apps, cut excess permissions and rotate their keys.
12. Keep backups you can trust, stored separately from the site, going back far enough to predate a compromise, and test a restore.

Keep a one-page record of who owns each item and when it was last done. When a vendor announces an incident late at night, that page is your incident plan.

An external scan sees your website the way an attacker's first probe does. Here is how ours maps to the incidents above.

A clean scan is a good baseline, not a clean bill of health. The checklist covers what no outside scan can see.