October 2026 Security Patches: What to Patch This Week

Back on October 28 I mentioned CVE-2026-98432 in passing, as the Linux bug Anthropic's model turned into remote root. It deserves more than a passing mention. It's a use-after-free in how the kernel handles incoming IPv4 TCP connections, so almost any Linux server or VPS that accepts connections is running the vulnerable code. The kernel's CVE team scores it 9.8, and Red Hat rates it Critical in a security bulletin published October 30. SUSE, Amazon and Oracle rate it 8.1, Important.

The part that confused me at first: Anthropic's exploit needed a server with a multipath TCP (MPTCP) listener, and took 48 minutes to leak a kernel address, then five more to get a root shell. But the bug itself isn't an MPTCP bug. The Go security team put it plainly: systems with no MPTCP listeners may be vulnerable to similar attacks.

Where the fixes are (as of about 9:50 AM CST, November 2):

• Debian: fixed. Bookworm in 6.1.190-1 and trixie in 6.12.113-1, per the Debian tracker.
• Amazon Linux: fixed in AL2 and AL2023 kernels, advisories dated October 24 to 30.
• Oracle Linux: fixed in the UEK kernels for Oracle Linux 7 through 10, released October 16.
• SUSE: partly fixed. SLES 16.0 and the SLES 15 SP4 to SP6 LTSS kernels have updates. SLES 15 SP7 and Leap 15.6 are still in progress.
• Ubuntu: no fix yet. Ubuntu's tracker still lists every supported release as vulnerable, with fixes for 22.04, 24.04, 26.04 and 26.10 marked "work in progress" and target kernel versions listed.
• Red Hat: fixed. Red Hat shipped kernel updates on November 1 for RHEL 10 (RHSA-2026:93413), RHEL 9 (RHSA-2026:93412) and RHEL 8 (RHSA-2026:93414, plus RHSA-2026:93415 for the real-time kernel), per its CVE page. RHEL 6 and 7 are listed as not affected.

On RHEL 8, 9 or 10: install the kernel update, reboot, and check uname -r shows the new kernel.

What I'd do on an Ubuntu box today:

1. See if anything listens on MPTCP. ss -Mltn lists MPTCP listeners. Go programs built with Go 1.24 or newer use MPTCP for listeners by default on Linux, so check even if you never turned it on.
2. Turn MPTCP off if you don't use it. Most servers don't. Set net.mptcp.enabled = 0, save it so it survives a reboot, then restart the services that were listening, since sockets that are already open keep going. For a single Go program you can set GODEBUG=multipathtcp=0 instead, but the Go team calls per-program switches a "fragile mitigation".
3. Consider Red Hat's packet filter. Its bulletin gives an nftables table that drops incoming IPv4 TCP packets carrying IP options. Red Hat says it reduces exposure but can't fully prevent it, and to test it before production. Ordinary traffic should be fine, but try it on one server first.
4. Patch and reboot as soon as your distro ships. The kernel update does nothing until you reboot into it, so check uname -r afterwards. Then remove the nftables table.

# Which kernel am I running?
uname -r

# Anything listening on MPTCP?
ss -Mltn

# Turn MPTCP off now and after reboots
sudo sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/90-cve-2026-98432.conf

# Red Hat's filter: save as cve-2026-98432.nft, test it first
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft

# After you've rebooted into a fixed kernel
sudo nft delete table inet cve_2026_98432

Two more things. Containers share the host's kernel, so patching inside a Docker image does nothing here, it's the host that needs the update. And if you're on managed hosting or a platform where you don't control the kernel, it's your host's job, so it's fair to ask them when they're rebooting into the fix. I'll update this box when Ubuntu ships.

First, Project Manager by weDevs now has a public exploit. This is CVE-2026-116512 (CVSS 9.8), the no-login code execution bug in the list further down this box. On November 1 someone posted an exploit script for it on GitHub. I read the repo's README but didn't open or run the code, and I'm not linking it. Per the README, it takes a file full of site addresses and works through them in parallel, and it has a shell upload mode. Per ThreatWire and Exploit Intel, which both read the code, that mode writes a webshell that takes commands from anyone who finds it, no password. So this went from a bug you'd need to work out yourself to one anyone can point at a list of sites.

What isn't confirmed is attacks. It's not on CISA's Known Exploited Vulnerabilities list, and CISA's own assessment on the CVE record, last updated the morning of November 2, still says no known exploitation. Patchstack's entry does show a "Known to be exploited" label, but it doesn't say where or show any attack data, and it puts the same label on the Gravity Forms bug in the October 30 update below, which also has a public proof of concept. So I'm not calling this one exploited. I'd still treat it as the most urgent thing in this box.

What to do: update to 4.1.2 or later, which came out October 29. If you can't update today, deactivate it until you can. Then, if a site was on 4.1.1 or older, check whether someone got in first. Don't only look in uploads. Exploit Intel says the script hunts for the folder that holds wp-config.php and writes its shell there, as mushr00w_upl.php. A file name is easy to change, so check the broader stuff too:

# Which version? You want 4.1.2 or later.
wp plugin list --name=wedevs-project-manager --fields=name,status,version,update
wp plugin update wedevs-project-manager

# Can't update yet? Turn it off until you can.
wp plugin deactivate wedevs-project-manager

# Who has admin? Look for accounts you didn't create.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes

# Run these from the WordPress folder.
# PHP in uploads. There should almost never be any.
find wp-content/uploads -name '*.php'

# PHP files changed since the bug went public on October 30
find . -name '*.php' -newermt '2026-10-30' -not -path './wp-content/cache/*'

# The file name Exploit Intel reports
find . -iname 'mushr00w*'

# Hits on the plugin's API in your access log. The log path depends on your host.
grep -iE 'pm(/|%2F)v2|mushr00w' /path/to/access.log

Your own team using the plugin shows up in that last one too, so look for requests from addresses you don't recognize. File dates can be faked, so a clean result from the second command isn't proof. If you find anything, treat the site as compromised: restore a backup from before the first bad file or request, change admin and database passwords, run wp config shuffle-salts, and go through my checklist for auditing a WordPress site after a plugin compromise. Updating closes the hole. It doesn't remove a shell that's already there.

Delete this one. There's no fix:

• Bot for Telegram on WooCommerce, every version through 1.3.0. CVE-2026-109516 (9.8), published by Wordfence October 28. Anyone who knows a username can log in as that user, admins included, without the password. Per the CVE, the plugin's Telegram webhook endpoint takes requests from anyone and never checks they came from Telegram, so an attacker can send a fake message carrying your username. The plugin then makes a login token from the attacker's browser string and the current time, which is easy to guess, and hands over a logged-in session for it. WordPress usernames are often easy to find, so don't count on yours being secret. Wordfence and Patchstack both list it as unpatched, and 1.3.0 (May 2026) is still the latest version. WordPress.org closed the plugin on October 23, pending a full review, so you can't download it anymore. That doesn't remove it from sites that already have it. Deactivate it and delete it. It isn't on CISA's KEV list and I haven't seen reports of attacks, but with no fix coming that I know of, I wouldn't wait for one.

If it was on a site, delete it, then log everyone out and look for admins you don't recognize:

# Is it installed? If this prints a row, it is.
wp plugin list --name=bot-for-telegram-on-woocommerce --fields=name,status,version

# Remove it
wp plugin deactivate bot-for-telegram-on-woocommerce
wp plugin delete bot-for-telegram-on-woocommerce

# New salts log out every user, including anyone who got in this way
wp config shuffle-salts

# Who has admin? Look for accounts you didn't create.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Then reset admin passwords and go through the audit checklist linked at the bottom of this box.

Next, Ninja Forms, which is on a lot more sites. Ninja Forms (500,000+ active installs) got four more CVEs on October 31, all affecting 3.15.5 and older and all fixed in 3.15.6 (October 15). Update to 3.15.7 or later. 3.16.0 came out November 2 with translation fixes and built-in PayPal payments, and its changelog lists no new security fixes. None are rated critical, but the worst one is the same kind of bug attackers used on this plugin last month.

• CVE-2026-109997 (7.2). Anyone can store a script in a form submission with one request, no login. Per the CVE, the submit endpoint hands a fresh security token to anyone whose request fails, so the token check doesn't stop it. The code it points to includes the admin submission screens, so the script would run when someone logged in opens that entry.
• CVE-2026-100155 (6.5). Anyone can get the success message to run WordPress shortcodes. How much that matters depends on which shortcodes your other plugins add.
• CVE-2026-100151 (6.1). A rigged link can run script in the browser of whoever clicks it.
• CVE-2026-101326 (5.4). A logged-in subscriber can run shortcodes, but only if a public form uses the {wp:user_display_name} merge tag as a default value.

Why I'd do it today: on October 6, Patchstack reported attackers using an earlier Ninja Forms stored XSS (CVE-2026-94504, fixed in 3.15.4) through that same submit endpoint. Per Patchstack, the script sat in a submission until an admin opened it, then used that admin's session to install a fake plugin called WP Smart Thumbnails, create an admin account hidden from the Users screen by a must-use plugin, and add a backdoor login link. None of the October 31 Ninja Forms CVEs are on CISA's KEV list and I haven't seen reports of attacks on them. It's the same pattern, though.

3.15.7 has been on WordPress.org since October 26, even though its changelog is dated November 2. It hardens how merge tags handle submitted values and now actually enforces "Require user to be logged in" when a form is submitted. WordPress.org's version stats put only about 54% of sites on the 3.15 line, and that line still includes vulnerable releases. If you manage client sites, check each one:

# Which Ninja Forms version? You want 3.15.7 or later.
wp plugin list --name=ninja-forms --fields=name,status,version,update
wp plugin update ninja-forms

# Signs of the October campaign Patchstack described.
# Look for class-wp-query-(something).php or class-wp-token-validate.php you didn't add.
wp plugin list --status=must-use --fields=name
wp plugin list --name=wp-smart-thumbnails --fields=name,status
# An error here (option doesn't exist) is good news.
wp option get fz_emer_login_tokens

# Admins straight from the database, so a hiding plugin can't filter them out.
# Change wp_ if your table prefix is different.
wp db query "SELECT u.ID, u.user_login, u.user_registered FROM wp_users u \
  JOIN wp_usermeta m ON m.user_id = u.ID \
  WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%'"

A hidden admin won't show in wp user list while that must-use plugin is loaded, which is why the last command reads the database directly. If you find any of it, treat the site as compromised and use the checklist below. New salts won't kill that backdoor link. Deleting the must-use plugins and the option does.

Elementor: update to 4.3.6. Elementor (10,000,000+ active installs on WordPress.org) put out 4.3.6 on November 2. Its changelog lists three security fixes, for navigation links, icon and content handling, and Atomic elements and templates, with no details. As of the afternoon of November 2 there's no CVE or advisory for any of them on CVE.org, WPScan or Patchstack, so I can't tell you how serious they are. It also fixes MCP resources not loading in connected AI tools, if you've hooked an AI tool up to Elementor's MCP. Elementor Pro is a separate plugin with its own updates; this is the free core plugin, which Pro sites run too.

The bigger reason to update: two older bugs now have public proof-of-concept steps. Elementor 4.3.5 (October 13) fixed two stored XSS bugs in how it cleans SVG files, and WPScan published both on October 19:

• CVE-2026-81813 (CVSS 6.8). This is the one I'd worry about. Per WPScan, anyone with a Contributor account can add an SVG element to a post that loads an SVG from their own server, and Elementor's cleaner misses a script tucked into the file's text. No settings need to change on a site that started on Elementor 4.0 or later. It fires in Chrome, Edge and other Chromium browsers, not Firefox, for whoever views the post, including an admin previewing the draft.
• CVE-2026-81812 (CVSS 6.4). Needs an Author account, and per WPScan it only works if an admin turned on Elementor's Enable Unfiltered File Uploads setting and let Authors upload JSON files in the Role Manager. Both are off by default.

Dr. Web reported that WPScan planned to publish its proof of concept on November 2, and both WPScan entries now show step-by-step instructions. I read them and didn't run anything. Neither bug is on CISA's Known Exploited Vulnerabilities list, CISA's notes on both CVE records say no known exploitation, Patchstack rates both low priority, and I haven't seen reports of attacks. These aren't drive-by bugs: someone needs a login on your site first. But if guest writers, clients or old staff accounts have Contributor access, a script running in an admin's browser can generally do what that admin can, like create another admin.

How many sites are behind? Dr. Web said about 60% of installs were on branches older than 4.3 as of October 21. WordPress.org's version stats on November 2 put 46% on 4.3 and 54% on older branches, and the 4.3 share includes 4.3.0 through 4.3.4, which are still vulnerable. So more than half of Elementor sites are on a version with these bugs.

# Which version? You want 4.3.6 (4.3.5 at minimum for the SVG bugs).
wp plugin list --name=elementor --fields=name,status,version,update
wp plugin update elementor

# Is Unfiltered File Uploads on? 1 means on. Empty or an error means off.
wp option get elementor_unfiltered_files_upload

# Don't need custom SVG icons? Turn it off.
wp option update elementor_unfiltered_files_upload 0

# Who can write posts? Look for accounts you don't recognize.
wp user list --role=contributor --fields=ID,user_login,user_email,user_registered
wp user list --role=author --fields=ID,user_login,user_email,user_registered

# SVGs in the media library, and who uploaded them
wp post list --post_type=attachment --post_status=inherit --post_mime_type=image/svg+xml --fields=ID,post_author,post_date,guid

Until a site is updated, don't preview Contributor drafts in Chrome or Edge while logged in as an admin. I can't tell from the public write-ups whether updating cleans an SVG that's already saved in a post, so if you have contributors you don't fully trust, open their recent drafts in the editor and look for SVG elements that load from another site.

Security Optimizer by SiteGround, if you use its two-factor login. SiteGround's Security Optimizer plugin (1,000,000+ active installs on WordPress.org) had CVE-2026-118185 (CVSS 7.5), which WPScan published October 29. Before 1.6.9 the plugin never limited wrong two-factor codes. So someone who already had an admin's or editor's password could keep guessing codes until one worked. That's the exact case two-factor is there for: a password that leaked somewhere. Version 1.6.9 came out October 14, two weeks before the bug went public, and its changelog just says "2FA improvements."

The fix only works if login limits are on. I diffed 1.6.8 against 1.6.9. Wrong codes and backup codes now count as failed logins, and a locked-out IP address can't try codes at all. But all of that hangs off the plugin's Limit Login Attempts setting. Set it to Off and 1.6.9 still lets anyone with the password guess codes all day. The plugin sets it to 5 tries when it's installed, so the question is whether anyone turned it off. The count is per IP address, so it slows down a guesser with one address but does a lot less against one with many. One side effect I noticed in the diff: when the code prompt comes up, 1.6.9 now ends that account's other logged-in sessions, so don't panic if signing in on your laptop logs you out on your phone.

# Which version? You want 1.6.9 or later.
wp plugin list --name=sg-security --fields=name,status,version,update
wp plugin update sg-security

# Is its two-factor login on? 1 means yes. An error means it was never turned on.
wp option get sg_security_sg2fa

# Is Limit Login Attempts on? 0 means off. 3 or 5 means on.
wp option get sg_security_login_attempts

# Turn it back on at 5 tries.
wp sg limit-login-attempts 5

How urgent is it? It's not on CISA's Known Exploited Vulnerabilities list, CISA's notes on the CVE record say no known exploitation, and Patchstack rates it low priority. But WPScan says it will publish its proof of concept on November 29, so I'd update before then. It's also this plugin's second two-factor fix since August: CVE-2026-82228 (CVSS 8.1), which Patchstack lists as not needing a login, was fixed in 1.6.7. If an admin or editor password on one of these sites has ever turned up in a breach, change it too.

Then the rest of the October 31 batch. Also on October 31, Wordfence published CVEs for seven more WordPress plugins, all rated between 9.1 and 9.8. Those scores make them sound equally bad. They aren't. Three let someone with no login run code on your server, and a fourth can get there by deleting the right file. The other three deserve an update but aren't takeovers. The good news: every fix was out before the CVEs went public, some by almost two weeks. None of the seven are on CISA's Known Exploited Vulnerabilities list as of November 2, and I haven't seen reports of attacks. Project Manager now has a public exploit, though, which is why it's at the top of this box.

Update these today if you run them:

• Project Manager by weDevs: 4.1.2 or later. CVE-2026-116512 (9.8). Versions through 4.1.1 let anyone run code on the server through the plugin's REST API, no login needed. Per the CVE, WordPress runs the plugin's input check before its permission check, so the permission check never gets a say. 4.1.2 came out October 29. 5,000+ active installs. A public exploit came out November 1, so this one goes first. See the top of this box.
• PDF Invoice for WooCommerce + Drag and Drop Template Builder: 7.2.0. CVE-2026-109220 (9.8). Through 7.1.1, a crafted order note on an ordinary guest checkout can end in code running on your server. The CVE says it works on a default install if the store takes bank transfer or cheque payments, because those orders go on hold and that's what generates the invoice. 7.2.0 came out October 28. 500+ active installs.
• SimpleForm: 3.11.0. CVE-2026-118235 (9.8). Through 3.10.2, anyone who can load a page with one of its forms can upload a file that may run as code, by ending the file name with a dot. 3.11.0 came out October 28. It's small, 30+ active installs, but if a client site has it, this is the one I'd fix first.
• Acadlix LMS: 1.2.0. CVE-2026-103882 (9.1). Through 1.1.9, an attacker can delete any file on the server. The CVE says it takes a subscriber account, then says the only real check is a token the plugin prints on every public page, so in practice no login. Deleting wp-config.php is the classic move: WordPress then offers to run its installer again. 1.2.0 came out October 23 and drops the vulnerable endpoint. 40+ active installs.

Update these too, but they're not takeovers:

• Uncanny Toolkit for LearnDash: 3.8.3. CVE-2026-119096 (9.8). Through 3.8.2, someone who already has a user's password can log in even if you never approved that account or you suspended it. It gets around the plugin's approval and suspension controls. It doesn't get anyone in without a password. 3.8.3 came out October 29. 20,000+ active installs.
• Popup Builder: 4.4.6. CVE-2026-89270 (9.1). Through 4.4.5, one request from anyone can move every published popup to the trash. That's vandalism, and on a store that lives on its popups it costs sales, but they land in the trash, so you can restore them. 4.4.6 came out October 19. The biggest one here, at 200,000+ active installs.
• WP Booking System: 2.1.0.6 or later. CVE-2026-116557 (9.1). Through 2.1.0.5, someone can delete the notes on any calendar. The CVE description says that takes a subscriber account, but its title says no login, so I'd assume no login. 2.1.0.6 (October 26) added the missing checks, and 2.1.0.7 is current. 10,000+ active installs.

If you manage sites with WP-CLI, this shows what's installed and whether an update is waiting. Plugin folder names usually match the slugs below, but check the list before you trust the update line:

# What's installed, what version, and is an update waiting?
wp plugin list --fields=name,version,update

# Update just these seven, where present
wp plugin update wedevs-project-manager pdf-for-woocommerce simple-form acadlix \
  uncanny-learndash-toolkit popup-builder wp-booking-system

If the Telegram plugin, a Ninja Forms older than 3.15.6, or any of the first four plugins in that list were on a site at a vulnerable version, fix it, then go through my checklist for auditing a WordPress site after a plugin compromise. Updating closes the hole. It doesn't remove anything someone left behind.

Facts as of November 2, 2026. Install counts are WordPress.org's rounded numbers. WordPress.org doesn't show one for the Telegram plugin since it's closed.

If you run an Express app, two High-severity fixes belong on this list. Each bug lets a single request from anyone, no login needed, crash your Node process. The Express team wrote them up on October 31, but the fixed versions have been on npm since October 22, so there's no reason to wait.

• body-parser: update to 2.4.0 or 1.20.9. CVE-2026-111181 affects versions before 1.20.9 and 2.0.0 up to 2.4.0. body-parser is what's behind express.json() and express.urlencoded(), so this is most Express apps. A gzip-compressed body with extra bytes tacked on the end crashes the process, with default settings. Parsing runs before routing, so the attacker doesn't need a real route or a login.
• multer: update to 2.5.0. CVE-2026-113872 affects 2.0.0 up to 2.5.0, but only if your upload code uses an async fileFilter. A synchronous fileFilter isn't affected. If you're still on multer 1.x, it's not in this advisory's range, but npm marks 1.x deprecated with known vulnerabilities, so move to 2.5.0 anyway.

The catch with npm update. Express recommends npm update body-parser multer. I tested that against old lockfiles, and it works on Express 5 and on Express 4.22 or newer. It does nothing for body-parser on Express 4.21.2 or older, because those versions pin body-parser to exactly 1.20.3. npm reports success and you're still on 1.20.3. The same thing happens if your package.json pins multer to an exact version like "2.4.0" instead of "^2.4.0".

# What am I running?
npm ls express body-parser multer

# Express 5, or Express 4.22 and newer
npm update body-parser multer

# Express 4.21.x or older: Express has to move to 4.22.x too
npm update express body-parser multer

# Check again
npm ls body-parser multer
npm audit

If your package.json pins Express to an exact old version and you can't move it yet, an npm override forces the fixed body-parser underneath it. Add this to package.json and run npm install:

"overrides": {
  "express": {
    "body-parser": "^1.20.9"
  }
}

Then commit the updated package-lock.json and redeploy. On Vercel or any host that builds from Git, nothing changes until a new build runs. In Docker, rebuild the image.

And update Node. Express also tells everyone to upgrade Node for the Brotli bug, CVE-2026-111497, which reaches Express apps through the same body parsers when a request is sent Content-Encoding: br. That's the Node.js section below and my Brotli post: 22.23.4, 24.22.1, 26.12.1 or later. It got more urgent on October 27, when CISA added it to its Known Exploited Vulnerabilities catalog. The new body-parser doesn't fix the Brotli bug. Only a patched Node does.

Four WordPress plugins to check today. All four already have fixes out. One of them, the critical Gravity Forms bug, was added to VulnCheck's known exploited list on October 30. CISA hasn't listed it, and I haven't seen details of the attacks. I haven't seen exploitation reports for the other three. Most of these were disclosed on October 29, though some of the fixes have been out for weeks. If you're behind, you've been exposed that whole time.

• MainWP: Dashboard 6.4, and Child 6.4 on every connected site.
• Gravity Forms: 3.1.3 or later. The current release is 3.2.1.
• AI Engine: 3.8.7 or later. The current release is 3.8.9.
• Formidable Forms: 7.0.

MainWP: update the Dashboard and every child site to 6.4. MainWP shipped 6.4 on October 29, and WPSec published three advisories on October 30. The worst is in MainWP Child 6.3 and older (rated 8.1). Anyone holding one real signed request or login link from your Dashboard could replay it with their own settings and potentially log in as an administrator. They'd need that captured request first. In the Dashboard (rated 8.8), the bulk user import page had no security token check. Opening an attacker's page while you're logged in could create admins on your child sites. A third bug (rated 5.3) lets anyone switch off white-label branding. Child has more than 700,000 active installs, and there are no CVE numbers yet, so a scanner that matches on CVEs won't flag these. Two catches: Child 6.4 has to go on every client site, and Dashboard 6.4 needs PHP 8.3 or newer. With PHP2Shell around, that means 8.3.36 or later. My take: until the Dashboard is updated, stay logged out of it when you're not using it.

Gravity Forms: update to 3.1.3 or later. Wordfence published two bugs on October 29 that affect 3.1.2 and older. The big one is CVE-2026-103039, rated 9.8 (critical): a PHP object injection anyone can trigger by submitting a form. According to WordSec, your site is exposed only if a form has a Post Custom Field set to the List input type with a content template turned on. Gravity Forms has no gadget chain of its own, so turning this into code execution takes a usable chain from another plugin or theme, or a particular server setup. The second, CVE-2026-97645 (7.2), is stored cross-site scripting through the List field. An admin would have to click a planted link in the entry view and confirm a prompt. VulnCheck lists the object injection bug as exploited in the wild as of October 30. Updated November 1: a public proof-of-concept script for this bug went up on GitHub on October 31. I'm not linking it. It can check which Gravity Forms version a site runs and look for vulnerable forms, though it leaves out the piece that builds the actual payload. I'd expect more scanning because of it, so treat 3.1.2 and older as urgent. The fix has been out since 3.1.3 on October 1, so if you update regularly you're probably covered. Check anyway. The changelog shows 3.2.1 as the current release. My take: Gravity Forms updates come through your license. If a client's license lapsed, the update may never have shown up, and that's the site I'd check first. If a site was on 3.1.2 or older and has a form that creates posts, update it, then go through my audit checklist.

AI Engine: update to 3.8.7 or later, and check whether MCP is even on. CVE-2026-110732 affects 3.8.6 and older, and Patchstack rates it 7.5. It only matters if you turned on the plugin's MCP feature, which lets AI tools like Claude or ChatGPT act on your site. In those versions, anyone could register their own app with the MCP sign-in, using a redirect address they control. If an admin then approved that app on the consent screen, the attacker got an admin-level token. That's enough to create users and change settings. The consent page could also be loaded invisibly inside another site, so a hidden "approve" click was possible. Per the changelog, 3.8.7 (October 23) stops that framing and shows where an app will send you. 3.8.8 adds more MCP fixes, and 3.8.9 is current. The plugin has more than 90,000 active installs, and MCP was off by default in the affected versions. My take: if you don't use MCP, switch the module off. If you do, look through the MCP connections it has approved and remove any you don't recognize.

Formidable Forms: update to 7.0. The vulnerability is tracked as CVE-2026-89435 and rated 8.8. In 6.35 and older, any logged-in user, down to a Subscriber, could make the site install a plugin of their choosing. That's effectively a takeover. It only affects sites running the free plugin without Formidable Pro. So if your site lets visitors register, or you have customer or member accounts, this one is serious. Some listings say there's no patched version, but there is. The CVE record points to the 7.0 code changes, and Formidable's 7.0 changelog lists added permission checks against unauthorized plugin installs. 7.0 came out October 16. My take: 7.0 is a big release that adds MCP support and changes a lot in Stripe payments. After updating, submit a test entry on any form that takes payments. If you can't update right away, turn off open registration under Settings, General.

# Check versions (Gravity Forms' slug is usually gravityforms):
wp plugin list --fields=name,version,update_version | grep -E 'mainwp|gravityforms|ai-engine|formidable'
# Update what's behind, for example:
wp plugin update mainwp-child ai-engine formidable
# Look for admins you don't recognize:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Facts as of about 10:20 PM CDT, October 30, from WPSec, Wordfence's CVE records, WordSec, Patchstack, VulnCheck's KEV listing and each vendor's changelog. If you'd rather someone else keep your sites patched, get a free quote.

Quick recap: the private keys of eight eMudhra intermediate certificate authorities were compromised. Six of them issue TLS certificates, so someone holding those keys could make a certificate that looks valid for any website. Apple says it has blocked them in Safari, Mail and apps that use Apple's security frameworks since October 19, and it started blocking the emSign ECC Root CA - G3 root on October 23. You don't have to do anything for those.

The command line is the gap. Apple's own support page says the curl, git, python3, ruby, perl and openssl that come with macOS or the Xcode Command Line Tools check certificates against /etc/ssl/cert.pem. For anything that chains to a root in that file, they don't check Apple's block or whether the certificate was revoked. Apple says the real fix is coming in a future macOS update. Until then, its workaround is removing two roots from that file by hand: emSign ECC Root CA - G3 and, optionally, AAA Certificate Services.

Here's the catch. macOS Golden Gate 27.2 shipped October 26. Its security notes don't mention eMudhra, and the update replaces /etc/ssl/cert.pem with Apple's copy. AAPL Ch. tested it on a macOS 27.0 virtual machine: roots removed before the update were back after it, and it reports the same for Tahoe 26.7.2 and Sequoia 15.8.2. A separate test on 26.7.2 counted 126 certificates in the file before the update and 128 after, and the built-in curl connected to test sites it had refused before the update. Apple's page does warn that an update can replace the file. I'll admit I would have assumed an OS update leaves a file I edited alone. It doesn't. If you did the workaround last week, assume it's gone.

What I'd do on every Mac you develop on:

1. Check the file after every update. Apple's check command lists either root if it's still there and shows nothing if both are gone: openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'
2. If a root is back, redo Apple's steps. Apple says to delete the old backup first with sudo rm /etc/ssl/cert.pem.orig, then repeat its steps exactly as written. Removing AAA Certificate Services also stops these tools from verifying some sites that chain to it for legitimate reasons, so test the things you depend on.
3. Know which copy you're running. Some tools bring their own certificate list and never read this file. The Python releases further down make Python's ssl module reject the compromised keys whatever your settings say, and Composer 2.11 rejects those intermediates even when the system store trusts their roots. Run which python3 and composer --version so you know whether you're on Apple's copy or your own.
4. Don't forget the other Macs. CI runners and shared dev machines get updates too. Put the check in whatever runs after updates, not on a wiki page nobody reads.

If you'd rather have someone else keep track of the Macs and servers your business depends on, get a free quote.

October 30 update: people are actively trying the update bug. Of the 22 fixes in 7.1.4, the one I listed first, the race condition in the update process, is now being probed. Wordfence told SecurityWeek that its firewall rule for it got a first hit nine minutes after going live on October 28, and that it logged more than 18,500 requests for staged setup-config.php installer paths in the first 21 hours. A day later, Wordfence told The Hacker News it had blocked 62,969 attacks on the flaw over 24 hours. Two of the largest sources polled small groups of sites for about 14.5 hours, which looks like waiting for an update to start. Those are attempts. Wordfence hasn't reported a successful compromise, and there's still no CVE number.

How it works, briefly. During a full-package core update, older versions unpack the new WordPress into a folder under wp-content/upgrade/ with a predictable name, and on many servers that folder is reachable from the web. For a few seconds it holds a complete copy of WordPress, installer included. If an attacker requests that installer at just the right moment, they can point it at a database they control and get PHP code running on your server. It's hard to time. That's why Wordfence rates it 8.1 (high) with high attack complexity, and WordPress's own advisory rates it low. 7.1.4 adds random characters to the folder name, keeps an index.php in the folder, and never copies a wp-config.php out of it.

Every branch has its fix now. Per that advisory, the patched versions are 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34 and 4.7.39. Sites on 4.6 or older get no fix at all.

How to confirm you're patched:

1. Check the version against your branch. Go to Dashboard > Updates, or run wp core version. It should match your branch's number in the list above, or be newer.
2. Make sure the update actually finished. wp core verify-checksums compares your core files with WordPress.org's copy of that release. A leftover .maintenance file in the site root means an update got stuck partway. My take: if Dashboard > Updates is still offering the security release, the update didn't take.
3. Look in the staging folder. According to Patchstack, between updates wp-content/upgrade/ should hold nothing but an index.php. The old cleanup could delete that file, so an empty folder is fine too. A leftover folder, especially one with wp-admin/setup-config.php or a wp-config.php inside, deserves a closer look.
4. Check that wp-config.php still points at your database. Copying a planted wp-config.php into your live site is the step the fix blocks. If DB_HOST or DB_NAME isn't yours, treat the site as compromised.
5. Search your access logs. Requests under /wp-content/upgrade/ that end in setup-config.php or install.php are probes. The one that matters is a 200 response during an update. Also look for what Wordfence lists: admin accounts, plugins and PHP files you don't recognize.
6. Block the folder at the web server. Patchstack recommends denying web access to wp-content/upgrade/, and notes that a PHP security plugin can't catch this, because the staged copy never loads your plugins. My take: it costs nothing and covers the next update too.

wp core version
wp core verify-checksums
ls -la wp-content/upgrade/
find wp-content/upgrade -mindepth 1 ! -path wp-content/upgrade/index.php
grep -E "DB_(HOST|NAME)" wp-config.php
# Probes in your logs (adjust the path for your server):
zgrep -E "wp-content/upgrade/.*(setup-config|install)\.php" /var/log/nginx/access.log*
# Block the folder. nginx, in the server block:
#   location ^~ /wp-content/upgrade/ { deny all; }
# Apache, in the site root .htaccess:
#   RedirectMatch 403 ^/wp-content/upgrade/

My take: if you find a 200 on that installer path during an update window, or anything else on Wordfence's list, don't start deleting things. Save the logs and files first, then work through my audit checklist. Facts as of about 10:15 PM CDT, October 30, from Wordfence via SecurityWeek and The Hacker News, WordPress's advisory and Patchstack. The original October 28 write-up follows.

WordPress released 7.1.4 on October 28 as a security release, and WordPress.org recommends updating immediately. Its release notes count 22 vulnerabilities fixed. Most are stored cross-site scripting that needs a logged-in account, usually Contributor or higher. The risk is highest on sites where people other than you can log in and write: staff, guest authors, members.

What it fixes:

• The update process itself. A weakness in the upgrade process, which the release notes describe as a race condition during core updates, could lead to remote code execution during the upgrade window.
• Stored XSS in many places. Several in the Interactivity API (plus a stored denial of service there), Customizer selective refresh, the Categories block, the Comments Pagination and Post Navigation Link blocks, specially crafted block markup, and the privacy data-removal requests screen.
• One leak that needs no login. Visitors who aren't logged in could discover unpublished Customizer changesets, meaning design changes you've saved but not published.
• Smaller fixes. Specially crafted user logins (the release post calls it stored XSS, the release notes call it hardening on the multisite Network Users screens), unsafe replacements in the Image and Playlist blocks, and custom roles that moderate comments being able to read notes on posts they can't edit.
• Root certificates. The certificates bundled with WordPress were updated because of the eMudhra revocation, the same certificate problem behind the Python update further down.

Will it install itself? If your site supports automatic background updates, WordPress says the update starts on its own. Otherwise go to Dashboard > Updates and click Update Now. WordPress is also backporting the fixes to every older branch still eligible for security fixes, back to 4.7. As of October 30, every backport is out, from 7.0.8 down to 4.7.39 (full list above). Only the newest version is actively supported, and the next major release, 7.2, is planned for December 8.

What I'd do this week:

1. Confirm the version on every site. Don't assume auto-updates ran. Hosts, plugins and config settings can turn them off. Check Dashboard > Updates, or run wp core version with WP-CLI.
2. Take a backup, then update. If you're on an older branch, update within it, then plan the move to 7.1.
3. Review who can write. Most of these bugs need a Contributor account or higher, so remove accounts nobody uses.
4. Don't stop at WordPress. The PHP underneath it matters more. PHP2Shell is still first on the list below. If you think a site was already tampered with, start with my WordPress audit checklist.

I handle WordPress updates and maintenance for businesses in Nashville and Middle Tennessee. If you'd rather not track this yourself, get a free quote.

Google's October 27 Chrome update (156.0.8078.73 on Linux, 156.0.8078.73/.74 on Windows and Mac) fixes 52 security bugs, four of them rated critical. Going by Google's release notes, 18 of those 52 credit Anthropic or its researcher Xinyang Ge, including all four critical ones. Six say "assisted by Claude." Google doesn't flag any of the 52 as exploited in the wild. Chrome 156.0.8078.47, the October 20 release, doesn't have these fixes, so a machine still showing .47 needs this update.

Why Anthropic is in the credits. On October 27, Anthropic's Frontier Red Team said an unreleased internal research model found critical bugs in Chrome, Safari, Android, Windows and Linux, then wrote working exploits after "initial prompting." That's Anthropic's account, and it doesn't break down how much a person did at each step. The headline example chains four Chrome bugs. Opening one web page in a stock, default-configured Chrome on macOS ran code outside the browser's sandbox, with no further clicks. Anthropic says 62 CVEs from this work have been assigned and patched as of Chrome 156, all rated critical or high. I can match 18 in the October 27 notes and 15 in the October 20 release. I can't confirm the full 62 from Google's notes.

The other platforms. Everything below except Android has a published fix:

• Safari: a chain that let a web page read data from other sites you're signed in to, like email. Apple's June 29 Safari 26.5.2 and iOS 26.5.2 notes credit "Milad Nasr and Nicholas Carlini with Claude, Anthropic" for a WebKit use-after-free, CVE-2026-43715. Anthropic doesn't name the CVE, so that match comes from The Hacker News.
• Android: copying photos and data off a locked, stolen phone over USB. Anthropic says Google has addressed it. I couldn't find a public advisory.
• Windows: a remote crash, not code execution, on machines that answer HTTP/3. Anthropic ties it to CVE-2026-33096, which Microsoft patched in April and describes as an HTTP.sys denial-of-service bug rated 7.5. Microsoft's record doesn't name a finder.
• Linux: remote root on servers running a multipath TCP listener. Anthropic ties it to CVE-2026-98432, a kernel use-after-free published October 15 and fixed in the stable kernel branches, rated 9.8 in NVD. The NVD description covers an IPv4 TCP fix, so the multipath TCP link comes from Anthropic's post.

What this means for a small business. If models can find and chain bugs like these, the time between a patch and a working exploit gets shorter, and "we'll update next month" gets riskier. For the browsers and devices your team uses:

1. Relaunch Chrome. Chrome downloads updates on its own but only applies them when it restarts. Open chrome://settings/help and look for 156.0.8078.73 or later.
2. Check managed devices, not just your own. In Google Admin, Intune or Jamf, look for machines still on 156.0.8078.47 or older. Set Chrome's RelaunchNotification policy so laptops that never close the browser still restart into the update.
3. Don't forget other browsers. Update Edge, Brave and other Chromium browsers when their makers ship these fixes, and keep Safari, iPhones and iPads on 26.5.2 or later.
4. Patch the servers too. On Linux, install your distro's kernel update and reboot. For CVE-2026-98432, Red Hat shipped fixed kernels on November 1, but as of November 2 Ubuntu hadn't, so see the Linux update at the top for what to do in the meantime. On Windows servers that answer HTTP/3, make sure April's updates are in.

If you want a hand checking which of your team's machines and sites are behind, get a free quote.

If you use Tailscale SSH on your servers, add this one to the list. On October 25, researcher Erica Windisch of Cyberdione Labs published Tailworm, a report with 11 findings from testing Tailscale 1.104.2 and headscale 0.29.5, the self-hosted control server. The most serious claim: someone who controls a device your access rules already let connect over Tailscale SSH can use its socket forwarding to get root on the server.

On October 26, Tailscale posted an update. It doesn't go through the report finding by finding, but it says most of the SSH issues it has found are privilege escalation: someone already allowed to connect over Tailscale SSH “may be able to perform actions beyond the permissions of their configured local user, including potentially gaining elevated privileges.” Tailscale calls them serious, says it has fixes for most of them in testing, and is targeting a patched client by the end of Tuesday, October 27, “subject to successful completion of testing.” It isn't telling everyone to turn Tailscale SSH off.

The patched version is out: Tailscale 1.104.4. Tailscale released 1.104.4 on October 27 and published four security bulletins with it. The one behind the root claim is TS-2026-014: Tailscale SSH's Unix socket forwarding ran as root, so a peer allowed to forward could reach root-only sockets like the Docker socket or the tailscaled local API. Tailscale now does that forwarding as the logged-in user. TS-2026-015 fixes a Tailscale SSH memory bug that could crash tailscaled, and TS-2026-016 and TS-2026-017 cover Tailscale Serve. All four are fixed in 1.104.4 or newer, so update every node that runs Tailscale SSH or Serve. The forwarding switch below is still a good stopgap for any machine you can't update right away.

What to do today. Tailscale recommends four things:

• Review your Tailscale SSH access policies, so only the users and devices that need access have it.
• Turn off SSH forwarding if you don't need it, by setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service. Tailscale says this keeps Tailscale SSH working and “mitigates several of the more serious findings.”
• Tighten access to sensitive systems for now.
• Get ready to install the patched client as soon as it's out.

On a Linux server with Tailscale's standard systemd service, that environment file is /etc/default/tailscaled:

tailscale version
echo 'TS_SSH_DISABLE_FORWARDING=1' | sudo tee -a /etc/default/tailscaled
sudo systemctl restart tailscaled

That turns off port and socket forwarding (ssh -L and ssh -R) through Tailscale SSH. Normal shell sessions keep working. If you're connected to the server over Tailscale while you restart it, expect a brief drop, and have another way in just in case. If you don't use Tailscale SSH at all, tailscale set --ssh=false turns it off. If you only use Tailscale as a private network and run regular OpenSSH over it, Tailscale's update is about its built-in SSH server, not your OpenSSH. Tailworm also lists findings in app connectors and headscale, so if you run either, read the report's own mitigation notes.

Sources for this update:

• Tailscale, “Tailscale SSH: Investigation and remediation update” (Oct 26, 2026)
• Tailworm, security assessment of Tailscale v1.104.2 and headscale v0.29.5 (Cyberdione Labs)
• Tailscale changelog and Tailscale security bulletins
• The Hacker News, “Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers”
• Tailscale security bulletins TS-2026-014 through TS-2026-017 (fixed in 1.104.4)

If you run WordPress, two plugin updates belong on this week's list. Both can be triggered without an account.

LiteSpeed Cache: update to 7.9.2 or later. LiteSpeed says versions before 7.9.2 have two stored cross-site scripting bugs, CVE-2026-113499 and CVE-2026-113500, and WPScan rates both 7.5 (high). The plugin has more than 7 million active installs, but not every site is exposed. LiteSpeed says a site is affected only if it publishes comments from visitors who aren't logged in, its theme prints the comment author's name without escaping it, and one of these settings is on:

• CVE-2026-113499: CDN > Other Static CDN with Use CDN Mapping on, a CDN URL set, and Include Images on.
• CVE-2026-113500: Page Optimization > CSS Settings > Font Display Optimization set to Swap.

If all of that lines up, an attacker's script runs in the browser of anyone who views the page. If that visitor is a logged-in admin, it runs with the admin's permissions. That's the same foothold behind the backdoor I added to my WordPress audit post. The same release fixes a third, minor bug, CVE-2026-113501, that lets a Subscriber dismiss the plugin's pinned admin warnings. If you can't update right away, LiteSpeed says to turn on comment moderation. After updating, I'd purge the page cache so nothing built by the old version is still being served.

Product Filter for WooCommerce by WBW: update to 3.4.7 or later. Versions through 3.4.6 have a blind SQL injection, CVE-2026-112866, that needs no login. Patchstack rates it 9.3, and the CVE record marks the impact on confidentiality as high, so the worry is someone reading your database. The plugin has more than 50,000 active installs. The 3.4.7 changelog lists a fixed SQL injection in product filters and a fixed unauthenticated information disclosure. I haven't seen a report of attacks yet, but Patchstack expects this one to be exploited. On a store, that database holds your customers and orders.

wp plugin list --skip-plugins --skip-themes | grep -E 'litespeed-cache|woo-product-filter'
wp plugin update litespeed-cache woo-product-filter --skip-plugins --skip-themes

Python: update to 3.15.2, 3.14.10, 3.13.18, 3.12.16 or 3.11.18. Python shipped expedited security releases for 3.11 through 3.15. The main fix, CVE-2026-115557, makes the ssl module reject the compromised eMudhra intermediate CA keys, whatever your SSL settings say. The Node.js release below also updated its CA store after an eMudhra intermediate CA was compromised. The Python Software Foundation, which assigned the CVE, rates it 9.4 (critical). Python says that on the new releases, normal pip use, including upgrading pip itself, is safe from attacks that use those keys, even before pip is updated.

The same releases fix CVE-2026-114583, which the PSF rates 6.9 (medium). A crafted tar archive could slip past tarfile's filter="tar" setting with tricky link entries and write files outside the folder you're extracting into. If your code unpacks tar files that other people upload, that one's for you.

Only 3.15.2 and 3.14.10 come with Windows and macOS installers. 3.13.18, 3.12.16 and 3.11.18 are source-only, so on those lines you'll get the fix through your Linux distribution, your Docker base image or a tool like pyenv, once they pick it up. Same rule as PHP2Shell and the Brotli fix: check the version where the code actually runs, not just on your laptop.

python3 --version
docker run --rm your-image python3 --version   # inside the image you deploy

On a Linux server, update with apt or dnf once your distribution ships its fix. Distributions often backport the patch without changing the version number, so check their security notice, not just the number. For Docker, rebuild on the newest official python image for your line and redeploy. On Windows or a Mac with the python.org installer, install 3.15.2 or 3.14.10.