LoginSign Up
← Back to all sparks
I

Icinga

INFRA · APIS
Velocity5.0

Open-source infrastructure and network monitoring system

icinga.com ↗

Icinga 2 is fixing the same API permission holes across every supported branch.

monitoringsecurity-fixesapi-permissionsclusteringbackportsself-hosted
◆Current state
Icinga 2 ships security fixes as simultaneous releases across its 2.14, 2.15, and 2.16 branches, and has now done so twice in five weeks. The 18 August pair - v2.16.5 and v2.15.6, tagged 25 seconds apart - closes an events/* permission bypass on /v1/events and a memory-exhaustion path where a node could crash another using the 1 GB message limit, now capped at 16 MiB for messages from lower in the hierarchy. v2.16.5 additionally repairs an IcingaDB regression introduced in v2.16.0.
◆Where it's heading
The recurring theme is that the API's filter and permission model was more permissive than intended. July's critical release introduced a filter-expression permission so DSL filters in API queries can be restricted per user, with enforcement deliberately deferred to v2.17; August's pair fixes filter expressions on /v1/events not being permission-checked at all. Cluster message handling is being tightened in parallel. The project is clearly working through an audit of the API surface, and it is backporting every finding rather than pushing users onto the newest branch.
◆Prediction
Enforcement of the filter-expression permission is already scheduled for v2.17, so that release should be the one where the opt-in restrictions become mandatory - expect more backported API permission fixes across all three branches before it lands.

◆Recent moves

  1. 1d ago

    v2.16.5: /v1/events permission bypass and node memory exhaustion fixed

    Two vulnerabilities closed - an authenticated ApiUser with events/* could read objects through crafted filter expressions without objects/query/* permission, and a node could exhaust another node's memory via the 1 GB message limit, now capped at 16 MiB - plus a fix for an IcingaDB regression dating to v2.16.0. The permission bug is the same class the July filter-expression work was addressing.

    View source ↗
  2. 1d ago

    v2.15.6: the 2.15-branch twin of the August security fixes

    The 2.15-branch release carrying the same two security fixes as v2.16.5, tagged within half a minute of it and without the IcingaDB regression fix. Icinga's standard practice of shipping a security fix simultaneously to every supported branch.

    View source ↗
  3. 1mo ago

    Fixes API auth regression and hanging endpoint connections

    A regression from v2.16.0 that broke API authentication for clients sending HTTP Basic Auth only after being asked, endpoint connections that could hang indefinitely and block further attempts until restart, and OpenSSL compatibility. Operationally the most disruptive of the recent bugs.

    View source ↗
  4. 1mo ago

    Security release for the 2.14 branch, adds filter-expression permission

    Critical fixes including two allowing an unauthenticated attacker to take over or crash the process over the network, plus the new filter-expression permission restricting which API users may use DSL filters. Enforcement is opt-in until v2.17 because the change is incompatible.

    View source ↗
  5. 1mo ago

    Security release for the 2.15 branch

    The 2.15 twin of the same July security release, with an identical body. One of three branch releases published within two minutes of each other.

    View source ↗
  6. 1mo ago

    Security release for the current 2.16 branch

    The 2.16 member of the July trio, carrying the same critical fixes and the filter-expression permission. Together the three releases show Icinga backporting security work rather than forcing branch upgrades.

    View source ↗