kuvasz-uptime/kuvasz 4.3.0

v4.3.0

on GitHub

Documentation: v4.3.0 - kuvasz-uptime.dev

docker pull kuvaszmonitoring/kuvasz:4.3.0

Features

Three new integrations joined the family, so you can reach more places without hand-crafting a webhook payload for them:

• Microsoft Teams posts Adaptive Cards to a channel or a chat, color-coded by the severity of the event. It's built on the Workflows app, so it isn't affected by the retirement of the Microsoft 365 (Office 365) Connectors.
• Apprise hands your notifications to a self-hosted Apprise API instance, which forwards them to 80+ services at once — ntfy, Gotify, Matrix, SMS providers and many more — so you don't have to wire them up one by one.
• Pushover sends push notifications to your phone, tablet and desktop, and can escalate an outage to its emergency priority, which repeats until someone acknowledges it.

All three behave like every other integration: they can be global or assigned to specific monitors and maintenance windows, their events can be filtered with excluded-events, and they're testable right from the UI, the REST API and the MCP server. If you were reaching any of them through a custom webhook until now, you can drop the payload template and replace the whole setup with a handful of properties.

Security

• Relative redirects were resolved against the wrong hop (GHSA-jq3w-22qh-gf8w): when an HTTP monitor followed a chain of redirects, a relative Location header was always resolved against the monitor's own URL instead of the URL of the hop that actually returned it. A chain like https://a.example → https://b.example/deep/path → Location: /next was followed to https://a.example/next rather than https://b.example/next. Besides checking a completely different resource than the one the hop pointed at, this let an intermediate hop steer the check to an arbitrary path on the monitored origin - with the monitor's own request method, body and custom headers attached - even when that origin is only reachable from Kuvasz itself. Relative locations now follow RFC 9110 and are resolved against the hop that returned them. Reported by @CaptBoykin.

Enhancements

• Redirect chains are capped: the new app-config.http-check-max-redirects property (10 by default) limits how many redirects a single HTTP check follows. Redirect loop detection only recognizes a repeated URL, so a chain where every hop is different was previously followed without an upper bound. Exceeding the limit now marks the monitor DOWN with a dedicated error.

Full Changelog: 4.2.0...4.3.0