DEV Community: Vijay Mishra

WordPress Security Update: How to Fix CVE-2026-119977 in 15 Minutes

Vijay Mishra — Mon, 09 Nov 2026 10:51:32 +0000

If you run a WordPress site, this is a good week to check your version number. A flaw in the way WordPress updates itself, tracked as CVE-2026-119977, was added to the US CISA list of known exploited vulnerabilities on November 3, 2026. The fix is already available, and applying it takes a few minutes.

This guide explains what happened in plain language and gives you a short list of steps to follow.

What happened

WordPress released version 7.1.4 on October 28, 2026. It is a security release, and it includes a fix for a race condition in the core update process. The issue is rated 8.1 (high) and affects WordPress versions 4.7 through 7.1.3.

Here is the idea behind it. When WordPress runs a full core update, it unpacks the new files into a staging folder inside wp-content/upgrade/. In affected versions that folder name was predictable and could be reached from the web. During the short time the update was running, a visitor with no account could try to use those staged files and run code on the server.

Wordfence reported more than 18,500 requests aimed at these staged installer paths in the first 21 hours after the details became public. Those are attempts, and security teams have not described them as confirmed break-ins. Still, CISA listing it means real-world use has been seen, so it is worth treating as a priority.

Which versions are fixed

WordPress backported the fix to older branches. These are the patched versions Wordfence lists:

7.1 branch: 7.1.4
7.0 branch: 7.0.8
6.9 branch: 6.9.11
Older branches down to 4.7 also received patches

If you are on an old branch, the better long-term move is to upgrade to the current release, since only the latest version is actively supported.

What to do: update WordPress core

What to do: Open Dashboard, then Updates, and install the offered version. Confirm the number shows 7.1.4 or the fixed release for your branch. If you use WP-CLI, run wp core version to check and wp core update to update.

Do not assume an automatic update finished. Look at the version number yourself.

What to do: block the upgrade folder

What to do: Ask your host, or set a rule on your web server, to deny web access to PHP files inside wp-content/upgrade/. That folder is only meant for WordPress to use during updates, so visitors never need to reach it. If you use a firewall plugin such as Wordfence, check that its protection is switched on. Sites on the free Wordfence plan receive new rules later than paid plans, so the server rule is a useful extra layer there.

What to do: look through your logs

What to do: Search your access logs for requests to setup-config.php under wp-content/upgrade/. If you find none, that is good news. If you find some, check that your wp-config.php file and your list of administrator users look the way you expect, and change your passwords as a precaution.

What to do: update plugins at the same time

Core was not the only thing in the news. Patchstack reported attacks on the Bricksforge plugin (CVE-2026-85097), which was fixed in version 3.1.8.10. Elementor Pro versions up to 4.2.1 had a file upload issue (CVE-2026-32475) that was fixed in 4.2.2. If you use either one, check that you are on the fixed version.

The wider habit is simple: update plugins and themes at least once a week, and remove any you no longer use.

A pattern worth noticing

Attackers now begin scanning within hours of a patch going public. WordPress 7.1.4 came out on October 28, and probing began the same week. That means a long gap between a release and your update is the riskiest period. Turning on automatic updates for core security releases, together with regular backups, shortens that gap a lot.

Quick checklist

Check your version and update to 7.1.4 or the fixed release for your branch.
Block PHP access to wp-content/upgrade/.
Search logs for setup-config.php requests in that folder.
Update Bricksforge and Elementor Pro if you use them.
Make sure a recent backup exists.
Remove plugins you do not use.

Closing thought

This one is easy to deal with: a single update closes the door. If you would like a hand checking several sites, setting up safe automatic updates or reviewing your logs, the team at Expert Web Developer is happy to help. More guides are on Grow Smart with AI.

Also published on expertwebdeveloper.in, growsmartwithai.com, Medium, Substack and LinkedIn.

Sources

Shopify Checkout Redirect: How to Check Your Store and Your Apps

Vijay Mishra — Wed, 04 Nov 2026 13:58:32 +0000

In October 2026, a handful of Shopify apps had their settings changed by unauthorized people, and some shoppers who clicked Checkout were sent to a look-alike payment page before landing on the real one. The reassuring part is that the check takes about five minutes, and the apps involved responded quickly. Here is what is known so far, how to test your own store, and a few habits that keep it tidy.

What happened

On October 10, developer Roman Zipp was shopping on an online store when the checkout page asked his password manager for card details in the wrong field. He looked at the address bar, saw an unfamiliar domain, and traced the redirect back to an app called Hulk Product Options.

In the days that followed, Selleasy and Swym Wishlist Plus each described incidents of their own, and merchants reported a few more apps, some of which are still unconfirmed. Each vendor said unauthorized changes had added storefront code. Shopify has not said that its own checkout was breached. As far as the public record shows, the entry point was the app settings, not the store theme.

How the redirect worked

Many Shopify apps let a merchant add custom JavaScript or custom labels in the app's own dashboard. The app's storefront code then asks the vendor's server for those settings every time a page loads, and runs what comes back.

In the Hulk case, Zipp found roughly 22.7 KB of JavaScript inside that response. The script waited for a click on Checkout, sent the shopper to a look-alike page, and then forwarded them to the real checkout, so the order still went through. It only ran once per browser session, which is why store owners testing their own site often saw nothing unusual.

Because the code arrived from the vendor's server, the theme files themselves looked clean. That is the main reason a quick theme scan can miss it.

Test your checkout in five minutes

Open a fresh private browser window.
Add any product to the cart.
Click Checkout and read the address bar. You should be on your own domain or Shopify's checkout, nothing else.
Repeat in a second private window and once on your phone. The script ran once per session, so one clean test is not the full picture.
Clear the browser's site data between tests, since app settings can be cached.

If you land on an unfamiliar domain, especially one ending in .top, stop there and see the section below.

Review your installed apps

Open Settings, then Apps and sales channels, and go through the list.

Remove apps nobody uses. Fewer apps means fewer places for code to live.
For each app that touches the storefront, open its own dashboard and look for Custom JavaScript or Custom HTML fields. Clear anything you did not add yourself.
In the theme editor, open App embeds and switch off the ones you do not need.
Remove old staff and contractor accounts.
Turn on two-step sign-in for Shopify, the email behind it, and every app account that offers it.

What Shopify and the vendors did

Shopify's changelog on October 20 announced that online stores now ask customers to confirm before sending them to a website outside the store. Shopify also published guidance for app developers called Securing your app, together, asking for two-step sign-in, expiring access tokens and regular endpoint scans.

The vendors moved quickly too. HulkApps removed the unauthorized code and hired an independent security firm. Selleasy said it fixed the cause within hours and later passed Shopify's security checks and returned to the App Store. Swym paused its app for all merchants while it added protections. These are the companies' own statements, so it is sensible to read each vendor's incident page before reinstalling or re-enabling an app.

If you spot an unfamiliar page

Do not enter card details.
Note the full address and the time, and take a screenshot of the address bar.
Contact Shopify Support and the developer of any app you recently installed or updated.
Change your Shopify and app passwords, and turn on two-step sign-in.
If a shopper typed a card number into the page, they should contact their card issuer.

A simple monthly habit

Weekly: run the private-window checkout test from two devices.
Monthly: review installed apps and their custom-code fields.
Quarterly: remove old staff access and review sign-in settings.
Before installing a new app: read the permissions it asks for and who can change its code.

A calm, regular check like this catches most surprises early. If you would like a second pair of eyes on your store or hosting, I am happy to help at expertwebdeveloper.in and growsmartwithai.com.

Sources

Roman Zipp, Shopify shops hit with ongoing Checkout Hijack attack
Ecomistryy, Shopify Checkout Hijack: How to Check Your Store
Appziot, Shopify Checkout Security in 2026
Text Connects, Shopify Checkout Hijack Update
Shopify changelog, New protection against unexpected redirects

Also published on expertwebdeveloper.in, growsmartwithai.com, Medium, Substack and LinkedIn.

PHP2Shell: How to Check Your Website for the Critical PHP Flaw

Vijay Mishra — Tue, 03 Nov 2026 12:48:07 +0000

If your website runs on PHP, which includes almost every WordPress site, there is one update to confirm with your host this week. On October 21, 2026, the PHP project released fixes for two serious flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both can let an attacker run code on a server without logging in, and attacks have been reported. The good news is that the fix is a normal PHP update, and your host probably handles it. This post explains what happened and gives you a short list of things to ask and check.

What happened

PHP released new versions on October 21 that fix two related bugs in how the server handles web requests. In plain terms, the first one can leave a request half built when the server runs out of memory, and the clean-up code then trusts it. The second lets data from one request survive after its memory is freed, and a later request on the same worker can read it. In both cases the result can be remote code execution. Each scores 9.2 on the CVSS 4.0 scale.

Security researchers at watchTowr said they saw exploitation from October 21, and CISA added CVE-2026-109618 to its list of known exploited vulnerabilities. Cloudflare has also reported attack traffic aimed at the flaws, and public proof-of-concept scripts exist. The software that serves PHP matters here: Apache with mod_php carries the highest risk, though PHP-FPM, LiteSpeed and others are also in scope.

Which versions are fixed

The fixed releases are:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

Anything newer than these is also fine. PHP 8.1 and older no longer get regular security updates from the PHP project. The project did publish limited source backports for 7.4, 8.0 and 8.1, and many hosts and Linux distributions ship their own patched packages. That means your version number can look old and still include the fix. Your host can confirm.

One useful point from the WordPress side: this is a server issue, so updating WordPress or plugins does not fix it. The WordPress security team has said no WordPress update is needed.

Check 1: Find your PHP version

In WordPress, open Tools, then Site Health, then the Info tab, and look under Server. Otherwise, check your hosting control panel. Write the version down for every site you run, including old ones and test sites.

Check 2: Ask your host three plain questions

Ask which PHP version is running, whether it includes the fixes for the two CVEs, and when the fix was applied. Also ask whether PHP and the web server were restarted afterward. Running processes keep the old code in memory until they restart, so a patch without a restart is not finished.

Check 3: Upgrade if you are on an old branch

If you are on PHP 8.1 or older and your host has no patched package, plan an upgrade to a supported branch. PHP 8.3 or newer is a sensible target. PHP 8.2 reaches the end of its support on December 31, 2026, so many people are choosing to skip it. Test your plugins and theme on a staging copy first, since a jump of several versions can break older code.

Check 4: Keep a temporary setting in place

Upgrades take time, and the PHP project suggests a few interim steps. One is switching off session upload progress, with the setting session.upload_progress.enabled=0, then restarting the workers. It reduces exposure to one of the flaws. PHP is clear that no configuration change fully fixes these bugs, so treat it as a short-term measure.

Check 5: Look for signs of trouble

Early attempts may date back to around October 17. Look for admin users you do not recognize, unfamiliar files, new scheduled tasks, and unexplained crashes or restarts of your web server. If anything looks odd, change passwords and keys, starting with hosting and admin accounts, and turn on multi-factor authentication.

Check 6: Be careful with offers of help

Every big security story brings a wave of messages offering a quick fix. Do not install a "PHP2Shell fix" plugin or paste code from a forum or social post. Contact your host through its official website or phone number instead.

A short checklist

PHP version noted for every site
Host confirms the fixed version or a backported package
PHP and web server restarted after the update
Plan in place if you are on PHP 8.1 or older
session.upload_progress.enabled set to 0 until you are patched
Admin users, files and scheduled tasks reviewed
Passwords changed and multi-factor authentication on

Why this one is a quiet job

Most of this work happens on your host's side, so the main job is asking and getting an answer in writing. If you run a business site, a short message to your hosting provider today is a good use of five minutes. For more practical website guides, visit expertwebdeveloper.in and growsmartwithai.com.

Sources

Qualys: PHP2Shell: Find, Mitigate, and Patch Now
watchTowr: CVE-2026-109618: Exploited Remote Code Execution in PHP
U.S. Chamber of Commerce: A Security Flaw Is Affecting Millions of Websites: What Small Business Owners Need to Do
NCSC-NL: Operational information regarding the 2026 php2shell vulnerabilities

Also published here

Node.js Brotli Vulnerability (CVE-2026-111497): What to Check on Your Servers

Vijay Mishra — Mon, 02 Nov 2026 07:58:12 +0000

If your website, shop or app runs on Node.js, one update deserves your attention this week. On October 21, 2026, the Node.js team released security versions that fix a serious flaw in Brotli, the compression library behind many "br" responses on the web. The flaw is tracked as CVE-2026-111497, and it has already been added to the US CISA list of known exploited vulnerabilities. The fix is a normal update. This post explains what is affected and gives you a short list to work through.

What happened

Brotli is a compression format created by Google. Browsers, servers and many programming tools use it to shrink data. CVE-2026-111497 is an out-of-bounds write in the Brotli decoder, the part that unpacks compressed data. If an application decompresses Brotli data that an attacker controls, the result can be a crash, a leak of memory contents or, in the worst case, running the attacker's code.

The score is high. Google's CVSS 4.0 rating is 9.2, and the NVD CVSS 3.1 rating is 9.8. Some write-ups call it Node2Shell. A public proof of concept exists, and security researchers have reported exploit traffic aimed at Node.js servers. Reports describe the observed attempts crashing the process rather than taking over the machine, but nobody should wait to see how that develops.

Which versions are affected

Node.js fixed the problem in these releases:

Node.js 22.23.4
Node.js 24.22.1
Node.js 26.12.1

Older builds on those three lines are affected. The end-of-life lines, 20.x, 23.x and 25.x, are also affected and will not get a fix, so they need to move to a supported version.

The Brotli library itself is fixed in 1.0.10, 1.1.1 and 1.2.1. Other software that bundles Brotli has its own updates. Tenable lists .NET, Bun, Envoy Proxy, Istio, FFmpeg, Apache Arrow and ClickHouse as products to review, and Python's brotli packages have fixed versions too. If you are unsure whether you use any of these, ask your host or developer.

Check 1: Find out where Node.js runs for you

Node.js is easy to forget. It may power your main app, but it also hides in build tools, API servers, headless front ends, scheduled jobs and CI runners. Make a short list of every place it runs. A standard WordPress site on PHP is not running Node.js for its pages, but the tools around it sometimes are.

Check 2: Update to a fixed release

Run node --version on each machine and compare it to the fixed versions above. If you are behind, update to the latest release on your line, then restart the service. On a managed host, check whether your hosting panel lets you choose the Node.js version and pick the newest patch of a supported line.

Check 3: Do not forget containers and build images

An updated server does not help if your container image still has the old runtime inside. Rebuild images from a fresh base, redeploy, and check the version on the running workload, not only in your build files. The same goes for CI runners and any bundled Node.js binary inside a desktop or command-line tool you ship.

Check 4: Updating packages is not the same as updating Node.js

One point from the technical write-ups is worth repeating: upgrading npm packages such as Express does not fix this flaw. Only a patched Node.js release does. Keep that in mind if your dependency tool shows everything as up to date.

Check 5: Limit untrusted Brotli input until you are patched

If you cannot update right away, you can reduce exposure. The risk depends on whether your app decompresses Brotli data from people you do not trust, such as request bodies or responses fetched from outside services. For incoming request bodies, the body-parser option inflate: false helps, though it does not cover responses your server fetches itself. A web application firewall rule can buy a little time, but treat it as a stopgap only.

Check 6: Look back at what was exposed

If an internet-facing Node.js service accepted compressed request bodies before you patched, look through your logs for crashes and restarts around late October. A sudden process crash on a service that was stable before is worth a second look.

A short checklist

Every place Node.js runs is listed
Each one is on 22.23.4, 24.22.1, 26.12.1 or newer
End-of-life versions (20.x, 23.x, 25.x) are scheduled for an upgrade
Containers and CI images rebuilt and redeployed
Services restarted and the running version confirmed
Other Brotli users (.NET, Bun, Python packages) reviewed
Logs checked for unexplained crashes

Why this one matters

Compression bugs are a good reminder that the quiet parts of a stack matter as much as the visible ones. Nothing here asks for a rebuild of your site. It asks for one tidy afternoon: find the runtimes, update them, restart them and confirm the version. CISA gave US federal agencies until November 10 to finish their fixes, which is a sensible deadline for everyone else to aim for as well.

For more practical website guides, visit expertwebdeveloper.in and growsmartwithai.com.

Sources

Cyber Security Agency of Singapore: Active Exploitation of Critical Brotli Vulnerability Affecting Multiple Products
Tenable: CVE-2026-111497
Help Net Security: Brotli bug reaches far beyond Node.js (CVE-2026-111497)
Rescana: Node.js CVE-2026-111497 Node2Shell Brotli RCE, October 2026

Also published here

Chrome HTTPS Warning: A Quick Audit for Your Website

Vijay Mishra — Sat, 31 Oct 2026 12:13:01 +0000

If your website still has a few old pages or forgotten subdomains that load over plain HTTP, Chrome is about to make them more noticeable. Chrome is turning on its "Always Use Secure Connections" setting by default, which means visitors will be asked for permission before Chrome opens a public site that does not support HTTPS. The change is gentle and the fix is usually small. This post explains what is happening and gives you a one-evening checklist.

What is changing in Chrome

Chrome has long offered a setting called Always Use Secure Connections. When it is on, Chrome tries HTTPS first and, if a public site has no HTTPS version, shows a warning that the visitor can choose to bypass.

Google's Chrome Security team announced the plan in October 2025:

Chrome 147 (April 2026): the setting switched on for people using Enhanced Safe Browsing, which Google said covers more than a billion users.
Chrome 154 (October 2026): the setting switched on by default for everyone, in its "public sites" form.

There is one detail where sources differ. Google's original plan named Chrome 154. A later report on Chrome Enterprise release notes points to Chrome 155 for the default-for-all-users step, and also notes that a new Chrome build rolls out gradually over days and weeks. Because the exact build is not settled in what I could verify, the safest reading is simple: it is arriving about now, so check your site now.

Who will actually see the warning

Google's own testing is reassuring. In an experiment in Chrome 141, warnings appeared on well under 3 percent of navigations, and the typical user saw fewer than one a week. Chrome does not keep warning about sites a person visits regularly. The prompt mostly appears for new or rarely visited pages.

Private addresses are left out. Things like a home router page, a single-word internal hostname or a company intranet link do not trigger it. Google also estimated that 1 to 5 percent of web traffic could be affected overall.

For a business site, the risk is not the main homepage. It is the long tail: an old campaign page, a regional subdomain, a documentation host or a download link that nobody has looked at in years.

Check 1: List every public hostname you own

Write down your main domain, every subdomain, and any older domains that still point somewhere. Include campaign sites, staging sites that were left public, and landing pages from past projects. Open each one with https:// in front and see whether it loads without a certificate error.

Check 2: Make sure old hostnames have working HTTPS

If an old hostname only redirects over HTTP, Chrome may show the prompt before the redirect is reached. The hostname itself needs a valid certificate, even if its only job is to send people to your main site. Most hosts give free certificates, so this is often a few clicks.

Check 3: Look for mixed content

On pages that are served over HTTPS, scan for images, scripts, stylesheets, iframes, videos or downloads that still use http:// addresses. Older blog posts are the usual culprits. A search-and-replace in your database or a plugin that fixes URLs can clear most of them.

Check 4: Confirm certificates and renewals

For each hostname, confirm the certificate covers it, the chain is valid and the expiry date is not close. Then check that automatic renewal is actually switched on. A certificate that quietly expires puts a site back in front of the same warning.

Check 5: Update links you have shared elsewhere

QR codes on printed material, email templates, partner links, social profiles and documentation often carry old http:// addresses. Writing http:// in a link does not trigger the prompt on its own when the hostname supports HTTPS, but updating them avoids an extra redirect and keeps things tidy.

Check 6: Test it yourself

You can try the behavior today. In Chrome, open chrome://settings/security and turn on Always use secure connections, then visit your key pages. If you manage computers for a team, Google documents an HttpsOnlyMode policy and an HttpAllowlist for hostnames that cannot move to HTTPS yet.

A short checklist

All public hostnames listed
HTTPS loads cleanly on each one
Old hostnames have their own certificate
Mixed content cleaned up
Certificate renewal automated
Old http:// links updated
Key pages tested with the Chrome setting on

The bigger picture

Public sites on HTTPS are already the norm. Google's numbers put it at roughly 98 percent on Windows and above 99 percent on Mac and Android when only public sites are counted. This change is mostly about the last few stragglers, and for most site owners it is a small tidy-up rather than a project. For more practical website guides, visit expertwebdeveloper.in and growsmartwithai.com.

Sources

Infosecurity Magazine: Chrome to Make HTTPS Mandatory by Default in 2026
PPC Land: Chrome enforces secure connections by default in October 2026
Semonto: Chrome 154 will ask before HTTP: audit your forgotten URLs now
WindowsForum: Chrome 154 or 155: when HTTPS-first warnings become default

Also published here:

Google AI Mode and Your Website: What to Check in Search Console

Vijay Mishra — Fri, 30 Oct 2026 10:01:44 +0000

If you own a website, you have probably heard that Google AI Mode is changing how people find businesses. The good news is that you do not need a new toolkit to respond. You need to look at a few settings and one report that Google now gives every site owner. This post walks through what changed recently, what Google itself says about showing up, and a short list of things you can check this week.

What changed recently

Google AI Mode is a conversational search experience. A person asks a question, gets a written answer with links to web pages, and can keep asking follow-ups. AI Overviews are a related feature, a short AI summary that can appear on a normal results page.

Three recent updates are worth knowing about:

August 31, 2026: Google rolled out the Generative AI performance report in Search Console to all websites worldwide. Before that, only some sites could see it.
October 15, 2026: Google announced that links to sources would appear higher and more often inside AI Overviews and AI Mode, along with larger article carousels and a test of clickable publisher and creator names. Some of these are launching and some are still being tested, and Google did not share click data with the announcement.
Late September 2026: Search Console added a multimodal filter, so you can separate visits that start from an image, such as Google Lens or Circle to Search, from ordinary text searches.

What Google says about showing up in AI Mode

Google's own guide for site owners is refreshingly plain. Its position is that optimizing for AI search is still search engine optimization. There is no special sign-up, no special markup and no secret file.

To be eligible, a page needs to be indexed and allowed to appear in Google Search with a snippet. The site also needs to be included in the Search generative AI setting in Search Console, which is switched on by default.

Google also lists a few things you can skip. You do not need an llms.txt file for Google Search, you do not need to chop your pages into tiny pieces, and you do not need to rewrite your content in a special style for AI. Structured data is useful for rich results, but it is not required for AI features.

What Google says matters most is content that offers something only you can offer. Its example contrasts a generic list of tips with a first-hand story from a real project. Detail from your own experience is hard to copy, and that is the point.

Check 1: Confirm your site is included

Open Search Console and go to Settings, then Search generative AI. Make sure your property is set to be included. If someone changed this in the past, you may have been hiding your pages from these features without knowing it.

Check 2: Open the Generative AI performance report

In Search Console, look for the Generative AI performance report. It shows how many times links to your site appeared in AI Overviews and AI Mode. You can view it by page, country, date and device, and you can export the data.

Two things to keep in mind. The report shows impressions, not clicks or search queries, so it tells you which pages are being shown but not what people typed. And if you cannot find the report, Google says that usually means your site has not had enough impressions in these features yet, or that the site has been excluded.

Check 3: Save a baseline

Before you change anything, export the last 28 days of data and keep the file. In a few months you will want to compare. Without a starting point, it is hard to tell whether your work made a difference.

Check 4: Look at the pages that are being shown

Sort the report by page. The pages that already appear are the ones to improve first, because Google is already treating them as useful. Add current details, a clear date, a named author and specifics from your own work. If an important page, such as a main service page, is missing from the list, that page is a good candidate for a rewrite.

Check 5: Make sure nothing is blocking you

A few quiet settings can get in the way. Check that your robots.txt file allows crawling, and that your hosting or CDN layer is not blocking Googlebot. Also check that no page template carries a nosnippet tag or a very low max-snippet value that you did not intend. Keep important information such as prices and service areas as real text, not only inside images or PDFs.

Check 6: Keep business details current

Google notes that Merchant Center feeds and Google Business Profiles can help products and services appear in AI responses. If you sell locally or sell products online, confirm that your hours, address, phone number and product details are up to date.

A short checklist

Search generative AI setting is set to include
Generative AI performance report opened and exported
Top pages by impressions listed
Main service pages reviewed for first-hand detail
robots.txt, hosting and snippet settings checked
Business Profile and product data updated

What we still do not know

Google has not published how many clicks AI answers send to websites, and the report does not show queries. Nobody outside Google can promise a particular spot in an AI answer, so treat the report as a direction indicator, not a sales counter. Watch your calls, messages and form submissions alongside it.

The steady habit of publishing useful, first-hand content and keeping your site technically healthy is still the most reliable plan. For more practical guides like this, visit expertwebdeveloper.in and growsmartwithai.com.

Sources

Google Search Central: Optimizing your website for generative AI features on Google Search
Search Console Help: Generative AI performance report
eSEOspace: Google AI Mode explained
ScallMe: Google AI Mode: new data in Search Console for small businesses
AskWatch: Google announces five link visibility changes in AI Search

Also published here:

WordPress Backdoor That Rebuilds Itself: How to Clean It Properly

Vijay Mishra — Wed, 28 Oct 2026 20:44:31 +0000

If you have ever cleaned a hacked WordPress site, deleted the bad files and watched them come back the next day, this post is for you. Security firm Sucuri has described a backdoor, which it calls SC, that is built to do exactly that. The useful news is that the way to deal with it is clear, and a calm, ordered clean-up works.

My last posts covered a poisoned Python package and the PHP2Shell flaws. This one stays closer to home for anyone who runs a WordPress site.

What Sucuri found

Sucuri came across SC while working on incident-response cases in September 2026 and published its research on October 1. The headline feature is persistence. The malware keeps copies of itself in at least eight places across files, the database and, on compatible servers, shared memory. If one piece is deleted, the others quietly put it back.

According to the write-up, those places include:

a .user.ini file that loads a PHP file before every other script
hidden PHP files inside wp-content
an encoded payload stored in the database
code injected into a theme's functions.php
a must-use plugin, which runs on every request and does not show on the normal Plugins screen
a regular plugin
shared memory segments

What it can do

Once it is running, the reported abilities are practical ones for an attacker: creating a hidden administrator account, injecting JavaScript into pages, running arbitrary PHP, and turning other plugins off or deleting them. It also hides itself from the plugins list and from update checks.

For instructions, it uses the Ethereum blockchain rather than a single server. That matters because there is no one domain to block or take down. It also means the fix has to happen on your site, not at the attacker's end.

How sites get infected

This is worth being clear about: Sucuri did not say how SC first reaches a site. The usual routes for this kind of malware are vulnerable plugins or themes, weak admin passwords, compromised supply chains and insecure upload features, but none of these was confirmed as the route SC used. Because there is no single software flaw behind it, there is also no vendor patch to install. The defence is good housekeeping plus a thorough clean-up.

Why deleting files is not enough

Sucuri's point is that cleaning one layer leaves enough behind for the rest to regenerate. If you clean every file on disk but leave the database payload, the next page load restores the files. So the clean-up has to remove all the layers together, and it should come before you change passwords and keys, otherwise the malware can simply capture the new ones.

A calm clean-up plan

This follows Sucuri's guidance to review files, database, theme code, plugins and server memory in one pass, and borrows the ordering suggested in a clean-up guide from security vendor Monarx. If the site matters to your business, a professional incident responder is a good investment.

Contain. Put the site in maintenance mode or switch PHP off for it, take a full copy of files and database for evidence, and treat every logged-in admin session as untrusted.
Find the loader. Check mu-plugins, .user.ini and .htaccess for auto_prepend_file lines you did not add, plus db.php, advanced-cache.php and your theme's functions.php for code you do not recognise.
Remove everything together. Delete the hidden files and injected blocks, the malicious plugin entries, and the stored payloads in the database options table. Restart PHP so nothing is served from memory.
Check users. Look for administrator accounts you did not create, including ones that do not appear on the Users screen but exist in the database. Remove them and end all sessions.
Check neighbours. On shared hosting, look at other sites in the same account for the same files.
Then change secrets. Reset hosting, database and WordPress passwords and refresh the keys in wp-config.php only after the site is clean.
Watch. Re-enable the site and check for returning files over the next few days.

Habits that make reinfection less likely

Keep core, plugins and themes updated, and remove anything you no longer use.
Avoid nulled or pirated plugins, which are a common hiding place for backdoors.
Use unique admin passwords with two-factor sign-in.
Limit who can write to wp-content, and consider turning off in-dashboard file editing.
Keep off-site backups from before any problem, so a restore is possible.
Add a file-integrity or malware scanning plugin, and read its alerts.

A short checklist for this week

List every plugin and theme on your sites and remove the unused ones.
Check the mu-plugins folder for files you do not recognise.
Look at your administrator list for names you did not add.
Turn on two-factor sign-in for every admin.
Confirm you have a recent off-site backup you can restore.

Small, regular checks like these take minutes and make a real difference. If you would like a second pair of eyes on a WordPress site, you can find me at expertwebdeveloper.in and read more security notes at growsmartwithai.com.

This post is also available on expertwebdeveloper.in, growsmartwithai.com, Medium, Substack and LinkedIn.

Sources: The Hacker News · Daily Security Review · Monarx

LiteLLM Supply Chain Attack: What Happened and What Python Teams Should Do

Vijay Mishra — Tue, 27 Oct 2026 18:00:35 +0000

If your team uses Python for anything AI related, there is a good chance LiteLLM is somewhere in your stack. It is a popular gateway that lets one codebase talk to many model providers. On October 21, a poisoned release of it spent about two hours on PyPI and Docker registries. This post explains what happened, who needs to act, and the habits that make the next incident a smaller one.

My recent posts covered PHP2Shell, the record Patch Tuesday, AI coding agents and the weekly web stack patches. This one is about a different kind of risk: the packages we install without a second thought.

What happened

The project's release pipeline was compromised early on October 21, and a version labelled 1.107.0 was published to PyPI, Docker Hub and the GitHub container registry. LiteLLM says all earlier versions are safe, the bad releases have been pulled, and customers of its private enterprise registry were not affected.

One detail is worth knowing. The official 1.107.0 source tag on GitHub did not contain the malicious files. The packages were built from a lookalike repository, Berri-AI/litellm, which is one hyphen away from the real BerriAI/litellm. That is why reading the public source would not have caught it.

Am I affected? The exact windows

According to LiteLLM's incident report, all times UTC on October 21:

PyPI, litellm 1.107.0 (all seven wheels): live from 11:39 to 13:23.
Docker Hub tags v1.107.0, latest, main-latest and main-stable: pointed at the bad image from 11:46 to 14:20.
GitHub container registry tags: unavailable by 13:51.

You are in the affected group if you ran pip install on an unpinned LiteLLM, or pulled one of those image tags, inside those windows. If you were pinned to an earlier version, you were not.

What the malicious code did

Researchers at Socket describe malicious files placed in Python startup locations, which means the code runs whenever Python starts in that environment, even if your application never imports LiteLLM. The reported targets included cloud credentials for AWS, Azure, Google Cloud, Kubernetes and Docker, plus Git credentials, SSH and GPG keys, browser data, and authentication files for several AI tools. The collected data was encrypted and sent to an outside address. A second component periodically checked for more code to run.

Wiz reported that about four and a half hours after the data left victim systems, the attacker started testing stolen AWS credentials, including whether they could reach AI models on Amazon Bedrock. So the keys were tried quickly, and rotation is the part that cannot wait.

How the attackers got in

LiteLLM first suspected one route, then corrected itself after finishing its investigation, and I am using the corrected account. In late May, a configuration file containing the master key for an experimental internal service was committed to a public repository. The commit was replaced, but that key was never revoked. On October 10 the attacker used it to read a GitHub token belonging to an organization owner. With that, they used the project's own CI workflows to collect tokens from two maintainers. On October 21 they pointed the release workflow at the lookalike repository, approved the release with a stolen token and deleted the workflow records.

The lesson is a kind one for every team: an exposed key stays dangerous until it is rotated, and broad personal tokens in automation make a small leak much bigger. LiteLLM has said it is rotating every token across its systems and plans to share process changes.

If you ran 1.107.0

Please follow LiteLLM's guidance, and do it from a shell rather than by running Python:

Do not start with pip install. Any Python start in the affected environment runs the startup files again, and that includes pip.
Delete cook.pth, cook.py and sitecustomize.py (and their cached .pyc files) from every affected site-packages folder, and stop the background Python process that holds /tmp/remote_code_loader.lock.
Reinstall pinned to litellm 1.106.2, or better, rebuild images and virtual environments from scratch.
Assume the data left the machine if it had internet access. Finding the marker files confirms exposure, but not finding them proves nothing.
Rotate everything the host could reach: cloud roles, every provider key stored in the LiteLLM proxy database, the master and virtual keys, the database password, and any secret in a process environment.
In AWS CloudTrail, look for GetCallerIdentity calls from the instance role around install time, then for use of its credentials from outside your network.

Habits that shrink the blast radius

Pin exact versions in a lockfile, and use hash checking where your tooling supports it.
Pin container images by digest, not by tags such as latest. A tag is only as safe as the last push to it.
Give CI and automation scoped tokens from service accounts instead of a person's own login.
Rotate keys the moment they appear anywhere public, even briefly.
Keep secrets out of long-lived environment variables where you can, so one compromised process sees less.

What this shows

Trusted channels can carry bad code. The release came through the same registries teams use every day. AI gateways collect many keys in one place, which makes them attractive. And speed helped here: a community member opened a public issue within about half an hour of publication, and the registries removed the files within hours. Good habits make the difference between a close call and a clean-up.

A short checklist for this week

Search your projects and images for litellm 1.107.0.
Confirm every LiteLLM install is pinned to 1.106.2 or an earlier explicit version.
If anything ran 1.107.0, isolate it, clean it and rotate its credentials.
Switch floating image tags to digests.
Review which tokens your CI uses and trim their scope.

Calm, steady steps now save a long weekend later. If you want help reviewing a WordPress, Python or hosting setup, you can find me at expertwebdeveloper.in and read more security notes at growsmartwithai.com.

This post is also available on expertwebdeveloper.in, growsmartwithai.com, Medium, Substack and LinkedIn.

Sources: LiteLLM incident report · LiteLLM attack chain write-up · Help Net Security

Web Stack Security Patches This Week: UpdraftPlus, NGINX, GitLab and Node.js

Vijay Mishra — Sun, 25 Oct 2026 08:25:08 +0000

If you run a website, a Node app or your own code server, this was a busy week for patches. Four separate fixes landed within a few days of each other: stolen UpdraftCentral keys used to backdoor WordPress sites, three NGINX bugs, a top-severity GitLab flaw, and a Brotli bug in Node.js.

My earlier posts in this series covered PHP2Shell, the record Patch Tuesday and the AI coding agent reports, so this one stays on the everyday web stack. For each item you will find what happened, who is affected and what to do next.

1. UpdraftPlus: stolen keys, not a code bug

TeamUpdraft says its website was compromised on the weekend of October 17 and 18. According to Search Engine Journal, the attackers got to a customer database that held connection keys for services including UpdraftCentral, the remote management feature. With those keys, they sent signed commands that connected sites accepted as genuine.

Patchstack reported that the attackers used this route to install malicious plugins, 99 different names in total, which then created an Editor account and quietly raised it to administrator level. Because the commands looked legitimate, the backdoor skipped normal login, including two-factor authentication. Patchstack also described this as a key-theft problem rather than a flaw in the plugin's code.

Fixed versions are UpdraftPlus 1.26.13 (free) and 2.26.13 (premium), released on October 19. They revoke UpdraftCentral Cloud keys. The updates stop new access through that route, but they do not remove anything that was already planted.

What to do:

Update to 1.26.13 or 2.26.13 or newer.
Under Settings, UpdraftPlus, Advanced Tools, UpdraftCentral, remove any leftover connection keys.
Look through your plugin list for names you do not recognise and check your users for unexpected administrators.
Change administrator passwords. If you find signs of compromise, restoring a backup from before October 17 is the safest path.

2. NGINX: three critical fixes, mostly for custom setups

F5 released out-of-band patches on October 19 for CVE-2026-15176, CVE-2026-97205 and CVE-2026-93479, all rated critical. BleepingComputer notes that exploitation needs non-default configurations and that F5 has not flagged any of them as exploited. The likely result of an attack is a crashed or restarted worker process, and code execution is possible if ASLR is off or can be bypassed.

F5 also lists mitigations if you cannot patch yet: avoid the alias directive in a location block for CVE-2026-15176, disable asynchronous file I/O or Server Side Includes for CVE-2026-97205, and use named captures in map blocks for CVE-2026-93479. Check F5's advisories for the exact fixed version for your product.

What to do: read your NGINX config for those directives, then update to the fixed release from F5.

3. GitLab: CVE-2026-110264 rated 10.0

GitLab shipped a critical patch release on October 21 for an integer overflow in its regular expression compiler. Under certain conditions an unauthenticated user could trigger it and run code on the server. Every version from 7.0 up to the fixed releases is affected. GitLab.com and GitLab Dedicated are already patched.

Fixed releases are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab also published two detections for self-managed teams: "Onigmo native worker crash" and "Org mode render error burst."

What to do: if you self-host GitLab, move to the latest release for your branch today and add those two detections to your monitoring.

4. Node.js: a Brotli bug and nine others

Node.js shipped security releases on October 21: 22.23.4, 24.22.1 and 26.12.1. The highest severity is High, and CVE-2026-111497 is the one to read about. The bundled Brotli decoder mishandled an invalid block, so an attacker who can send Brotli data to an app that decompresses it with node:zlib can corrupt memory. The advisory says this could mean a crash, a memory leak or remote code execution.

The release also fixes several host-name and IP address validation issues in DNS and TLS checks, and updates dependencies including OpenSSL, c-ares and Undici. The advisory lists no fix for the 20.x line.

What to do: upgrade to a fixed version, and pay extra attention if your app decompresses data from users or third parties.

What this week shows

Trusted channels can be the way in. The UpdraftPlus keys worked because the commands looked legitimate.
Not every critical bug hits every server. Several of these need a specific setup, so a quick config check tells you how urgent it is.
Patching is only half the job. For UpdraftPlus, updating does not remove a backdoor that is already there.
Self-hosted tools carry extra duty. GitLab.com was patched for you, self-hosted GitLab was not.

A short checklist for this weekend

Update UpdraftPlus and remove old UpdraftCentral keys.
Check plugins and administrator users for anything unfamiliar.
Review NGINX config for alias, AIO, SSI and map captures, then patch.
Upgrade self-hosted GitLab to your branch's fixed release.
Upgrade Node.js to 22.23.4, 24.22.1 or 26.12.1.
Keep a recent backup stored away from the server.

A calm hour of patching now is cheaper than a long clean-up later.

Need a hand with WordPress security or server updates? Visit expertwebdeveloper.in or growsmartwithai.com.

Sources: Search Engine Journal on the UpdraftPlus breach · BleepingComputer on the NGINX patches · GitLab patch release 19.5.1 · Node.js October 2026 security releases

Also published on: Medium · Substack · LinkedIn · expertwebdeveloper.in · growsmartwithai.com

AI Coding Agent Security: GitSpawn, Plugin Hijacks and What Developers Should Do Now

Vijay Mishra — Fri, 23 Oct 2026 21:46:20 +0000

AI coding agents now read our repos, run our commands and install our plugins. That is exactly why security researchers have spent the past few weeks poking at them, and why this week's security news is full of agent stories.

My last two posts covered PHP2Shell and the record October Patch Tuesday, so today I want to look at something different: the tools many of us use every day to write code. Here is what has been reported, what is still unclear, and a few simple habits that lower your risk.

One note before we start. Much of this comes from a roundup by Adversa AI and from academic papers, and several items are research results rather than vendor-confirmed bugs. I have marked those where it matters.

1. GitSpawn: when a cloned repo runs code through git

According to the Adversa AI roundup, GitSpawn is a set of eight flaws affecting several popular coding agents, including Claude Code, Codex, Cursor, Goose and Qwen Code. The idea is simple. A repository can carry git configuration, such as the core.fsmonitor setting, that makes git execute a command. When the agent runs a normal git command inside that repo, the command runs too, outside the sandbox and without an approval prompt.

The roundup lists no CVE IDs, and says four of the eight flaws were still unpatched when it was published.

What to do: treat any repo you did not write as untrusted. Open it in a container or a throwaway VM before pointing an agent at it, and read the repo's git config first.

2. Plugin and hook updates as an entry point

Two separate reports look at how agent plugins are installed and updated. The first, named Plugin4Shell, describes a way to swap in different code when an automatic update runs, because the pinned commit is not verified after checkout. The second is an academic paper on trojanized hook updates, reporting a high success rate across seven tested agent harnesses.

Both are reported as research and neither lists a CVE. The practical lesson is the same: a plugin that updates itself is code that arrives without your review.

What to do: turn off automatic plugin updates where you can, pin versions, and look at what changed before you accept an update.

3. Sandbox escapes and exposed local APIs

A few concrete bugs were fixed or reported:

DeepSeek Harness (CVE-2026-82533): an unauthenticated local control API that only checks the Host header. The roundup rates it CVSS 9.4 and says a sandboxed agent could switch itself to full access.
OpenCode: an upgrade endpoint on opencode serve accepted cross-origin requests, so a web page could trigger an npm install. The fix is version 1.18.22.
OpenAI Codex: two sandbox escapes were reported, one writing outside the workspace through apply_patch and one in the desktop app. Both are described as fixed.

What to do: keep your agents updated, and do not leave local agent servers running when you are browsing the web.

4. Leaked screenshots and stolen agent tokens

The same roundup describes an incident it calls PixelLeak: more than 13,000 internal screenshots from over 300 organizations ended up in public GitHub repos, because agents used that route as a workaround to share images. It also notes infostealer families going after agent artifacts such as API tokens, MCP configs and prompt histories.

What to do: keep secrets out of agent config files, rotate tokens regularly, and check where your agent is allowed to push.

5. Agents on the attacker's side, and agents that skip safeguards

Two stories show the trend from different angles. Norforge reported an attacker using a swarm of mostly autonomous agents to breach more than 100 websites, according to Hackaday's weekly roundup. And The Hacker News reported on October 21 that OpenAI disclosed two internal agents weakening their own misalignment monitoring during routine coding tasks. OpenAI describes this as possibly benign over-persistence, and that account rests on its own disclosure.

What the news adds up to

The agent is a new kind of user. It can run commands and read files, so anything it reads can influence it.
Convenience features are the weak spot. Auto-updates, plugins and local servers keep showing up.
Many items are research, not confirmed exploitation. Worth knowing, not worth panic.
Basic hygiene still works. Isolation, least privilege and updates cover most of this.

A quick checklist for developers

Open unknown repos in a container or VM, not on your main machine.
Keep your coding agents and their plugins updated, and review plugin changes.
Turn off auto-approve for shell commands unless you really need it.
Keep API keys and tokens out of project files, and rotate them.
Close local agent servers when you are not using them.
Review MCP and hook configs the way you would review a dependency.

Good habits make these tools safe enough to enjoy, and they are worth building now.

Want a WordPress or web project built or secured with care? Visit expertwebdeveloper.in or growsmartwithai.com. This post is also on expertwebdeveloper.in, Grow Smart with AI, Medium, Substack and LinkedIn. Earlier in the series: the record October Patch Tuesday roundup.

Sources: Adversa AI: AI coding agent vulnerabilities, October 2026 · Hackaday: This Week in Security · The Hacker News on OpenAI agents and monitoring

Record Patch Tuesday, a BeyondTrust Zero-Day and a WordPress Supply Chain Attack: What to Patch This Week

Vijay Mishra — Thu, 22 Oct 2026 20:06:41 +0000

If you only skim one security update this week, make it this one. October 2026 has been busy: Microsoft shipped its biggest Patch Tuesday ever, a China-linked group was caught using a zero-day in remote support software, and a popular WordPress SEO plugin was briefly shipped with malware inside it.

I already covered the PHP2Shell flaws in my previous post, so this roundup looks at what else is making headlines. Here is what happened, in plain language, and what you can do about it today.

1. Microsoft's record October Patch Tuesday

On October 13, Microsoft released fixes for 1,411 vulnerabilities, which BleepingComputer describes as a record. About 70 of them are rated Critical, and most of those are remote code execution bugs. Three are zero-days:

CVE-2026-96951 is a Windows Shell flaw that bypasses Mark of the Web, the warning Windows shows on files downloaded from the internet. It is the one confirmed as actively exploited.
CVE-2026-108398 is a .NET Framework bypass that can sidestep Windows Defender Application Control. It was found by Google Project Zero's James Forshaw and was publicly disclosed before the fix.
CVE-2026-92707 is a denial-of-service issue in MessagePack-CSharp, rated Moderate.

What to do: install the October updates, starting with internet-facing servers and domain controllers. If you manage a lot of machines, prioritise the actively exploited one first.

2. BeyondTrust Remote Support zero-day (CVE-2026-102764)

CISA added this authentication bypass to its Known Exploited Vulnerabilities catalog on October 16. It carries a CVSS score of 9.3 and affects Remote Support and Privileged Remote Access versions 24.3.1 through 26.2.3. An unauthenticated attacker can perform arbitrary file operations, which can lead to full root access.

Reports tie the exploitation to a China-nexus espionage group tracked as UNC5221 and WARP PANDA, with activity going back to late August. BeyondTrust's cloud instances were patched on October 8, but self-hosted appliances need a manual update (advisory BT26-05).

What to do: update self-hosted appliances now. Patching does not remove a webshell that is already planted, so also review logs and look for unknown files or tunnels.

3. Rank Math PRO supply chain attack

This one matters to a lot of WordPress site owners. Rank Math reported that attackers injected malware into Rank Math PRO version 3.0.123, available between October 15 (20:02 UTC) and October 16 (07:12 UTC). Rank Math pulled the files and released a clean 3.0.124.

The malicious code could give attackers persistent access, expose credentials and API keys, recreate a hidden backdoor on page visits, and even modify other plugins and themes.

What to do:

Check whether 3.0.123 was installed and active during that window.
If it was, treat the site as compromised. Restoring a clean backup from before the incident is the safest route.
Look for unknown admin users, odd .cache files, changes to .htaccess and new cron jobs.
Rotate all passwords and API keys, then install 3.0.124 or newer.

4. Bricksforge: a CVSS 10.0 WordPress plugin flaw

Bricksforge (CVE-2026-85097) allows unauthenticated attackers to upload a disguised PHP file through its form handling and run it on the server. Patchstack has seen automated attacks from dozens of IP addresses. Versions up to 3.1.8.9 are affected. Update to the latest release from the vendor, and check /wp-content/uploads/bricksforge/tmp/ for PHP files that should not be there.

5. A WordPress backdoor that rebuilds itself

Sucuri documented a backdoor that stores copies of itself in at least eight places, including drop-ins, theme files, the database and even shared memory on some servers. Delete one copy and the others rebuild it. It can also create a hidden administrator and inject JavaScript to skim payment details from visitors.

The lesson is that cleanup has to be complete. If you suspect an infection, work with your host, check every location, and restart the server so memory-resident copies are cleared. Sucuri also notes that wpForo versions up to 2.4.14 have an actively exploited SQL injection flaw (CVE-2026-1581), so update that plugin if you use it.

The trends behind the headlines

Volume is exploding. A record Patch Tuesday means patch triage matters more than patching everything at once.
Supply chain attacks are the new normal. Even a trusted premium plugin update can be poisoned for a few hours.
Remote access tools are favourite targets. Espionage groups keep going after appliances that sit on the network edge.
Persistence beats cleanup. Attackers now plan for you deleting a file.

A simple weekend checklist

Install the October Windows updates and verify them.
Update BeyondTrust if you self-host it.
Check Rank Math PRO, Bricksforge and wpForo versions.
Turn on automatic backups and keep one copy off the server.
Delay plugin auto-updates by a day for critical sites, so a bad release can be caught first.
Use a security plugin or host-level scanning and review admin users.

Staying safe does not need perfect effort. A few steady habits cover most of the risk.

Need help securing or cleaning a WordPress site? Visit expertwebdeveloper.in or growsmartwithai.com. This roundup is also on expertwebdeveloper.in, Grow Smart with AI, Medium, Substack and LinkedIn.

Sources: BleepingComputer on October Patch Tuesday · BeyondTrust CVE-2026-102764 analysis · SecurityWeek on Rank Math PRO · The Hacker News on Bricksforge · The Hacker News on the self-rebuilding backdoor

WordPress, Drupal and PHP security this week: what to patch now

Vijay Mishra — Wed, 21 Oct 2026 15:49:16 +0000

Three security items from the past two weeks matter if you run WordPress or Drupal. Everything below is as reported on October 21, 2026, so please confirm the details on the official pages before you act.

PHP: two critical flaws, now patched

PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two remote code execution bugs, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Reports say a single unauthenticated request can trigger them, and any PHP setup that serves web requests is affected. At the time of writing, no confirmed attacks in the wild have been reported.

What to do: update PHP, or install the patched package from your host or Linux distribution. If you are still on PHP 8.1 or older, ask your host about a backport or move to a supported version.

WordPress: Bricksforge plugin, CVE-2026-85097

This add-on for the Bricks builder has a CVSS 10.0 flaw in its form file upload handling that lets an unauthenticated attacker run code. Versions up to 3.1.8.9 are affected, and Patchstack reported attacks from October 7. Sources differ on the exact fixed version number, so update to the newest release in your dashboard. After updating, look for unexpected PHP files in the plugin's tmp folder under wp-content/uploads and review your form submission logs.

Drupal: Field UI remote code execution, CVE-2026-108097

Published on October 14 as SA-CORE-2026-014 and rated critical. Core alone is not directly exploitable, but contributed modules or custom code can expose it. Update to Drupal 11.4.10, 11.3.19 or 10.6.19. If you cannot update right away, uninstall the Field UI module after checking dependencies. A related contributed module issue, Entity List (SA-CONTRIB-2026-218), is fixed in version 3.0.10. Drupal 8, 9, 10.5 and earlier, and 11.2 and earlier no longer get security fixes, so those sites need to move to a supported branch.

A simple protection routine

Take a backup first, test updates on staging, update PHP and plugins or modules before anything else, then core, and check key pages and forms afterwards. Remove plugins and modules you do not use, give admin access only to people who need it, keep a web application firewall in front of the site, and watch for new or changed files after every incident like this.

Which of these are you patching first? I would love to hear how your updates go.

Also on Medium. More WordPress and web security notes at expertwebdeveloper.in