October 2026 Security Bugs: What to Patch in PHP, Node.js, Next.js, Go, and eMudhra

By Developer Muhammad, fullstack web & applied AI developer in Karachi, Pakistan. Updated 28 October 2026.

If you only clicked "Update WordPress" this week, you are not done.

October 2026 dropped serious bugs in the tools under the website, not only in the theme or a plugin. PHP itself can let a stranger run code on the server. Node.js has the same class of bug in a compression library called Brotli. Next.js shipped two bugs that can run code on the server. Go had to stop trusting eight weak certificate keys from eMudhra. NGINX and self-managed GitLab needed their own updates in the same two weeks.

Pakistan's National CERT (PKCERT) already published three advisories that match this list: Advisory 19 for PHP, Advisory 20 for eMudhra, and Advisory 24 for Node.js.

This post is a patch list, not a scare story. I am not going to show exploit code. I am going to show the version numbers, who is actually at risk, and the message you can paste to your developer or your hosting company tonight.

If you only have 10 minutes, install these versions

Patch in this order. The first two are the ones I would not leave overnight on a public site.

.NET also got an out-of-band fix on 25 October for the same Brotli bug: runtime 8.0.33, 9.0.22, and 10.0.14. Bun 1.4.4 includes the Node-side Brotli fix. If you run either, update those too.

Why this week is different for sites in Pakistan

A lot of business sites in Karachi sit on shared hosting. cPanel, a cheap yearly plan, WordPress, a JazzCash or bank-transfer checkout, and a developer who is not on a retainer. That setup is fine until the bug is in PHP itself.

Here is the part that gets missed.

Updating WordPress, the theme, and the plugins does not update PHP. PHP is the language the server runs. Your host chooses it. On many Pakistani shared servers that choice is still PHP 8.1 or older. Those versions did not get an official PHP release for this bug. Some Linux vendors shipped their own backport. Many cheap hosts have not.

So the question is not "did my site update?" The question is "what does php -v say, and who is allowed to change it?"

The same split shows up everywhere else this month:

• A Next.js site on Vercel is not the same risk as a Next.js app on a VPS you forgot to redeploy.
• A Go API compiled in August is still old even if you installed a new Go on your laptop today.
• A browser update protects Chrome and Firefox. It does not protect a Python script, a Java keystore, or a Go service that ships its own trust list.

PKCERT's three advisories are the local signal. If your host or your IT vendor says they have not heard of this, send them Advisory 19, 20, and 24 from pkcert.gov.pk.

What is PHP2Shell, and does updating WordPress fix it?

No. Updating WordPress does not fix PHP2Shell.

PHP2Shell is the public name for two bugs in PHP itself: CVE-2026-109618 and CVE-2026-109619. The PHP security team scored each one 9.2 on CVSS 4.0. NVD later scored CVE-2026-109618 at 9.8 on CVSS 3.1. Both can allow someone on the internet to run code on the server with no login. The bug sits under your app. It does not care if the site is WordPress, Laravel, a custom PHP panel, or a forgotten phpMyAdmin folder.

The PHP project shipped fixes on 21 October 2026:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1, 8.0, and 7.x did not get a normal release. There are source backports, and some hosts may package those. If your account still says 8.1 or 7.4, do not assume you are safe. Ask the host for the package version and whether that package includes the October 21 fix.

On 26 October 2026, CISA added both CVEs to the Known Exploited Vulnerabilities list. US federal agencies were told to patch by 29 October 2026. Scanning showed up before the public fix. Treat this as something people are already trying, not as a theory.

One honest limit, because the headlines got loud: a firewall rule is not the fix, and the partial PHP settings people passed around do not cover every path. The PHP team was clear that those settings are incomplete. The complete fix is the new PHP version, then a restart of PHP-FPM, Apache, or LiteSpeed so old workers die.

On Windows, do not stop at the first 21 October zip if you can get the 26 October rebuilds: PHP 8.5.12-1, 8.4.27-1, 8.3.36-1, and 8.2.35-1. Those bundle Brotli 1.2.1, so they also cover the compression bug from the Node.js section.

What to check on a Pakistani shared host:

1. In cPanel, open Select PHP Version or MultiPHP Manager. Write down the number.
2. If it is below 8.2.35, open a ticket. Paste the four fixed version numbers. Ask them to move your account or confirm their backport.
3. After they say it is done, check again. Do not trust the ticket reply alone.
4. Then update WordPress, plugins, and themes. That is still worth doing. It is just a different job.

I would not keep a client shop on PHP 7.4 in 2026 even after a backport. The backport closes this hole. It does not turn an old PHP into a supported one.

What is Node2Shell, and why did Python and .NET get the same bug?

Node2Shell is not a bug in your Express routes. It is a bug in the Brotli decoder that Node.js ships.

On 21 October 2026 Node.js released 22.23.4, 24.22.1, and 26.12.1. The release fixes 10 issues. Four are high. The one people named Node2Shell (some write-ups say HTTP2Shell) is CVE-2026-111497: an out-of-bounds write in Brotli decompression. Node.js says it can lead to remote code execution. Google, which owns the Brotli library, has scored it as high as 9.2. The bug is in Brotli versions 1.0.3 through 1.0.9, 1.1.0, and 1.2.0. Fixed upstream versions are 1.0.10, 1.1.1, and 1.2.1.

That is why the same CVE showed up in more than one language:

• Python: the brotli package before 1.2.1, and brotlicffi before 1.2.1.0
• .NET: out-of-band updates on 25 October, runtimes 8.0.33, 9.0.22, and 10.0.14
• Bun: 1.4.4
• Anything else that copied an old Brotli decoder into its own binary

Updating the operating system's libbrotli package does not fix a copy baked into Node or into a Python wheel. You update the runtime or the package, then you restart. If the app runs in Docker, you rebuild the image. A running container keeps the old Node until you do.

The other high fixes in that Node release are less famous and still worth having:

• CVE-2026-105482 — dns.resolve cuts a name at a hidden NUL byte, so a program can look up a shorter name than the one it checked
• CVE-2026-106069 — TLS hostname check can be fooled when the host is an odd IPv4 form such as 0127.0.0.1
• CVE-2026-105483 — a similar TLS bypass using fullwidth digits. This one hits Node 24 and 26, not 22

Node 20 is end of life. It will not get these fixes. If a client server still says v20, the conversation is "move to 22.23.4 or newer," not "wait for a 20.x patch."

For a typical Karachi project this means the API on a VPS, the Next.js server if it is self-hosted, PM2 processes, and any small admin tool someone left running on port 3000. A static site on Vercel that never runs your own Node server is a different case, but the build image can still be old. Check node -v on the machine that actually serves traffic.

Is my Next.js site safe if it is on Vercel?

Only if the deployed version is new enough. "We use Vercel" is not a version number.

On 14 October 2026 Next.js fixed three issues. The safe floors people should be on now are 16.4.1 (or a later 16.4.x) and 15.5.28.

1. GHSA-673q-mjm6-r5xr — critical, CVSS 9.5. A bug in use cache when a cached function returns more than one typed array. It affects Next.js 16.0.0 through 16.4.0 only. Next.js 15 is not in this one. There is no config workaround. The Next.js advisory says to upgrade even if you do not think you use that pattern.
2. CVE-2026-96889 — critical in the Next.js advisory, CVSS 9.5. The image optimizer can hit a memory bug in an SVG library when sharp is older than 0.35.5, on common Linux servers (glibc). Affected range is wide: Next.js 10 through 15.5.27, and 16.0.0 through 16.4.0. Fixed in 15.5.28 and 16.4.1. Trap: on an existing 15.5 project, npm install next@15.5.28 can leave the old sharp in the lockfile. Run npm ls sharp and move it to 0.35.5 or newer.
3. CVE-2026-94482 — high, CVSS 8.2. A Server Actions bug that can burn CPU. It is a denial of service, not a "take the server" bug, but it is in the same release. Affected from Next.js 13 up through 15.5.27 and 16.0.0 through 16.4.0.

Next.js 14 and older do not have a patched release for the image bug. If a client is still on 14, plan the move. Do not tell them "14 is fine because we do not use SVG." The advisory does not support that shortcut.

I build most client sites with Next.js, React, and Node. The check I want on every repo is short: next version in package.json, the version that was actually deployed, and sharp if the project is on 15. If you want that kind of site built and kept current, my web development work in Karachi is where that stack lives. This post is the maintenance side of the same job.

Also look for old preview deployments. A forgotten Vercel preview, a staging subdomain, or a copy on a Rs. 2,000 VPS can still be on 15.5.0. Attackers do not care that you call it "just staging."

Did Python itself get a remote-code bug in October 2026?

No. CPython, the main Python interpreter, did not ship an RCE like PHP2Shell this month.

Two Python-related fixes still matter, and people mix them up.

Brotli. If your app, worker, or scraping tool uses the brotli or brotlicffi package to decompress data, update to brotli 1.2.1 and brotlicffi 1.2.1.0. That is CVE-2026-111497, the same decoder bug as Node. A Django site that never touches Brotli is not in this bucket. A FastAPI service that accepts compressed uploads might be.

Certificates. For the eMudhra problem below, Python apps that vendor the certifi bundle need certifi 2026.10.19 or newer. Updating Windows or Ubuntu is not the same as updating certifi inside a virtualenv or a Docker image.

If you run both a Next.js front and a Python AI service, patch them as two apps. I see this shape a lot: Next.js for the product, Python for the model or the agent. The Node bug and the Python package bug are related, but pip install -U does not update Node, and nvm install does not update certifi.

What happened with eMudhra, and why does a Go app care?

Eight intermediate certificate keys from eMudhra (emSign) were so weak that researchers could recover them.

A researcher reported this on 17 October 2026. The keys were created in an April 2025 ceremony. They were supposed to be strong P-384 keys. The private values were tiny integers, all under 256. Published examples include 4, 56, 66, 115, 155, 156, 230, and 237. Six of the intermediates were for website TLS certificates. Two were for code signing.

Chrome and Firefox blocked the keys within hours. eMudhra revoked the eight intermediates. Google removed the emSign ECC Root CA - G3 root from Chrome around 27 October 2026. eMudhra has said the weak intermediates had not issued normal public website certificates, and Google said none of those showed up in Certificate Transparency logs before the block. I am not claiming Pakistani bank sites were breached. I am saying the trust system had eight keys that were not secret, and old software will keep trusting bad chains until you update it.

Browsers update themselves. These often do not:

• Go programs built before the patch
• Python certifi pinned in a repo
• Node's bundled CA list, which is updated in the 21 October Node releases
• Java keystores
• curl on macOS, which often does not check revocation unless you turn that on
• old Docker images, VPNs, and small appliances

Go's fix is CVE-2026-111943. Install Go 1.27.3 or Go 1.26.10, then rebuild and redeploy every service. The block lives inside the binary you compile. A server that still runs last month's binary is still old. Go 1.25 and older did not get a release for this. Move those codebases forward.

You will sometimes see the error x509: no valid chains built after the upgrade. That is the patch doing its job when a chain hits one of those keys. It is not a random outage.

PKCERT Advisory 20 is the Pakistan note for this. If a site you own starts failing in Chrome only, check which certificate authority issued the certificate before you blame the server.

Do the NGINX and GitLab updates matter for a small business?

Yes if you run them yourself. No if a big host runs them and you only have FTP.

NGINX. On 14 October 2026, NGINX released 1.30.6 and 1.31.7. There are five bugs. NGINX rates them medium. F5 scores three of the memory bugs much higher, up to 9.2, including CVE-2026-15176. They depend on config. The risky patterns include alias combined with a rewrite that uses $request_filename, certain regex map captures, and SSI with aio. One of the bugs has been in NGINX since 2005. That does not mean every shop site is exposed. It means a copy-pasted config from an old tutorial can be. If you run NGINX on a VPS or inside Kubernetes, upgrade or install your distro's backport, then reload. If you are on shared hosting, your host owns this. Ask them anyway.

GitLab. On 21 October 2026, GitLab patched CVE-2026-110264, a CVSS 10.0 bug. It is an integer overflow in the regular expression compiler. GitLab says an unauthenticated user could run code on a self-managed GitLab server. The affected range goes back years, to the 7.0 line. GitLab.com is already patched. The 12 October self-managed releases (19.4.2, 19.3.5, 19.2.8) fixed a different bug. They are still vulnerable to this one.

Fixed builds include 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13. Versions older than the patched 18.11 line do not get a tiny patch. They need a real upgrade. 19.4.3 and 19.3.6 include database migrations, so read the upgrade notes before you click through on a Friday.

A small software house in Karachi often runs one GitLab box on a local server or a cheap VPS, with every client repo and CI token on it. That box is a worse place to be late than the marketing site.

What should you send your developer tonight?

Copy this. Fill in the blanks. Send it on WhatsApp or email.

Please confirm these versions on the live server, not only on your laptop, by tomorrow:

1. PHP is 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or a host backport you can name). PHP-FPM was restarted. If we are on 8.1 or 7.x, say so.
2. Node on the server is 22.23.4, 24.22.1, or 26.12.1. Old containers were rebuilt.
3. Next.js in production is 16.4.1+ or 15.5.28. sharp is 0.35.5 or newer if we are on Next 15.
4. Python brotli is 1.2.1 and certifi is 2026.10.19 or newer, if we use them.
5. Any Go service was rebuilt with Go 1.27.3 or 1.26.10 and redeployed.
6. Self-managed GitLab is on a 21 October fixed release, not the 12 October one.

Reply with the version output, not "done."

That message is the whole point of this article. Version numbers beat a long security thread.

If you are about to hire someone to do this, or to rebuild the site after years of "the nephew handles hosting," read the 11 checks before you hire a web developer in Pakistan. One of those checks is whether they can explain what they updated and who owns the server. This month is a live test of that.

Cheap hosting is not automatically bad. A plan that cannot move off PHP 7.4, will not answer a ticket, and keeps the site on an unknown Node binary is not cheap. It is a postponed bill. I broke down what Pakistani businesses actually pay, and what that money should include, in how much a website costs in Pakistan in 2026. Patching time is part of the cost. A quote that ends at launch day is incomplete.

Questions people ask after a week like this

Is every Pakistani website hacked?

No. A bug being public is not the same as your site already being taken over. PHP is on CISA's exploited list, so I would not wait. I also would not pay someone who DMs you "we already breached your site, pay us to fix PHP." Ask for the version. Ask what file changed. Real incidents leave logs, new admin users, and strange files. Fear does not.

Does a Cloudflare proxy or a WAF replace the patch?

No. A firewall can block some known scans. It does not close the hole in PHP, Node, or Next.js. Use it as extra cover while you patch. Then still patch.

I use WordPress. Which section is mine?

The PHP section, and the NGINX question for your host. The Next.js section is not yours unless the front of the site is headless Next.js. The Node section is yours if someone runs a Node tool, a headless frontend, or a build server next to WordPress.

I use Vercel and never SSH into a server. Am I done?

Check the deployed Next.js version and redeploy if it is below 16.4.1 or 15.5.28. Vercel runs the platform. You still choose the framework version in the repo. Also check any API you host somewhere else. The database, the Python worker, and the WhatsApp bot do not update because the frontend redeployed.

Our developer says "the host will handle it."

Sometimes that is true. Shared PHP and shared NGINX are the host's job. Make them say the version. Your developer still owns app dependencies: Next.js, sharp, Python packages, Go binaries, Dockerfiles, and GitLab if you installed GitLab yourselves.

What if we cannot upgrade this week?

Take the public site off old PHP if the host cannot move you. Put up a static page or move DNS to a host that can. For Next.js, do not leave a vulnerable preview online because production is "scheduled for next sprint." For GitLab, do not expose an unpatched server to the open internet while you wait. None of the partial workarounds are as good as the upgrade.

What I would do this week for a business site

I would not rewrite the site. I would not buy a new theme. I would do this, in order.

1. Read PHP, Node, and Next versions on the live machine.
2. Patch PHP first if the site is WordPress or Laravel. Restart PHP.
3. Rebuild and redeploy Node and Next.js if those are in the stack.
4. Update brotli and certifi if Python is in the stack. Rebuild Go binaries if Go is in the stack.
5. Ask the host about NGINX. Patch self-managed GitLab the same day if it is on the internet.
6. Save the before-and-after version output in the client WhatsApp group so this is not a story next month.

The sites that get hurt in a week like this are rarely the ones with a perfect security team. They are the ones where nobody knows who can change PHP. If that is your setup, fix the versions today, and fix the ownership after.

I am Muhammad, a full-stack and applied AI developer in Karachi. I build with Next.js, React, Node.js, and Python, and I keep the production version on the list above. If your site needs that check, or a rebuild off an old PHP host, start at dev-muhammad.vercel.app.

Sources

These are the vendor and CERT pages behind the version numbers. If a number in this post and a vendor page ever disagree, trust the vendor page. This article was written on 28 October 2026.

• PHP security releases, 21 October 2026, and the Windows Brotli rebuilds on 26 October 2026: php.net
• CISA Known Exploited Vulnerabilities entries for CVE-2026-109618 and CVE-2026-109619, added 26 October 2026
• Node.js security releases, 21 October 2026: nodejs.org
• Next.js advisories for GHSA-673q-mjm6-r5xr, CVE-2026-96889, and CVE-2026-94482, fixed 14 October 2026
• Go 1.27.3 and 1.26.10, CVE-2026-111943, urgent release around 19–20 October 2026
• NGINX 1.30.6 and 1.31.7, 14 October 2026
• GitLab patch release, 21 October 2026, CVE-2026-110264
• PKCERT Advisories 19 (PHP), 20 (eMudhra), and 24 (Node.js): pkcert.gov.pk/advisories