nginx | 05/16/2026 | By Thijs Eilander

Angie 1.11.5 Released: 5 Security Fixes Explained

Angie 1.11.5 has landed, and this is one of those releases where the tiny version bump hides a very loud message: update your server. The official Angie 1.11.5 release ships five security fixes, including hardening for rewrite processing, OCSP handling, HTTP/3, SCGI/UWSGI proxying, and charset decoding. If your site is public-facing, this is not a “maybe later” patch. It is a “put the coffee down and schedule the update” patch.

If you want the ready-to-deploy version with performance tuning, modern TLS, and a truckload of useful modules already lined up, have a look at our Angie stack. That page is the home base for our Angie packages, modules, optimizations, and build choices.

Angie 1.11.5 security fixes overview

What changed in Angie 1.11.5?

In plain English: Angie 1.11.5 is a security release. No glitter cannon. No “look mum, new dashboard” moment. Just five fixes that close doors you do not want strangers testing at three in the morning.

The upstream release notes list these issues:

  • CVE-2026-42945 in rewrite processing, where a specific chain of unnamed captures and query strings could crash a worker process and, on systems without address space randomization, open the door to worse.
  • CVE-2026-40701 in ssl_ocsp handling, where freed memory could still be touched while processing DNS responses.
  • CVE-2026-40460 in HTTP/3, where IP spoofing could bypass restrictions or authorization in some setups.
  • CVE-2026-42946 for scgi_pass or uwsgi_pass, where a malicious upstream response could trigger excessive memory allocation, over-read data, leak worker memory, or crash the process.
  • CVE-2026-42934 in charset_map UTF-8 decoding, where a specially crafted response could cause an out-of-bounds read.

That is a lot of security mileage from one patch release. Or, to put it less politely: if you expose Angie to the internet, skipping this update is like locking your front door and leaving the kitchen window open because “it is only a small window”.

Why this release matters more than the version number suggests

Patch releases are often treated like the salad on the plate. Everyone knows it is probably good for them, but the burger of “I will do it next week” usually wins. Angie 1.11.5 is not that kind of patch.

Several of these fixes touch things people actually enable in real deployments: rewrite rules, OCSP, HTTP/3, SCGI, UWSGI, and character set handling. In other words, this is not a museum-piece bug collection. These are features that show up in reverse proxies, WordPress stacks, app gateways, and API frontends every day.

That is why the Angie 1.11.5 release matters. It is security work in boring clothes. And boring clothes are exactly what you want from infrastructure. If your web server is exciting, something has usually gone very wrong.

The five Angie 1.11.5 fixes, explained like a normal person

1. Rewrite rules stop being crash bait

The rewrite bug is the kind of thing that makes config-heavy setups nervous. If you use rewrite logic with capture groups such as $1 and query strings, a specially crafted request could crash workers under the right conditions. Angie 1.11.5 closes that hole. If your config contains clever rewrite gymnastics, this fix is your sign to stop living dangerously.

2. OCSP handling gets safer

OCSP is part of certificate validation. It helps your server decide whether a certificate should still be trusted. The fixed bug involved use-after-free behaviour while processing DNS replies. That is fancy developer language for “the software might touch memory it already threw away”. Computers hate that. Attackers love that. Angie 1.11.5 removes that risk.

3. HTTP/3 gets a real security cleanup

HTTP/3 is fast, modern, and a little bit dramatic, because every new protocol arrives with its own box of edge cases. In this release, Angie fixes a bug where attackers could spoof IP addresses in some HTTP/3 configurations and bypass restrictions or authorization. If you turned on HTTP/3 because you enjoy low latency and shiny transport layers, yes, you also want this fix.

4. SCGI and UWSGI deployments get more robust

If your Angie server sits in front of Python apps, legacy gateways, or service layers that use SCGI or UWSGI, one upstream flaw could make the server allocate too much memory, read beyond safe bounds, leak process memory, or crash. None of those outcomes are cute. Angie 1.11.5 tightens this area up.

5. Charset decoding stops peeking where it should not

The final fix deals with UTF-8 decoding via charset_map. A specially crafted response could trigger an out-of-bounds read, which is a clean way of saying the worker process might read data from the wrong place. Best case: crash. Worst case: it leaks bits of memory. Also not the sort of surprise you want from your web server.

Where our Angie stack fits in

If you are not in the mood to hand-roll every package, module, and TLS detail yourself, this is where our Angie stack earns its keep. We package Angie as a drop-in replacement for NGINX, with the same configuration style but with Angie’s newer core features, including native ACME support and the richer status API.

Our Angie page also covers the practical bits people actually care about: dynamic modules, build optimizations, OpenSSL integration, PQC readiness, and supported Debian and Ubuntu releases. If you are building a serious edge stack, it is the shortest path from “I heard Angie exists” to “this thing is actually running on my server”.

Useful starting points:

Should you update right now?

Short answer: yes, if the server is exposed to the internet. Extra yes if you use HTTP/3, OCSP, SCGI, UWSGI, or complicated rewrite rules. Extra-extra yes if the phrase “we have been meaning to patch that box for a while” just made someone on your team look at the floor.

The sensible approach is simple: update in staging, test the obvious paths, then promote to production. Angie is designed as a drop-in replacement for NGINX, so this should not turn into a Greek tragedy. Still, do the grown-up thing and test. Confidence is nice. Rollback plans are nicer.

And if you are evaluating whether Angie is the right move at all, compare it with Angie vs NGINX. If you already run Angie, Angie 1.11.5 is the sort of release that rewards fast patching and quiet operations. Which, frankly, is the dream.

Frequently Asked Questions

What is Angie 1.11.5?

Angie 1.11.5 is a security-focused release of the Angie web server. It brings five upstream fixes for issues affecting rewrite processing, OCSP, HTTP/3, SCGI/UWSGI proxying, and charset decoding.

Do I need to update if my server seems fine?

Yes. Security bugs rarely send a polite calendar invite before causing trouble. A server that “seems fine” can still be vulnerable, especially when the issues involve request handling and protocol parsing.

Does Angie 1.11.5 matter if I use HTTP/2 and not HTTP/3?

Yes, because HTTP/3 is only one of the five fixes. The release also hardens rewrite logic, OCSP handling, SCGI/UWSGI behaviour, and charset decoding. Even if HTTP/3 is disabled, the other fixes may still apply to your setup.

Is Angie really a drop-in replacement for NGINX?

In most real-world cases, yes. Angie keeps NGINX-compatible configuration syntax, so existing configs usually carry over cleanly. That is one of the reasons it is attractive for admins who want newer features without rewriting their whole stack.

Where can I get a packaged Angie build for Debian or Ubuntu?

You can start on our Angie stack page, which links to the repository setup, package details, modules, and related Docker images. It is the fastest route if you want Angie without spending the afternoon compiling things by hand like it is 2009.

Related Posts