On November 3, 2026, the Next.js team shipped its scheduled November security release, fixing seven vulnerabilities in:

• Next.js 16.4.5 (Active LTS)
• Next.js 15.5.29 (Maintenance LTS)

It follows a busy few months: a critical remote code execution fix in the OG image generator in September, and in October, critical fixes for remote code execution in "use cache" functions and in an upstream image library.

This release is less dramatic than those, but it touches something many modern Next.js apps depend on: caching. Several issues could let one user’s or tenant’s cached data reach another, which matters a lot for SaaS apps.

Here’s what was fixed, who’s affected, and what to do.

The quick version

• Upgrade: next@16.4.5 on 16.x, or next@15.5.29 on 15.x.
• Most serious issue: cached data leaking between tenants when "use cache" and unstable_cache are combined.
• Self-hosting with next start? Several issues affect you more directly than Vercel-hosted apps.
• On Netlify? Also update @netlify/plugin-nextjs to 5.16.6.
• Next.js 14: the advisories list no patched 14.x release. Time to upgrade.

The seven issues, in plain language

1. Cross-tenant cache disclosure through unstable_cache (the most serious).
If a public "use cache" function reads a root parameter, such as a tenant ID, site, or locale, and that same function is also called from inside unstable_cache, a concurrent cold cache fill could return another request’s result without checking the root parameter. In a multi-tenant app, one customer could see another’s cached data. Most coverage rates this one High. The advisory’s workaround until you upgrade: don’t nest "use cache" inside unstable_cache.

2. Cross-root-parameter disclosure in nested "use cache" functions.
With Cache Components, an inner cached function that reads a root parameter and returns an early value alongside a slower async value could have its outer cache entry stored before its root-parameter dependencies were recorded. The result: tenant-, site-, or locale-specific content served across the wrong boundary.

3. Cross-user cache disclosure and poisoning with binary arguments.
On Next.js 16, apps that pass security-significant binary arguments, such as typed arrays or buffers, into "use cache" functions and share the resulting entries could have cache entries disclosed to or poisoned by other users.

4. Shared fallback shell poisoning on self-hosted apps.
Self-hosted apps running next start with Cache Components enabled and Partial Prefetching disabled or unset could have a shared page shell poisoned by an unauthenticated request. This affects Next.js 16.4+ apps with the route shape described in the advisory.

5. HttpOnly cookie exposure on Edge routes.
Cookie values could appear in an internal x-middleware-set-cookie response header on Edge runtime routes, defeating the purpose of HttpOnly. According to the advisory, the reproduced leak didn’t affect Node.js Route Handlers or routes setting cookies through cookies().set(). On Netlify, it also affected cookies set in Middleware.

6. SVG rejection bypass in image optimization.
With images.dangerouslyAllowSVG: false, an attacker could get an SVG past the filter by having it misclassified as AVIF, so the image optimizer would decode it as SVG anyway, reaching a parser the app had intentionally excluded. The advisory says this alone doesn’t demonstrate XSS or remote code execution.

7. Response framing issue on self-hosted apps.
Self-hosted apps that forward fetched responses, running behind HTTP/1.1 reverse proxies that use pipelining, could have responses mixed up between clients. The advisory notes it doesn’t apply to every reverse-proxy setup.

Who should worry most?

Highest priority:

• Multi-tenant SaaS apps using "use cache", Cache Components, or unstable_cache, especially where tenant, site, or locale is a root parameter.
• Self-hosted apps (next start) using Cache Components.
• Apps using Edge runtime routes that set HttpOnly cookies.

Lower but real priority:

• Apps relying on dangerouslyAllowSVG: false for safety.
• Self-hosted apps behind HTTP/1.1 pipelining proxies.

Step 1: Check your versions

npm ls next sharp

You want next 16.4.5+ or 15.5.29+.

Also check sharp, the image library Next.js uses. October’s image-optimization remote code execution issue (CVE-2026–96889), which affected Next.js running on glibc-based Linux, required sharp 0.35.5 or later. Upgrading Next.js normally brings in a fixed sharp version, but confirm it, especially in older lock files.

Step 2: Upgrade and redeploy

npm install next@16.4.5
# or, on Next.js 15
npm install next@15.5.29

Then rebuild and redeploy. On Netlify, also update the adapter:

npm install @netlify/plugin-nextjs@5.16.6

Step 3: Review your caching code

Upgrading fixes these specific bugs. But they’re a good prompt to check how your app separates cached data between users and tenants.

Search for risky patterns:

grep -rn "unstable_cache" app/ lib/
grep -rn "'use cache'\|\"use cache\"" app/ lib/

Make tenant boundaries explicit. As a general defensive habit, pass the tenant or user identifier as an argument to cached functions, so it’s always part of the cache key, rather than relying on values read indirectly inside the function:

async function getTenantSettings(tenantId: string) {
  'use cache';
  return db.settings.findUnique({ where: { tenantId } });
}

Never cache user-specific data in shared entries. Data for one logged-in user, such as profiles, orders, or permissions, shouldn’t go into a cache that’s shared across users unless the user ID is part of the key.

Avoid passing security-sensitive binary data (tokens, keys, signed payloads as typed arrays) into cached functions.

Step 4: Lock down self-hosted deployments

If you run Next.js yourself:

• Keep Next.js and sharp patched promptly. Self-hosted apps don’t get the platform-level protections hosting providers sometimes add.
• Review your reverse proxy settings, including whether HTTP/1.1 pipelining is in use.
• Watch the Next.js security page and GitHub advisories. Next.js now announces scheduled security releases about a week in advance, which gives you time to plan.

A note on Next.js versions

• Next.js 16 is the Active LTS.
• Next.js 15 is in Maintenance LTS and still received these fixes, but upgrading to 16 is recommended for the longer term.
• Next.js 14 and older received no patched releases for these advisories.

The bigger lesson: caching is now a security boundary

Modern Next.js caching is powerful: "use cache", Cache Components, and partial prerendering can make apps dramatically faster. But every cache is a shared store, and in a multi-tenant app, a caching mistake is a data leak.

Treat caching code like authorization code:

• Know exactly what goes into each cache key.
• Test with multiple tenants and users, for example by checking that tenant A never sees tenant B’s data, even under concurrent requests.
• Review cache changes carefully in pull requests.

Practical recommendation

Today:

1. Run npm ls next sharp on every Next.js project.
2. Upgrade to 16.4.5 or 15.5.29, and update the Netlify adapter if you use Netlify.
3. Search for unstable_cache and "use cache" and check how tenant and user data is cached.
4. If you’re on Next.js 14 or older, plan the upgrade now.

Four months, three significant Next.js security releases. The teams that cope best are the ones that can upgrade and redeploy within a day. If that’s hard for you today, improving your upgrade pipeline may be the most valuable security work you can do.

Sources: Next.js blog, “November 2026 Security Release” and “Upcoming Next.js November Security Release,” Netlify’s November 3, 2026 changelog, Releasebot’s Next.js release notes, and coverage from daily.dev, Webepex, TurboStarter, and DEV Community.

A Government Just Put a Date on AI-Powered Cyberattacks: What the UK’s 2028 Warning Means for Every Organization

Most warnings about AI and cybersecurity are vague: “AI could make attacks worse someday.” This week, a national cyber agency did something different. It put a date on it.

On November 3, 2026, the UK’s National Cyber Security Centre (NCSC), part of the intelligence agency GCHQ, published its annual review, The State of the Cyber Nation. Its central judgement:

It is highly likely that, between now and 2028, AI-powered malware will be used in a ransomware attack on the UK’s critical national infrastructure.

That means energy, water, transport, healthcare, telecoms, and other essential services. And while the warning is about the UK, the reasoning behind it applies to organizations everywhere.

Here’s what the NCSC said, what it didn’t say, and what any organization can do in the next two years.

What the NCSC actually said

On AI-powered ransomware: the agency judges an AI-powered ransomware attack on UK critical infrastructure “highly likely” by 2028. In intelligence language, that’s a strong statement.

On nation states: the NCSC wrote that by 2028, it is highly likely that China, Russia, and other nation states will routinely use AI in cyber operations to achieve their geopolitical goals. Reporting on the review highlighted China as the country best equipped for AI-enabled operations.

On the pessimistic scenario: alongside the review, the NCSC published an assessment of how AI could change cyber threats over the next two years. In its pessimistic scenario for 2028, it pictures a significant increase in the frequency and sophistication of attacks worldwide, with AI tools also making it harder to identify who’s behind an attack.

On the bigger picture: despite all this, the NCSC still believes AI will ultimately be a “net positive” for cybersecurity, because defenders can use it too.

The numbers behind the warning

The review covers September 1, 2025 to August 31, 2026. In that period:

• The NCSC’s incident team received 1,831 reports of cyber attacks.
• 337 needed the NCSC’s direct support.
• 80 were rated nationally significant.
• Its Early Warning service alerted 8,500 organizations to signs of a possible compromise.

“Tech on the cheap”

The most memorable line came from NCSC chief executive Richard Horne, who said that “for decades we have collectively got away with tech on the cheap.”

His point is important. AI isn’t creating most of these weaknesses. Much critical infrastructure still runs on old, unpatched, poorly segmented systems, because replacing them was always postponed to save money. Those weaknesses were tolerable when attacks were slow and labour-intensive. AI makes it faster and cheaper for attackers to find and exploit them.

What the warning does NOT say

It’s worth being precise:

• It’s a forecast, not a report of an attack. The NCSC hasn’t disclosed a specific breach or named a future target.
• Humans are still central. Analysts point out that today’s AI models are very good at finding vulnerabilities, but less capable at independently building complex custom malware. AI-enabled attacks will likely still involve skilled human operators, at least for now.
• The basics still matter most. Unpatched systems, weak passwords, and poor security hygiene remain the main ways in.

Why it matters beyond the UK

The UK isn’t alone in this view. Australia’s 2026 critical infrastructure risk review also describes AI as a growing threat multiplier. And the past month alone shows how the threat is already changing:

• PHP2Shell vulnerabilities were exploited before patches were even available.
• US agency CISA added vulnerabilities from 2015 to its list of actively exploited flaws.
• India’s CERT-In warned that AI agents had reached live systems at Indian organizations through exposed credentials.
• Researchers showed how a single file could trick AI coding agents into installing malware.

The common pattern: attackers move faster, and old weaknesses become more dangerous. That applies to a hospital in London, a bank in Mumbai, or a software company anywhere.

The UK’s defensive response

The UK government is also testing AI for defence. A project led by the Government Cyber Coordination Centre (GC3) with the AI Security Institute used AI to scan for weaknesses and uncovered hundreds of potential security issues, including critical vulnerabilities. The NCSC will run a wider scheme with the Department for Digital, Culture, Media and Sport.

The NCSC also acknowledged a challenge: automated AI defence currently falls outside many organizations’ comfort zones. Building trust in AI tools that find and fix problems will take time.

What every organization can do before 2028

You don’t need to run a power grid to act on this warning. Two years is enough time to fix a lot, if the work starts now.

1. Know what you have. You can’t protect systems you don’t know about. Build and maintain an inventory of every internet-facing system, application, and device, including forgotten test servers and old equipment.

2. Patch internet-facing systems fast. AI shortens the time between a vulnerability being disclosed and being exploited. Prioritize vulnerabilities known to be actively exploited, such as those on CISA’s Known Exploited Vulnerabilities list, and fix internet-facing systems within days, not months.

3. Use phishing-resistant multi-factor authentication. AI makes phishing messages far more convincing. Hardware security keys and passkeys protect accounts even when someone is tricked into entering a password.

4. Make backups ransomware-proof. Ransomware attackers target backups first. Keep offline or immutable backups that attackers can’t delete or encrypt. For example, with Amazon S3 Object Lock in compliance mode, backups can’t be deleted during the retention period, even by an administrator:

aws s3api put-object-lock-configuration \
  --bucket company-backups \
  --object-lock-configuration '{"ObjectLockEnabled": "Enabled", "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Days": 30}}}'

Then, most importantly, regularly test restoring from backups. An untested backup isn’t a backup.

5. Separate critical systems. Keep operational systems, such as industrial control systems, payment systems, and production databases, on separate networks from everyday office IT. That way, a compromised laptop can’t reach everything.

6. Budget to replace legacy systems. This is Horne’s “tech on the cheap” point. Old systems that can’t be patched or secured need a replacement plan, with real money attached. Every year of delay adds risk.

7. Use AI for defence, carefully. AI tools can help find vulnerabilities, sort alerts, and spot unusual behaviour. Start with tools that recommend actions for people to approve, and build trust before allowing anything automatic.

8. Prepare and practise your response. Have a written incident response plan, know who to call (your national cyber agency, such as CERT-In in India or the NCSC in the UK), and run a practice exercise at least once a year.

Practical recommendation

Treat 2028 as a deadline. This month, pick the three changes that would reduce your risk the most, usually patching internet-facing systems, phishing-resistant MFA, and tested immutable backups, and put them on a timeline with owners and budgets. A national cyber agency has given everyone a two-year warning. That’s rare. The organizations that use it well will be the ones still running normally in 2028.

Sources: NCSC, The State of the Cyber Nation (November 3, 2026), with reporting from The Register, The Next Web, Industrial Cyber, AI Weekly, Remio, Tech Insider, Swarmnetics, and AdsAdvance.

Why Your Self-Hosted LLM Is Slower Than It Should Be: KV-Cache-Aware Routing, Explained (With Kinference as the Example)

More teams are running open-weight models on their own GPUs. The reasons are good: data privacy, no per-token bills, and steady improvements in open models. The usual setup looks simple: a few vLLM replicas on Kubernetes, with a normal Kubernetes Service spreading requests across them.

Then the problems start. Responses feel slow even when GPUs aren’t busy. Adding more replicas doesn’t help as much as expected. And GPU utilization stays surprisingly low. Buoyant CEO William Morgan says it’s often in single digits, even during GPU shortages.

A big part of the problem is how requests are routed. This week, Buoyant released an open-source project aimed squarely at it: Kinference. Here’s the idea behind it, why it can make such a large difference, and how to apply it in your own setup.

First, how LLM inference spends its time

Each request to a language model has two phases:

1. Prefill: the model reads the whole prompt, which includes the system prompt, conversation history, documents, and tool definitions, and builds internal data called the KV cache (the “keys” and “values” the model’s attention layers need).
2. Decode: the model generates the answer one token at a time, reusing that KV cache.

For long prompts, prefill is expensive. It’s the main reason for time-to-first-token (TTFT): the pause before the first words appear.

Here’s the key insight: many requests share most of their prompt. In a chat, each new message resends the whole conversation. Coding agents resend the same files and instructions on every step. Business apps reuse the same long system prompt for every user.

vLLM takes advantage of this with prefix caching: if a replica already has the KV cache for the start of a prompt, it can skip recomputing that part. This can turn a slow prefill into a fast one.

The problem: round-robin routing ignores the cache

But that only works if the request reaches the replica that has the cache.

A standard Kubernetes Service spreads requests roughly evenly, without knowing anything about LLMs. So turn 1 of a conversation may go to replica A, turn 2 to replica B, and turn 3 to replica C. Each one recomputes the same prefix from scratch. The cache exists, just on the wrong GPU.

A toy simulation shows the effect. Four replicas, each able to cache 50 conversations, handle follow-up messages from 150 ongoing chats:

import random
from collections import OrderedDict
REPLICAS, CACHE_SLOTS, CONVERSATIONS, REQUESTS = 4, 50, 150, 20_000
class Replica:
    def __init__(self):
        self.cache = OrderedDict()  # conversation prefix -> cached KV (LRU)
    def handle(self, conv):
        hit = conv in self.cache
        self.cache[conv] = True
        self.cache.move_to_end(conv)
        if len(self.cache) > CACHE_SLOTS:
            self.cache.popitem(last=False)
        return hit
def simulate(route):
    random.seed(7)
    replicas = [Replica() for _ in range(REPLICAS)]
    hits = 0
    for i in range(REQUESTS):
        conv = random.randrange(CONVERSATIONS)  # follow-up turn in some chat
        hits += replicas[route(i, conv, replicas)].handle(conv)
    return hits / REQUESTS
round_robin = lambda i, conv, reps: i % len(reps)
cache_aware = lambda i, conv, reps: next(
    (n for n, r in enumerate(reps) if conv in r.cache), hash(conv) % len(reps))
print(f"Round-robin cache hit rate: {simulate(round_robin):.0%}")
print(f"Cache-aware cache hit rate: {simulate(cache_aware):.0%}")

The output:

Round-robin cache hit rate: 33%
Cache-aware cache hit rate: 99%

With round-robin, each replica tries to cache every conversation, so caches keep overflowing and only about a third of requests find a cache. With cache-aware routing, each conversation sticks to one replica, the caches don’t overlap, and nearly every request is a hit.

It’s a simplified model. Real routers must also avoid overloading a popular replica. But it shows why routing alone can change performance so dramatically, using the same GPUs and the same model.

What Kinference does

Kinference is an open-source inference control plane for vLLM on Kubernetes, released by Buoyant, the company behind the Linkerd service mesh, and announced on the vLLM blog on November 4, 2026. It’s licensed under Apache 2.0.

How it works: Kinference chooses which vLLM endpoint should handle each request. It exposes a gRPC interface that takes a request, for example in OpenAI chat-completions format, and returns the best endpoint plus any changes to the request body. It’s designed to work together with a proxy, such as the Buoyant Gateway, that actually forwards the traffic.

Its main features:

• KV-cache-aware load balancing: Kinference watches vLLM’s KV-cache events and engine metrics, so it knows which replica holds which cached data. It also considers GPU queue sizes and historical performance, so it can send each request to the replica that will do the least work for it. It uses NVIDIA’s open-source dynamo-kv-router component to track cache events.
• Declarative routing policies: routing rules are defined as Kubernetes-style resources, including options like semantic routing.
• Multi-tenant controls: token rate limiting, per-tenant policies, and per-tenant metrics, so each team’s or customer’s GPU usage can be measured and managed.
• Cloud overflow: it can optionally send requests to cloud providers under conditions you define, for example when your own GPU pool is saturated.

The headline result: in Buoyant’s own benchmark, KV-cache-aware routing reduced median time-to-first-token by 95% compared with round-robin load balancing through a standard Kubernetes Service. That benchmark measured latency without heavy load, to isolate the effect of routing. As with any vendor benchmark, test it on your own workloads.

You have options

Kinference isn’t the only project working on this problem. Cache-aware routing for LLMs is becoming a standard part of the inference stack:

• Kubernetes Gateway API Inference Extension and llm-d, an open-source effort that Google’s GKE Inference Gateway is built on, can route by prefix match and KV cache usage.
• NVIDIA Dynamo includes KV-aware routing and prefill/decode separation for vLLM and other engines.
• The vLLM Production Stack includes a KV-cache-aware router, deployable with Helm.

Kinference’s distinct angle is combining cache-aware routing with policy, multi-tenancy, and observability, in the style of a service mesh.

Getting more from your self-hosted inference, whatever tool you use

1. Keep prefix caching on. Make sure your vLLM version and settings use prefix caching, and confirm it in vLLM’s metrics.

2. Design prompts for caching. Put the stable parts first: the system prompt, tool definitions, and shared documents. Put the changing parts last: the user’s question and the latest messages. A timestamp or random ID at the start of a prompt can prevent every cache hit.

3. Measure TTFT, not just throughput. Track time-to-first-token per replica and per tenant. If it’s high while GPUs look idle, routing is a likely cause.

4. Watch cache hit rates. vLLM exposes metrics for KV cache usage and prefix cache hits. Low hit rates on chat or agent workloads are a strong sign that a cache-aware router would help.

5. Don’t just add GPUs. Before buying more hardware, try smarter routing. It may unlock capacity you already own.

The bigger picture

The first wave of AI infrastructure was about getting models to run. The current wave is about running them efficiently: better routing, better scheduling, and better use of expensive GPUs. With open-weight models becoming strong enough for real work, from small coding models like Flint to trillion-parameter models like Mistral Large 4, inference efficiency is turning into a core engineering skill.

Practical recommendation

If you run more than one vLLM replica behind a normal Kubernetes Service:

1. Check your prefix cache hit rate and TTFT in vLLM’s metrics.
2. Restructure your prompts so stable content comes first.
3. Try a cache-aware router in a test environment, whether that’s Kinference, the Gateway API Inference Extension, NVIDIA Dynamo, or the vLLM Production Stack.
4. Compare TTFT and GPU utilization before and after, on your real traffic.

The model and GPUs stay the same. Only the routing changes, and that alone may be the biggest performance improvement available to you this quarter.

Sources: vLLM blog, “Introducing Kinference: An Open Source Inference Control Plane for vLLM and Kubernetes” (November 4, 2026), the Kinference GitHub repository, Buoyant, and coverage from Cloud Native Now, daily.dev, Emergent, and AI Global Wire, plus documentation for NVIDIA Dynamo, the vLLM Production Stack, and GKE Inference Gateway.

Mistral Large 4’s Weights Are Out: What Changed Since the Preview, the License Fine Print, and the Hardware You’ll Need

Three weeks after its public preview, Mistral Large 4, nicknamed “Le Chonk,” is now an open-weight model. On October 29, 2026, Mistral published the full weights on Hugging Face, making it the largest open-weight model any US or European lab has released.

The released version isn’t just the preview with a download button. It’s noticeably stronger, it’s about half the price through Mistral’s API, and its license has some fine print every business should read.

Here’s what changed, what you can and can’t do with it, and what it takes to actually run a trillion-parameter model.

What was released

• Model: mistralai/Mistral-Large-4-1T-A52B on Hugging Face
• Size: about 1.05 trillion parameters in a mixture-of-experts design, with roughly 52 billion active per token, according to the released model’s name and specs. The preview was described with about 49 billion active.
• Context window: 1 million tokens
• Inputs: text and images (with a vision encoder of about 1.6 billion parameters), output in text
• Languages: 160+
• Training: from scratch on 3,800 NVIDIA Grace Blackwell GPUs in Mistral’s European data centres
• Two official versions:
• FP8: about 1.06 TB
• NVFP4: about 610 GB, a 4-bit format for NVIDIA’s newest Blackwell GPUs

What changed since the preview

1. Better at agentic coding. Mistral says three more weeks of reinforcement learning, guided by customer feedback, lifted the model’s score on Terminal-Bench 4.0, a benchmark for agents completing real tasks in a terminal, from 28.3% to about 41%. Independent replication is still pending, so treat that number with some caution.

2. More control over thinking. Early testers, which Mistral describes as governments and enterprises, wanted more control over how long the model “thinks” before answering. Balancing speed, cost, and quality is crucial in production, so this is a practical improvement.

3. Roughly half the price. On the day the weights shipped, Mistral cut its API price roughly in half, to about $0.70 per million input tokens and $2.10 per million output tokens, down from $1.36 and $4.18 during the preview.

4. A strong open model, not a frontier leader. Mistral calls Large 4 the best open model for coding and cyber defence, and reports top results among open-weight models on FrontierCode 2.0 and Terminal-Bench 4.0. But independent coverage notes that the coding lead over GLM-5.3 is about one point on a single index. It’s a strong open model, but it doesn’t dethrone the leading closed models.

The license: read this before you build a business on it

Mistral Large 4 uses the new Mistral Ecosystem Open-Weight License, described as a modified MIT license. In practice:

You can:

• Download the weights without approval
• Use it commercially inside your own products
• Fine-tune and modify it
• Run it on your own infrastructure, including on-premises

You need a separate agreement with Mistral to:

• Offer it as a hosted model service to third parties, for example selling API access to Large 4 itself

So a company using Large 4 inside its own app, chatbot, or internal tools is fine. A company planning to become a Large 4 API provider needs to talk to Mistral first.

It’s also open-weight, not fully open-source. The trained model is available, but the training data isn’t, and the hosting restriction goes beyond a standard MIT license.

The memory math: can you run it?

Here’s where “free to download” meets reality. A rough estimate of memory needed for the weights alone:

params = 1.05e12          # total parameters
fp8_gb = params * 1.0 / 1e9      # 1 byte per parameter
nvfp4_gb = params * 0.58 / 1e9   # ~4 bits plus scaling data
print(f"FP8 weights:   ~{fp8_gb:,.0f} GB")
print(f"NVFP4 weights: ~{nvfp4_gb:,.0f} GB")

That roughly matches the official checkpoint sizes: about 1.06 TB for FP8 and 610 GB for NVFP4.

And that’s just the weights. Real serving also needs memory for the KV cache, which grows with context length and the number of users. Using anywhere near the 1 million-token context adds a lot more.

Mistral’s own serving examples use:

• 8 GPUs for FP8
• 4 to 8 GPUs for NVFP4, on NVIDIA B200, B300, GB200, or GB300 Blackwell GPUs

In other words, Large 4 is a data-centre model. It won’t run on a laptop, a gaming PC, or a single GPU server. Even though it’s mixture-of-experts and only about 52 billion parameters are active per token, all 1 trillion must be stored in GPU memory, because any expert may be needed for the next token.

A typical multi-GPU deployment with an inference server like vLLM looks something like this (check the model card for the exact recommended settings):

vllm serve mistralai/Mistral-Large-4-1T-A52B \
  --tensor-parallel-size 8 \
  --tokenizer-mode mistral

If you can’t self-host, the API is the practical option

For most teams, the easiest way to use Large 4 is through a hosted service:

• Mistral’s API (as mistral-large-4), at the new lower price
• OpenRouter
• Microsoft Foundry
• Mistral’s Vibe coding agent, for some users

Hugging Face also offered demo Spaces with a small free allowance during the first week after release.

Who should care about the open weights?

Self-hosting makes sense if you:

• Need data to stay on your own infrastructure, for example in government, banking, defence, or healthcare
• Want European data residency and independence from US cloud providers
• Plan to fine-tune a very large model for a specialised domain, such as security or a specific language
• Already have access to multi-GPU Blackwell servers

The API is probably better if you:

• Want to test the model before committing to hardware
• Have moderate usage, where per-token pricing beats owning GPUs
• Don’t have specific data-control requirements

The bigger picture

The open-weight frontier has grown fast in 2026. Chinese labs have released several trillion-parameter-class open models, including Meituan’s LongCat-2.0 in June, trained on more than 50,000 domestic Chinese accelerators. Large 4 is Europe’s answer: a trillion-parameter open model, trained in Europe, with Mistral’s own data centres and a growing NVIDIA partnership behind it.

For developers, the trend is clear: open models keep getting bigger and better, but running the largest ones is still a serious infrastructure decision. The practical skill is knowing which model fits which job, from small local models like Flint for everyday coding to trillion-parameter models like Large 4 for the hardest, most sensitive workloads.

Practical recommendation

1. Test it through the API first. Run 20 to 50 of your real tasks and compare quality, speed, and cost with what you use now, at the new lower price.
2. Read the license if you plan any commercial use, especially anything that looks like offering the model as a service.
3. Only consider self-hosting if you have clear data-control needs and access to multi-GPU Blackwell hardware. Do the memory math, including the KV cache, before buying anything.
4. Wait for independent benchmarks before relying on the Terminal-Bench improvement.

Mistral Large 4 is a milestone for open AI in Europe. Just remember that “open” means you’re allowed to run it, not that it’s easy to run it.

Sources: Mistral’s October 29, 2026 announcement as reported by The Next Web, Euronews, Fortune and ZDNet; Hugging Face’s “Welcome Le Chonk” blog and model card; and coverage from TUN, Apple Scoop, CellCog, Online Tech Tips, and DEV Community, plus The Decoder and TechRadar on Meituan’s LongCat-2.0.

But if you already use Polars, that’s not the question you care about. Your question is simpler:

“If I upgrade from Polars 1.x to 2.0, will my code run faster?”

The official release post doesn’t answer that directly. Here’s what the available evidence shows, where 2.0 is slower, and how to measure the difference on your own data in about ten minutes.

What the official benchmark does, and doesn’t, tell you

The Polars team benchmarked 2.0 against DuckDB 1.5.6, a DuckDB 2.0 alpha, and DataFusion 54.0.0, using queries derived from TPC-H and TPC-DS on two AWS machines: a 16-vCPU c7a.4xlarge and a 192-vCPU c7a.metal.

Two findings stand out:

• Default Polars was fastest on all but one benchmark.
• On very large machines with small data, Polars has a constant overhead. At scale factor 10, moving from 16 to 192 vCPUs made default Polars 1.8x slower on TPC-DS. Polars limited to 32 threads was competitive or winning everywhere.

A Polars developer explained the cause on Hacker News: the join creates one partition per thread for each of the T threads, so the work grows with T squared on a 192-core machine. The team has diagnosed it and plans a fix.

What the official post doesn’t include is a comparison with Polars 1.x. For that, we need independent data.

The best direct comparison: 1.44.1 vs 2.0.0

Shortly after the release, the developer of ArrowMetal, an open-source GPU engine for Polars on Apple Silicon, re-ran their benchmark suite on both versions, using the same code and the same machine:

• Hardware: Apple M4 Max
• Data: 50 million rows, in memory
• Queries: 62 group-by, join, sort, and unique queries
• Method: best of 5 runs

The results:

• Overall: Polars 2.0.0’s time was 0.72x of 1.44.1’s at the median, roughly 28% faster.
• unique over two integer keys: 153.1 ms → 38.5 ms, about 4x faster.
• Sorting 5 million rows: 32.88 ms → 13.55 ms, about 2.4x faster.
• The streaming engine, now the default, was the faster of the two engines in 56 of the 62 queries.
• Sorting 50 million int64 keys: on Polars 2.0.0, the default streaming collect() took 199.74 ms, while forcing the old in-memory engine took 410.51 ms.

But not everything got faster:

• Filter-then-sort over integer keys: 694 ms → 713 ms, slightly slower.
• unique over a String and an integer key: 256 ms → 296 ms, about 16% slower.

This matches what the Polars team suggested before release: in September, they said they expected the new streaming engine to be “easily 5x faster” in aggregate for many workloads. The independent results suggest that’s possible on some operations, while the typical improvement is smaller, and a few operations go slightly the other way.

Why most workloads get faster

Two separate things changed in 2.0:

1. The default engine changed. In 1.x, LazyFrame.collect() used the in-memory engine. In 2.0, it uses the streaming engine, which processes data in batches across cores and uses less memory.

2. The engines themselves improved. Group-bys, joins, and sorts were optimized, and the query optimizer gained join reordering, better elimination of repeated sub-queries, and dynamic predicates.

This distinction matters when benchmarking. Polars 1.x already had a streaming engine; you just had to ask for it with collect(engine="streaming"). Comparing default 1.x with default 2.0 mixes both effects together. Comparing 1.x streaming with 2.0 streaming shows how much the engine itself improved.

Where 2.0 may be slower

Based on the available data, watch these patterns:

• Small data on machines with many cores. The constant overhead per thread can outweigh the benefit of parallelism. If you run small queries on large servers, test limiting the thread count.
• Some sort-heavy queries, especially filter-then-sort.
• Some operations on String keys, such as unique with a String column.
• Queries where you now need maintain_order=True to keep the old row order. Preserving order can cost some speed.

How to benchmark your own workload

Benchmarks on someone else’s machine are a starting point, not an answer. The good news: with uv, you can run the same script on both versions without changing your environment.

Save this as bench.py:

import time
import numpy as np
import polars as pl
N = 5_000_000  # increase to 50_000_000 if you have enough RAM
rng = np.random.default_rng(42)
pl.DataFrame({
    "order_id": np.arange(N),
    "customer_id": rng.integers(0, 200_000, N),
    "region": rng.choice(["north", "south", "east", "west"], N),
    "amount": rng.random(N) * 1000,
}).write_parquet("orders.parquet")
pl.DataFrame({
    "customer_id": np.arange(200_000),
    "segment": rng.choice(["retail", "wholesale", "online"], 200_000),
}).write_parquet("customers.parquet")
orders = pl.scan_parquet("orders.parquet")
customers = pl.scan_parquet("customers.parquet")
queries = {
    "group_by_sum": orders.group_by("region").agg(pl.col("amount").sum()),
    "join_group_by": orders.join(customers, on="customer_id").group_by("segment").agg(pl.col("amount").mean()),
    "sort": orders.sort("amount"),
    "unique_two_keys": orders.select("customer_id", "region").unique(),
    "filter_sort": orders.filter(pl.col("amount") > 500).sort("customer_id", "amount"),
}
def best_of(lf, runs=5):
    times = []
    for _ in range(runs):
        start = time.perf_counter()
        lf.collect()
        times.append(time.perf_counter() - start)
    return min(times) * 1000
print(f"Polars {pl.__version__}, {N:,} rows")
for name, lf in queries.items():
    print(f"{name:16s} {best_of(lf):8.1f} ms")

Then run it on each version:

uv run --with "polars==1.44.1" --with numpy python bench.py
uv run --with "polars==2.0.0" --with numpy python bench.py

The script uses only APIs that work in both versions, so the comparison is fair.

Better still, test your real pipelines. Replace the sample queries with your own: the slowest step in your ETL job, your heaviest notebook query, or a typical report. That’s the only benchmark that truly matters.

Tips for reliable results

• Run on the hardware you use in production. A laptop and a 64-core server can give very different results.
• Use realistic data sizes. Small data and large data behave differently, especially in 2.0.
• Take the best of several runs, and close other heavy applications.
• Compare engines separately: in Polars 1.x, also try lf.collect(engine="streaming") to see how much of the gain comes from the new default versus engine improvements.
• Watch memory, not just time. The streaming engine’s lower memory use, and its new ability to spill to disk, can matter more than speed for large datasets.
• On large servers with small data, test thread limits. Polars reads the POLARS_MAX_THREADS environment variable at startup:

POLARS_MAX_THREADS=32 python bench.py

Should you upgrade for performance?

Probably yes, if you:

• Use LazyFrames with large group-bys, joins, or unique operations.
• Hit memory limits with Polars 1.x.
• Run on typical laptops or servers with a moderate number of cores.

Test carefully first if you:

• Run small queries on machines with many cores.
• Have pipelines dominated by sorts or String-key operations.
• Rely on row order after joins or group-bys. Remember that 2.0 no longer guarantees order unless you ask for it.

And keep watching: Polars 2.1.0 is already available on PyPI, and the team has said that improving scaling on high-core machines is a priority. Some of today’s weak spots may already be improving.

Practical recommendation

Don’t upgrade based on anyone’s benchmark, including this article’s. Spend ten minutes running the script above with your real queries on both versions. If 2.0 is faster and your results are identical, which you can check with df_old.equals(df_new.sort(...)) after sorting both, you have a clear case to upgrade. If a few queries are slower, you’ll know exactly where to look.

Sources: Polars, “Release of Polars 2.0” (pola.rs) and its benchmark appendix, ArrowMetal’s Polars 1.44.1 vs 2.0.0 benchmark on DEV Community (October 8, 2026), The New Stack’s coverage of the Polars 2.0 pre-release, a Hacker News discussion with Polars developers, and Andy G.’s “Polars 2.0 Is Out” on Medium.

Kubernetes Before KubeCon 2026: 1.34 Hits End of Life, a New Standard for AI Workloads, and What to Do This Month

KubeCon + CloudNativeCon North America takes place November 9–12 in Salt Lake City, and the Kubernetes world has been busy in the run-up. In the last week alone:

• Kubernetes 1.34 reached end of life on October 27, 2026.
• The community launched a Workload Conformance Working Group, aimed at the growing variety of workloads, especially AI.
• OpenTelemetry’s Transformation Language (OTTL) reached v1.
• Kubernetes 1.38 moved closer to its December release.

Here’s what each change means and what platform teams should do before the conference.

1. Kubernetes 1.34 is end of life: check your clusters

As of October 27, 2026, Kubernetes 1.34 no longer receives patches. Its final release is 1.34.12, from September 15. That leaves three supported minor versions, with 1.37, currently at 1.37.1, supported until October 28, 2027.

Kubernetes supports each minor version for about 14 months: around 12 months of standard support plus 2 months of maintenance. That cadence means every team needs a regular upgrade rhythm, not occasional big-bang upgrades.

Check your control plane and node versions:

kubectl version
kubectl get nodes -o wide

The VERSION column in the node list shows each node’s kubelet version.

If anything shows 1.34 or earlier:

• Self-managed clusters: plan the upgrade now. Kubernetes only supports upgrading one minor version at a time, so moving from 1.34 to 1.37 means three upgrades.
• Managed services (EKS, GKE, AKS): check your provider’s support policy. Some offer extended support for older versions, often at extra cost, but that only postpones the work.
• Before upgrading: review the deprecation guides for every version you’ll pass through, and check that your add-ons, ingress controllers, and operators support the target version.

Remember the cgroup v2 requirement. Since Kubernetes 1.35, the kubelet refuses to start on cgroup v1 nodes by default. If you’re upgrading from 1.34, check that your nodes use cgroup v2 first:

stat -fc %T /sys/fs/cgroup/

The output should be cgroup2fs.

2. A new Workload Conformance Working Group

Kubernetes already has a well-known conformance program for clusters, so you can trust that a certified cluster behaves like Kubernetes should. There’s also a Kubernetes AI Conformance program for checking whether a cluster can run AI and machine learning workloads.

What’s been missing is a standard for workloads themselves. On October 27, 2026, the community announced the Workload Conformance Working Group to fill that gap. In the announcement, Broadcom’s Nabarun Pal explained that the group is writing a shared standard for how workloads behave at runtime on Kubernetes.

Why this matters: today, there’s no common way to say “this workload behaves well on Kubernetes.” Teams discover problems through trial and error, such as how an application handles node drains, whether it has the permissions it expects, or how it reacts to being rescheduled. That’s especially painful for AI workloads, which are often long-running, GPU-heavy, and sensitive to interruption.

A shared workload standard could eventually help:

• Platform teams set clear expectations for applications running on their clusters.
• Software vendors prove their products behave correctly on Kubernetes.
• AI teams run training and inference jobs more reliably across different clusters and clouds.

The group is just starting and is asking for community input. You can read the working group proposal, join the #wg-workload-conformance Slack channel, or attend its biweekly meetings.

3. Kubernetes images get signed verification summaries

The Kubernetes project has signed its container images since version 1.24. On October 28, 2026, the contributor blog described the next step: SLSA verification summaries for images published to registry.k8s.io.

A signature proves an image came from the Kubernetes project and hasn’t been changed. A verification summary goes further, recording how the image was checked against supply chain requirements, in a single signed document.

You can already verify the signatures of official Kubernetes images with cosign. Following the Kubernetes documentation, verification looks like this:

cosign verify registry.k8s.io/kube-apiserver-amd64:v1.37.1 \
  --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com

With supply chain attacks hitting package registries this year, from npm to PyPI, verifying the images that run your control plane is a good habit.

4. OpenTelemetry’s Transformation Language reaches v1

Observability matters more than ever on Kubernetes, and this week OpenTelemetry’s Transformation Language (OTTL) reached v1. OTTL lets you modify, filter, and enrich telemetry data directly in the OpenTelemetry Collector, before it reaches your monitoring backend. It’s now stable for traces, metrics, and logs, and included in Collector Contrib v0.164.0 and later.

The project also made a long-term promise: OTTL syntax and standard functions will stay backward compatible.

A common use is removing sensitive data before it leaves your cluster. For example, in a Collector configuration:

processors:
  transform:
    error_mode: ignore
    trace_statements:
      - delete_key(span.attributes, "user.email")
      - set(span.attributes["deployment.environment"], "production")

hat removes user email addresses from traces and tags them with an environment, all inside your own infrastructure.

5. Kubernetes 1.38 is on the way

Kubernetes 1.38 is in development, with code freeze around November 16–17 and the release blog planned for December 16, 2026. A deprecations and removals blog is scheduled for November 23. Watch for it, since it’s the best early warning of anything that might break your clusters.

What to expect at KubeCon

Based on the topics leading up to the conference, expect a strong focus on:

• AI workloads on Kubernetes: GPU sharing, inference at scale, and scheduling for AI jobs. For example, AWS and NVIDIA are presenting on placing multiple models on shared GPUs.
• AI agents and security: sandboxing agents, managing their credentials, and limiting what they can do.
• Observability: OpenTelemetry and Prometheus continuing to converge.
• Supply chain security: signing, verification, and provenance for images and dependencies.

Practical checklist for platform teams

This week:

1. Run kubectl version and kubectl get nodes -o wide on every cluster, and plan upgrades for anything on 1.34 or older.
2. Confirm all nodes use cgroup v2 before upgrading past 1.34.
3. Try cosign verify on the Kubernetes images you run.
4. Upgrade your OpenTelemetry Collector to a version with OTTL v1, and use it to remove sensitive data from telemetry.
5. Bookmark the 1.38 deprecations blog for November 23.
6. If you run AI workloads, consider sharing your experiences with the new Workload Conformance Working Group. Real-world problems are exactly what the group needs to hear.

Kubernetes keeps moving quickly. Teams that upgrade steadily, verify what they run, and take part in the community stay ahead of problems instead of reacting to them.

Sources: the Kubernetes blog and contributor blog (October 27–28, 2026), the Kubernetes releases page, the Kubernetes v1.38 release schedule, The New Stack’s “Road to KubeCon” coverage, the OpenTelemetry blog, and DEV Community.

On Sunday, October 26, 2026, the Python team did something it rarely does: it pushed out expedited security releases for five Python versions at once: 3.15.2, 3.14.10, 3.13.18, 3.12.16, and 3.11.18.

The reason wasn’t a bug in Python’s code. It was a problem in the system of trust the whole internet relies on: the private keys of eight intermediate certificates from the certificate authority eMudhra, under its emSign brand, had been compromised.

Here’s what happened, why it matters for every Python developer, and exactly what to update.

What happened

Every HTTPS connection relies on certificate authorities (CAs). When your code connects to a website or API, it checks that the server’s certificate was issued by a trusted CA, usually through an intermediate certificate that links back to a trusted root.

On October 20, 2026, eMudhra disclosed that the private keys of eight of its emSign intermediate CA certificates had leaked.

That’s serious. With those keys, an attacker could issue certificates that look completely valid for almost any website, then use them to impersonate sites and intercept encrypted traffic, for example on a compromised network.

The issue is tracked as CVE-2026–115557.

How Python responded

The new releases hardcode a denylist of the eight compromised intermediate certificate keys into Python’s ssl module. Even if a certificate chain would otherwise look valid, Python now rejects anything signed with those keys.

An important detail: this makes normal pip use safe, including upgrading pip itself, even before you’ve updated pip. That matters because pip is how most people install the very fixes they need.

The other languages and tools responded too. Go released 1.27.3 with a fix that distrusts a handful of compromised intermediate certificates, and the wider ecosystem has been shipping updates since the disclosure.

Also fixed in these releases

The releases include several other security fixes:

• CVE-2026–114583: tarfile’s tar_filter now rejects links that replace the destination, closing a path-traversal-style risk when extracting tar archives.
• http.cookiejar now rejects cookies with a negative version.
• Python 3.13.18, 3.12.16, and 3.11.18 also get an update to Expat 2.9.0, fixing CVE-2026–77214 and CVE-2026–102633 in the bundled XML parser.
• Python 3.13.18 and 3.12.16 also get a fix for a race condition in tempfile.TemporaryDirectory cleanup, where an attacker could swap a subdirectory for a symbolic link during deletion and affect files outside the directory.

This is the second round of expedited releases this month, following 3.15.1 and 3.14.9 on October 21.

Step 1: Update Python

Check your version:

python3 --version

You want 3.15.2, 3.14.10, 3.13.18, 3.12.16, or 3.11.18, depending on your version line.

Note: binary installers are only available for 3.15.2 and 3.14.10. The other three are source-only releases, so on those versions you’ll typically get the fix through your operating system’s packages, your Docker base image, or tools like uv and pyenv once they publish updated builds.

Docker: update your base images, then rebuild:

FROM python:3.14.10-slim

uv: update uv itself, then install the latest patch of your Python version:

uv self update
uv python install 3.14

Hosting platforms are updating too. Heroku’s Python buildpack, for example, already points each version alias to the new patch releases. Redeploy to pick them up.

Step 2: Update pip

Even with the Python fix in place, update pip to 26.2.2 or newer. Older pip versions still trust the compromised certificates:

python3 -m pip install --upgrade "pip>=26.2.2"

Do this in every virtual environment and every Docker image, not just your system Python.

Step 3: Update certifi and HTTP libraries

Many Python libraries, including requests, use the certifi package for trusted certificates rather than the operating system’s store. Update it and check its release notes:

python3 -m pip install --upgrade certifi requests urllib3

Step 4: Check whether your app depends on emSign certificates

There’s a flip side to distrusting certificates: any legitimate service whose certificate chains through one of the distrusted intermediates will now fail TLS verification. Since eMudhra is a widely used CA in India, teams calling Indian government portals, banking APIs, or other services that use emSign certificates should check their integrations.

To see who issued a server’s certificate:

openssl s_client -connect api.example.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -issuer

If a service you depend on uses an affected certificate, connections may start failing after you update. Don’t work around it by disabling certificate verification. Contact the service provider. They’ll need to reissue certificates from an unaffected chain.

Step 5: Use safe archive extraction

The tarfile fix is a good reminder to always use extraction filters when handling archives from untrusted sources:

import tarfile
with tarfile.open("upload.tar.gz") as tar:
    tar.extractall(path="extracted/", filter="data")

The "data" filter blocks dangerous archive contents, such as absolute paths, links outside the destination, and device files.

What about Python 3.10?

Python 3.10 reached end of life in October 2026 and isn’t part of these releases. If you still run Python 3.10, you won’t receive this fix or future ones. Upgrading to at least Python 3.12, and ideally 3.14 or 3.15, should be a priority.

Other Python news this week

• Django 6.1 now supports Python 3.15.
• Python’s experimental JIT compiler may be removed from CPython’s main branch early in the 3.16 development cycle, after PEP 836 was withdrawn. If you were experimenting with the JIT, keep an eye on that discussion.

Lessons for every developer

1. Trust is part of your supply chain. You can write perfect code and still be exposed because a certificate authority somewhere had a problem. Fast patching is the only defence.

2. Update the whole stack. Python, pip, certifi, base images, and hosting platforms each have their own copy of “what to trust.” Updating one isn’t enough.

3. Never disable certificate verification. When TLS errors appear after a security update, they often mean the update is working. Fix the certificate, not the check.

4. Automate base image updates. Tools like Dependabot and Renovate can update Docker base images and Python versions automatically, so emergency fixes reach production in hours instead of weeks.

Practical recommendation

Today:

1. Update to Python 3.15.2, 3.14.10, 3.13.18, 3.12.16, or 3.11.18.
2. Upgrade pip to 26.2.2+ in every environment and image.
3. Update certifi, requests, and urllib3.
4. Rebuild and redeploy your Docker images and services.
5. Check whether any integrations use emSign certificates, especially if you work with Indian services.

This is one of the rare security events that affects almost every Python project at once. Fortunately, the fix is straightforward: update, rebuild, redeploy.

Sources: Python.org release announcements, heise online, daily.dev, Linux Compatible, Warp2Search, Heroku’s Python buildpack v359 release notes, and the Django News newsletter, Issue 361 (October 26–30, 2026).

Apache Kafka 4.4 Is Out: Dead-Letter Queues for Share Groups, Transactional State Stores, and an Upgrade Gotcha to Know

Apache Kafka keeps evolving fast. On October 22, 2026, the project released Kafka 4.4.0, with 25 Kafka Improvement Proposals (KIPs) and 963 commits since 4.3.0. The very next day came Kafka 4.3.2, a bug-fix release with an important data-safety fix for anyone using tiered storage.

Kafka 4.4 contains features developers have wanted for years, along with one storage change that can catch you out during upgrades. Here’s what matters most.

First: if you use tiered storage, look at 4.3.2

Before the new features, a safety note. Kafka 4.3.2, released October 23, fixes around 60 issues, including two potential data loss issues in tiered storage: one in size-based retention and one in time index truncation.

If you run Kafka 4.3.x with tiered storage enabled, plan to upgrade to 4.3.2 (or 4.4.0) soon, even if you’re not interested in new features.

1. Dead-letter queues for share groups

Kafka 4.x introduced share groups, often called “Queues for Kafka.” Unlike classic consumer groups, where each partition belongs to one consumer, share groups let many consumers work through the same partition cooperatively, with each record acknowledged individually. That makes Kafka work much more like a traditional job queue.

Every queue system eventually needs an answer to one question: what happens to messages that keep failing?

Kafka 4.4 adds dead-letter queues (DLQs) for share groups (KIP-1191). Records become eligible for the DLQ when they:

• Are released more times than the maximum delivery count, for example after repeated processing failures, or
• Are explicitly rejected by the share consumer.

The feature requires the share.version feature to be upgraded to 2, and it’s configured dynamically through settings including:

• errors.deadletterqueue.topic.name
• errors.deadletterqueue.auto.create.topics.enable
• errors.deadletterqueue.copy.record.enable

In practice, setup might look like this (check the Kafka 4.4 documentation for exact syntax in your environment):

# Enable the newer share group feature level
bin/kafka-features.sh --bootstrap-server localhost:9092 \
  upgrade --feature share.version=2
# Send poison messages for a share group to a DLQ topic
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --entity-type groups --entity-name invoice-workers \
  --add-config errors.deadletterqueue.topic.name=invoice-workers-dlq

Why it matters: without a DLQ, a single bad message can be retried endlessly, blocking work or forcing you to build custom error handling. With a DLQ, failing messages are moved aside automatically, so the rest of the queue keeps flowing and someone can inspect the failures later.

2. Transactional state stores for Kafka Streams

This is one of the most anticipated changes in Kafka Streams, first proposed years ago as KIP-892.

Before 4.4, when a Kafka Streams app using exactly-once processing hit an error, its local state stores were often wiped and rebuilt from scratch. For apps with large state, rebuilding could take a very long time.

With transactional state stores, enabled with the new setting enable.transactional.statestores, state stores are no longer wiped and rebuilt on error. Only writes made since the last successful commit are lost and replayed.

processing.guarantee=exactly_once_v2
enable.transactional.statestores=true

Two related settings help you tune it:

• statestore.uncommitted.max.bytes limits how much uncommitted data is buffered.
• default.interactive.query.isolation.level controls whether interactive queries see uncommitted data.

The feature is off by default, so test it with your own workloads first. For stateful Streams apps, faster recovery can mean minutes instead of hours after a failure.

3. Better resilience to DNS problems

In cloud and Kubernetes environments, DNS isn’t always available exactly when an application starts. Kafka 4.4 adds bootstrap.resolve.timeout.ms (KIP-909) for clients:

• The default, 0, keeps the old behaviour: DNS resolution happens synchronously when the client is created.
• A positive value turns on asynchronous bootstrap resolution: the client constructor returns immediately, and resolution failures show up later as a BootstrapResolutionException.

bootstrap.servers=kafka.internal.example:9092
bootstrap.resolve.timeout.ms=30000

he project marks this as an evolving feature that may change in a minor release, and Kafka Streams and Kafka Connect don’t support it yet.

4. Lower tiered storage costs with delayed upload

Tiered storage moves older Kafka data to cheaper object storage like S3. Kafka 4.4 adds remote.copy.lag.bytes and remote.copy.lag.ms (KIP-1241), which let you delay uploading data to remote storage. That reduces how much data is stored in both places at once, which can lower storage costs.

5. Clearer control over Kafka Connect internal topics

Kafka Connect normally creates its internal topics (for offsets, configs, and status) automatically. In locked-down environments, that’s not always allowed. Kafka 4.4 adds internal.topics.automatic.creation.enable (default true). When set to false, Connect fails at startup if any internal topics are missing, and a new connect-internal-topics.sh tool helps create them manually.

6. Better operations tooling

• kafka-cluster.sh api-versions shows the API versions supported by brokers or controllers. It replaces kafka-broker-api-versions.sh, which is deprecated:

bin/kafka-cluster.sh api-versions --bootstrap-server localhost:9092

• Controllers can now be unregistered from cluster metadata, with new commands and an Admin API (KIP-1312).
• More Linux I/O metrics are exposed through JMX, making it easier to spot page-cache problems and write amplification.
• Clients detect misrouted connections by including cluster and node information when connecting.
• Benchmarking is more realistic: kafka-producer-perf-test.sh can now control how record keys are distributed.

The upgrade gotcha: storage formatting

This is the change most likely to surprise operators. Under KIP-1170, storage directories formatted with the kafka-storage tool are no longer forward-compatible. A broker must be the same version as, or newer than, the kafka-storage tool that formatted its directory, regardless of the --release-version you chose.

In practice:

• Don’t format storage with a newer Kafka tool than the brokers that will use it.
• Keep your provisioning scripts, container images, and brokers on matching versions.
• Be extra careful in automated setups, where a tooling image may be updated separately from the broker image.

Deprecations to note

• broker.id is deprecated (KIP-1232).
• ClientQuotaCallback#updateClusterMetadata is deprecated and will be removed in Kafka 5.0.
• Remaining Yammer-based group coordinator metrics are deprecated in favour of Kafka Metrics equivalents. Update dashboards that depend on them.
• kafka-broker-api-versions.sh will be removed in the next major release.

A sign of the times

The release announcement thanks 151 contributors, “and 8 AIs.” It’s a small detail, but it reflects how AI tools are becoming part of how even major open-source infrastructure projects are built.

Which Kafka versions are supported?

Kafka aims for three releases a year. If you’re on an older version, check the support timeline and plan upgrades accordingly. Upgrading regularly means each step stays smaller and safer.

Practical recommendation

1. Using tiered storage on 4.3.x? Upgrade to 4.3.2 soon for the data loss fixes.
2. Planning to move to 4.4? Read the “Upgrading to 4.4” notes first, and check that storage formatting tools and brokers will use matching versions.
3. Running work queues on share groups? Try the new dead-letter queues in a test environment.
4. Running stateful Kafka Streams apps? Test transactional state stores and measure how much faster your app recovers from failures.
5. Update dashboards and scripts that use deprecated metrics or tools.

Kafka 4.4 isn’t a flashy release, but it makes Kafka a more practical queue, a more resilient stream processor, and a cheaper long-term store, three things many data teams care about every day.

Sources: Apache Kafka 4.4.0 and 4.3.2 release announcements (October 22–23, 2026), Apache Kafka downloads page, and endoflife.date’s Apache Kafka support timeline.

If you run Go services in production, October brought two security releases worth acting on:

• Go 1.27.2 and 1.26.9, released October 8, 2026, with security fixes to the go command and the crypto/tls, html/template, net/http, net/textproto, and os packages.
• Go 1.27.3, released October 19, 2026, with a security fix to crypto/x509 that distrusts a handful of compromised intermediate certificates.

Most of the fixes target HTTP/2 and HTTP/1 handling in net/http, the code that powers most Go web servers, APIs, and proxies.

But there’s an important detail that’s easy to miss in Go: installing a new Go version doesn’t fix anything already running. Here’s what was fixed, why rebuilding matters, and how to check your services.

What was fixed

The October 8 releases address a long list of issues, including:

HTTP/2 (server and client):

• Memory exhaustion from Trailer headers on HTTP/2 servers
• Server crash from a race condition in the HPACK header encoder
• Excessive CPU use from repeated changes to the initial window size
• Double flow-control refunds on HTTP/2 server streams
• The HTTP/2 transport accepting malformed framing headers

HTTP/1:

• Connection desynchronization on the client after a rejected CONNECT request
• Connection desynchronization on the server after a successful CONNECT response
• No limit on the size of parsed Range headers

Other packages:

• crypto/tls: rejecting malformed Encrypted Client Hello (ECH) extension references
• net/textproto and mime/multipart: a way to bypass the memory limit on MIME headers
• Fixes in html/template, os, and the go command

Then on October 19, Go 1.27.3 fixed CVE-2026–111943 in crypto/x509 by distrusting a handful of compromised intermediate certificates, so Go programs no longer trust certificates issued through them.

Many of these are denial-of-service issues: an attacker sends crafted requests that make your server use too much memory or CPU, or crash. For internet-facing services, that’s a real risk.

The Go-specific catch: you must rebuild

In many languages, updating the runtime updates every app that uses it. Go is different. The standard library, including net/http and crypto/tls, is compiled into your binary.

That means:

• Updating Go on your laptop or CI runner doesn’t change binaries already built or deployed.
• A service built last month with Go 1.27.1 still contains the vulnerable code, even if your server now has Go 1.27.3 installed.
• The fix only reaches production when you rebuild with the new toolchain and redeploy.

You can check which Go version built any binary:

go version ./myservice

And for more detail, including module versions:

go version -m ./myservice

If it shows go1.27.2 or earlier on 1.27 (or go1.26.8 or earlier on 1.26), the binary needs a rebuild.

Step 1: Update your toolchain

Check your current version:

go version

You want Go 1.27.3 on the 1.27 line, or the latest 1.26 patch if you’re still on 1.26. Check the official Go release history page for the newest 1.26 release.

To pin the toolchain for your project, so everyone and every CI run uses the same patched version:

go get toolchain@go1.27.3

This adds a toolchain line to your go.mod, and Go downloads the right version automatically when needed.

Docker: update the base image in your build stage, for example:

FROM golang:1.27.3 AS build

Step 2: Update golang.org/x/net if you use it

Several HTTP/2 fixes also apply to golang.org/x/net, which some projects use directly or indirectly. Version v0.60.0 includes the fixes, and it requires Go 1.26 or newer:

go get golang.org/x/net@v0.60.0
go mod tidy

Step 3: Run govulncheck

govulncheck is the official Go vulnerability scanner. What makes it especially useful is that it checks whether your code actually calls the vulnerable functions, so it reports real exposure, not just every vulnerable package in your dependency tree.

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

You can also scan a built binary directly, which is useful for checking what’s actually deployed:

govulncheck -mode=binary ./myservice

Step 4: Rebuild, redeploy, and verify

Rebuild every service with the patched toolchain, deploy it, and confirm with go version ./myservice that the running binaries were built with the new version.

Don’t forget less obvious Go binaries:

• Internal tools and CLIs your team distributes
• Sidecars, operators, and controllers in Kubernetes
• Third-party Go tools you run in production. Check whether their maintainers have released new builds.

Step 5: Watch for tooling surprises

One project upgrading to Go 1.27 found that older golangci-lint versions couldn’t read Go 1.27’s compiled package data and had to upgrade golangci-lint as well. If your linters or other tools fail after updating Go, check for newer versions before assuming your code is broken.

Go 1.25 is out of support

Go supports only the two most recent major releases. With Go 1.27 out, Go 1.25 no longer receives security fixes, so it won’t get any of these patches. If you’re still on Go 1.25 or older, upgrade to Go 1.26 or, preferably, 1.27.

While you’re upgrading: what’s new in Go 1.27

If you’re moving to Go 1.27 for the first time, it’s one of Go’s most substantial releases in years:

• Generic methods: methods can now declare their own type parameters, a long-requested feature.
• encoding/json/v2 and encoding/json/jsontext are now available, and the new implementation becomes the default for JSON. If you hit compatibility problems, you can temporarily build with GOEXPERIMENT=nojsonv2.
• crypto/mldsa: post-quantum ML-DSA digital signatures, standardized in FIPS 204.
• A new built-in uuid package for generating and parsing UUIDs.
• An experimental, portable simd package for vector operations.
• The goroutine leak profile is now generally available, which helps find goroutines that never exit.
• Faster small memory allocations.
• New go fix modernizers to update older code patterns automatically.

Note that Go 1.27 needs macOS 13 Ventura or later on Macs.

Automate it

To stay on top of future releases:

• Add govulncheck to CI, so builds fail when reachable vulnerabilities appear.
• Use Dependabot or Renovate to update both Go modules and your Go toolchain version.
• Rebuild and redeploy regularly, not only when your own code changes. In Go, a security fix in the standard library only reaches production through a new build.

Practical recommendation

This week, for each Go service:

1. Run go version ./yourbinary on what’s deployed.
2. Update to Go 1.27.3 (or the latest 1.26 patch), and update golang.org/x/net if you use it.
3. Run govulncheck ./....
4. Rebuild and redeploy, then verify the deployed binary’s Go version.

Go makes deployment wonderfully simple: one static binary. The trade-off is that security fixes travel the same way, so no rebuild means no fix.

Sources: the Go release history on go.dev, the Go issue tracker for CVE-2026–111943, and October 2026 security update notes from Go projects on GitHub (uniqush-push, burrow, and websyncd), plus Go 1.27 release notes and coverage from JetBrains and daily.dev.

October 2026 has been one of the busiest months for Laravel security in years. There’s a critical PHP vulnerability, a critical framework advisory, fixes in Livewire, and a long list of patched dependencies, all within a few weeks.

Individually, each advisory is easy to handle. Together, they’re easy to fall behind on. In one public open-source Laravel project, a single composer audit reported 25 advisories across 8 packages before updates, and zero afterward.

This guide brings everything together into one checklist you can work through in under an hour per app.

Step 0: Get the full picture with composer audit

Before fixing anything, see what applies to your app. From your project root:

composer audit --locked

This checks the exact versions in your composer.lock against known security advisories, including packages you never installed directly, like those pulled in by Filament or Pulse. It’s the fastest way to see your real exposure.

Run it again at the end of this checklist to confirm everything is fixed.

Fix 1: Patch PHP itself (PHP2Shell)

The most urgent item isn’t in Laravel at all. PHP2Shell is a pair of critical PHP vulnerabilities, CVE-2026–109618 and CVE-2026–109619, allowing remote code execution without logging in. They were fixed on October 21 in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

Check every PHP version serving traffic, not just the CLI:

php -v
php-fpm8.3 -v

After updating, restart PHP-FPM and Laravel’s long-running processes, or they’ll keep running the old code:

sudo systemctl restart php8.3-fpm
php artisan queue:restart
php artisan horizon:terminate

A separate remote code execution flaw, CVE-2026–115560, was disclosed on October 23 and isn’t fixed by those releases. It only affects setups with session upload progress enabled. Check:

php -i | grep session.upload_progress.enabled

Unless you need that feature, turn it off in php.ini and restart PHP:

session.upload_progress.enabled = 0

Fix 2: Update the framework (token guard bypass and more)

Three framework advisories were fixed in recent releases:

• CVE-2026–114509 (critical, 9.2): the built-in token guard could be tricked into signing in as another user on MySQL and MariaDB. It only affects apps using 'driver' => 'token'; Sanctum and Passport aren’t affected. Fixed in 12.68.0 and 13.29.0.
• CVE-2026–114508: in apps using JSON:API resources, a crafted, nested include parameter could trigger relationship loading that destroyed data in a related table. It affects 12.45.0 up to 12.68.0, and 13.x before 13.27.0.
• CVE-2026–102279 (low): a cross-site scripting issue in the debug error page. Fixed in 12.69.0 and 13.30.0.

The simple answer is to update to the latest patch of your major version:

composer update laravel/framework --with-all-dependencies

If you’re on Laravel 11 or older, there are no fixes. Plan your upgrade to Laravel 12 or 13. Laravel 12 receives security fixes until February 24, 2027.

Fix 3: Update Livewire (even if you didn’t install it)

Livewire 4.4.8 fixes an advisory (GHSA-mhf7-xp6r-6qrc) involving parameter key confusion in the #[Authorize] attribute, which could affect how authorization checks are applied to component actions.

Many apps use Livewire indirectly, through Filament, Laravel Pulse, or starter kits, so it may not appear in your composer.json. Check what’s installed:

composer show livewire/livewire

If you use #[Authorize] in your components, see where:

grep -rn "#\[Authorize" app/

Then update:

composer update livewire/livewire

ivewire has had serious issues before, including a critical remote code execution flaw in v3 last year, so keeping it current is especially important.

Fix 4: Update the packages under your app

Laravel apps depend on dozens of packages you rarely think about. Recent advisories have affected packages like:

• guzzlehttp/guzzle, the HTTP client used by Laravel’s Http facade
• league/flysystem, behind Laravel’s Storage
• symfony/yaml and other Symfony components
• Development tools like psy/psysh, used by php artisan tinker, and phpunit

The safest approach is a full, tested update:

composer update --with-all-dependencies

Then run your test suite before deploying. If a full update is too risky right away, update only the packages that composer audit lists.

Fix 5: Turn off debug mode in production

The debug page XSS is a reminder of a long-standing rule: production should never run with APP_DEBUG=true. Debug pages can expose environment variables, database details, and stack traces, which is a gift to attackers.

Check quickly:

php artisan about

Look at the Debug Mode line. In production, your .env should contain:

APP_ENV=production
APP_DEBUG=false

After changing it, refresh the cached configuration:

php artisan config:cache

Fix 6: Review your API authentication

If any app still uses the old token guard, this month is a good reason to move on:

• Find it: grep -n "'driver' => 'token'" config/auth.php
• Short term: update the framework, and enable token hashing ('hash' => true) if you haven’t.
• Long term: migrate to Laravel Sanctum, which supports hashed tokens, expiry, abilities, and revocation.

Also review every route that accepts user input for authentication or lookups, and validate types explicitly, for example with 'token' => ['required', 'string']. This month’s bug happened because a value expected to be a string wasn’t checked.

Fix 7: Automate this so it doesn’t happen again

Manual check-ups are useful, but automation catches problems the day they’re published.

Add composer audit to CI. It returns an error when advisories are found, so a GitHub Actions step fails your build:

- name: Check for vulnerable packages
  run: composer audit --locked

Enable Dependabot or Renovate for Composer, so security updates arrive as pull requests automatically.

Subscribe to security news. Watch the GitHub Advisory Database for your key packages, and follow Laravel-focused security newsletters.

Keep PHP and Laravel on supported versions. Many of this month’s fixes simply don’t exist for older versions.

The one-hour checklist

For each Laravel app:

1. Run composer audit --locked and save the output.
2. Update PHP to a patched version, and restart PHP-FPM and workers.
3. Disable session.upload_progress.enabled unless you need it.
4. Update laravel/framework to the latest patch.
5. Update livewire/livewire, even if it’s only an indirect dependency.
6. Run composer update --with-all-dependencies and your tests.
7. Confirm APP_DEBUG=false in production.
8. Check for the old token guard, and plan a move to Sanctum if you find it.
9. Run composer audit --locked again and confirm it’s clean.
10. Add composer audit to CI and enable automated dependency updates.

Practical recommendation

Don’t treat this month’s advisories one by one. Block out an hour per app this week, work through the checklist, and set up the automation in step 10. The next advisory will come; what matters is whether your process catches it in hours or months.

Sources: Laravel advisories GHSA-f9x3–7vq9-cph6, GHSA-5wcm-3v2w-8362, and GHSA-jh5r-qr3c-85q8; Livewire advisory GHSA-mhf7-xp6r-6qrc; Corgea research; Laravel News; Brandefense; Securing Laravel; PHP security release notes; and a public dependency security update in the DLSite-List project on GitHub (October 2026).