If you run a WooCommerce store, you probably feel safe once WordPress says it’s up to date. The dashboard is green, the core update ran overnight, and you move on.
That feeling covers less than you think. WordPress core mostly updates itself. Your plugins usually don’t.
October showed the gap clearly. On October 6, WordPress 7.1.3 shipped with 7 security fixes, and sites with auto-updates on got it without anyone clicking a button. A week later, The Hacker News reported attacks on a flaw in WPC Product Bundles for WooCommerce. Stores use that plugin to sell product kits. That flaw had a fix available since September.
This post explains what each story means for a typical store and why plugin flaws are the bigger risk. Then it gives you a 15-minute monthly routine to run before the holiday rush.
WordPress core security releases mostly patch themselves
WordPress 7.1.3 was a security release. It fixed seven issues. One was a stored cross-site scripting (XSS) bug on the Comments admin page. Another let people see comments on private posts without logging in. XSS means an attacker can sneak code into a page so it runs in someone else’s browser.
The release post says sites with automatic background updates turned on will update on their own. That’s the default for minor releases like 7.1.3. WordPress.org‘s documentation says every site has automatic updates enabled for minor core releases and translation files.
So for most stores, the core fix landed on its own. Fixes are also being backported to older branches back to 4.7.
What to do: Open Dashboard > Updates and confirm you’re on 7.1.3. If you’re not, your host or a setting may have turned off auto-updates. Ask why.
Plugins are where stores actually get hit
Plugins don’t follow the same rule. By default, WordPress only auto-updates plugins in special cases. Everything else waits for you.
WPC Product Bundles for WooCommerce is a good example. Patchstack’s database lists a stored XSS flaw (CVE-2026-93836) in versions 8.6.6 and earlier. An attacker doesn’t need to log in to plant it. The fix is in version 8.6.7.
The Hacker News reported Patchstack’s findings on October 12. Attackers are using this flaw and a similar one in Ninja Forms. The attack drops a JavaScript file that runs in an administrator’s browser. From there it installs a malicious plugin, creates a hidden admin account, and reports back to the attacker.
Notice the target. The attacker doesn’t need your password. They need you, logged in, to view a page where their code waits.
The same report covers Bricksforge, a plugin for the Bricks site builder. Its flaw (CVE-2026-85097) scored 10.0 out of 10 on the CVSS severity scale. It let attackers upload and run their own code without logging in. Patchstack saw exploitation attempts from 63 unique IP addresses, which it says suggests automated attacks.
Bricksforge isn’t a WooCommerce plugin, but the lesson carries over. Automated attacks go after any plugin they can exploit, including the ones on store sites.
How many plugins are on your store right now? Do you know which ones handle form input from shoppers?
A fix only protects you after you install it
Here’s the part that matters most. Patchstack published the bundles flaw on September 23, 2026. The Hacker News reported active attacks on October 12. That’s almost three weeks where a fix existed and stores still got hit.
The fix was never the problem. The update just didn’t reach those stores in time.
This happens all the time. The Hacker News article, citing Wordfence, says 2,073 WordPress-related vulnerabilities were published in Q2 2026 alone. Nobody reads every one. You don’t have to. You just need your plugins updated faster than attackers can scan for old versions.
There’s a second catch. The Hacker News notes that updating fixes the flaw but doesn’t remove an infection that already happened. If an attacker created a hidden admin account last week, updating today won’t delete it.
What to do this week: If you use WPC Product Bundles, confirm you’re on 8.6.7 or later. If you were on an older version, look for signs of a past attack:
- Admin accounts: The Hacker News says to check for hidden admins in the database, not just on the Users screen. Ask your host or developer to help if you’re not sure how.
- Must-use plugins: Look in the
wp-content/mu-pluginsfolder for files you didn’t add. These load automatically and can’t be turned off from the Plugins screen. - Server logs: Ask your host to check access logs for unusual requests around the attack dates.
If you find something, restore from a clean backup and change all admin passwords.
A 15-minute monthly plugin audit keeps the gap small
You don’t need a security team. You need a routine. Put this on your calendar for the first Monday of each month.
1. List what you have (2 minutes). Go to Plugins > Installed Plugins. Count them. Note anything you don’t recognize or haven’t used in months.
2. Update what’s waiting (3 minutes). Install pending plugin and theme updates. Take a backup first. WooCommerce’s own security guide recommends regular backups stored off-site.
3. Turn on auto-updates for low-risk plugins (2 minutes). Since WordPress 5.5, you can enable auto-updates plugin by plugin. Use the “Automatic update” column on the Plugins screen. WordPress checks twice a day and emails you when an update succeeds or fails.
Keep auto-updates off for plugins that touch checkout or payments if you’d rather test those first. That’s a trade-off, not a rule.
4. Check a vulnerability database (5 minutes). Search your plugin names on Patchstack or Wordfence Intelligence. Both list known flaws by plugin and show the fixed version.
5. Remove what you don’t use (3 minutes). Deactivate and delete unused plugins. A deactivated plugin’s files still sit on your server. WooCommerce’s guide says to remove plugins that are no longer maintained or have known vulnerabilities.
While you’re in the dashboard, check one more thing. When did each plugin last update? A plugin with no update in over a year deserves a closer look.
Before Black Friday, freeze features, not security updates
Many stores lock their site in November. No new plugins, no redesigns, nothing that could break checkout. That’s a smart habit.
But a feature freeze shouldn’t become an update freeze. The bundles flaw shows how attackers move inside a few weeks of a fix. A store that stops updating on November 1 could be exposed through the busiest weeks of the year.
A safer approach:
- Freeze new plugins and design changes from early November.
- Keep installing security updates as they come out.
- Test checkout after each update. Add a product to the cart and complete a test order. It takes two minutes.
- Use a staging site if you have one. WooCommerce’s guide recommends testing updates there before going live.
- Turn on two-factor login for every admin account. WooCommerce’s guide lists it as a core step.
Ask yourself: if a critical plugin flaw were published on November 20, how fast could you update?
How WCBoost can help
WCBoost doesn’t make security plugins. But the same habits apply to every plugin on your store, ours included.
- Changelogs to check: Read each plugin’s changelog during your monthly audit, ours included. Start from our docs.
- Update checklists: Our post on WooCommerce 11.2 and what to check first walks through “update, then test” for a major release.
- Fewer plugins, fewer risks: If you’re comparing tools for variation swatches or a wishlist, pick ones that are actively maintained.