# Security Releases for Icinga 2 and Icinga Web

**URL:** <https://community.icinga.com/t/security-releases-for-icinga-2-and-icinga-web/15632>\
**Category:** Icinga 2\
**Tags:** release\
**Created:** [October 29, 2026, 7:35am UTC](https://community.icinga.com/t/security-releases-for-icinga-2-and-icinga-web/15632 "2026-10-29T07:35:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![theFeu](https://community.icinga.com/user_avatar/community.icinga.com/thefeu/32/7277_2.png) [@theFeu](https://community.icinga.com/u/theFeu)\
**Post date:** [October 29, 2026, 7:35am UTC](https://community.icinga.com/t/security-releases-for-icinga-2-and-icinga-web/15632/1 "2026-10-29T07:35:16Z")

</div>

Icinga 2 v2.16.6 and v2.15.7 and Icinga Web v2.14.1 and v2.13.2 are out.  
**All four releases fix security issues, so we recommend upgrading as soon as possible.**

The most severe ones:  
Icinga Web: the standalone chart endpoints let attackers read files and overload the server without logging in. We removed the endpoints entirely.

Icinga 2: the default mail notification scripts allowed command line argument injection through the recipient email address. With GNU mailutils, this can lead to arbitrary command execution.

The releases also fix API issues that could crash the daemon or expose objects users shouldn’t see, plus log injection and a few privilege problems in Icinga Web.

**Icinga Web v2.12 and earlier receive no fixes. If you’re still on one of those, move to v2.13.2 or later.**

Thanks to everyone who reported these issues responsibly, including Alessandro Mizzaro, moreamazingnick, and archnexus707.

All details, advisories and upgrade notes: [https://icinga.com/blog/icinga-2-v2-16-6-and-icinga-web-v2-14-1/](https://icinga.com/blog/icinga-2-v2-16-6-and-icinga-web-v2-14-1/)

---

<div class="post-metadata">

**Author:** ![theFeu](https://community.icinga.com/user_avatar/community.icinga.com/thefeu/32/7277_2.png) [@theFeu](https://community.icinga.com/u/theFeu)\
**Post date:** [October 29, 2026, 7:35am UTC](https://community.icinga.com/t/security-releases-for-icinga-2-and-icinga-web/15632/2 "2026-10-29T07:35:44Z")

</div>



---

<div class="post-metadata">

**Author:** ![moreamazingnick](https://community.icinga.com/user_avatar/community.icinga.com/moreamazingnick/32/7725_2.png) [@moreamazingnick](https://community.icinga.com/u/moreamazingnick)\
**Post date:** [October 29, 2026, 8:08am UTC](https://community.icinga.com/t/security-releases-for-icinga-2-and-icinga-web/15632/3 "2026-10-29T08:08:29Z")

</div>

> [@theFeu](#):
>
> Icinga Web v2.12 and earlier receive no fixes. If you’re still on one of those, move to v2.13.2 or later.

or if you really need to stay in IcingaWeb2 2.12.\* which is a bad idea you can block the path using apache2 config

```auto
<LocationMatch "^/icingaweb2/(svg|png)/chart\.php$">
    Require all denied
</LocationMatch>

```

The rule above works for standard installations but needs adaptation for installations which do not have icingaweb2 in the url path like:

> **[Icinga Enterprise Monitoring Demo | Dashboards, Alerts & Automation](https://demo.icinga.com/authentication/login)**
>
> Access the Icinga demo and explore open source infrastructure monitoring with live dashboards, alerting, automation, and scalable architectures.

---

<div class="post-metadata">

**Author:** ![tyler\_grant](https://community.icinga.com/letter_avatar_proxy/v4/letter/t/aca169/32.png) [@tyler\_grant](https://community.icinga.com/u/tyler_grant)\
**Post date:** [November 2, 2026, 3:28am UTC](https://community.icinga.com/t/security-releases-for-icinga-2-and-icinga-web/15632/4 "2026-11-02T03:28:37Z")

</div>

I had the same issue with a custom basepath for icingaweb2 I just added a leadding slash in the LocationMatch pattern and it worked for me