Sonarr - Tag - arleo.euhttps://www.arleo.eu/en/tags/sonarr/Sonarr - Tag - arleo.euHugo -- gohugo.ioenMon, 25 May 2026 20:51:17 +0200Postmortem — CrowdSec AppSec: Heuristic False Positive on Sonarr/Radarrhttps://www.arleo.eu/en/posts/postmortem-crowdsec-appsec-false-positive-sonarr/Mon, 25 May 2026 20:51:17 +0200Jmrhttps://www.arleo.eu/en/posts/postmortem-crowdsec-appsec-false-positive-sonarr/

Summary

On May 25, 2026 at around 10:02 PM (local time), Sonarr and Radarr became completely inaccessible from the home IP (82.XX.XX.XX), returning 403 on every URL including /login. The service was fully operational. Initial suspicion fell on the day’s crowdsec-cf-sync refactor deployment — the real cause was a CrowdSec AppSec heuristic false positive.

Timeline

Time (local) Event
~10:00 PM Sonarr browser session cookie expired
10:02:31 PM Browser loads Sonarr library → attempts to fetch 20+ /MediaCover/*.jpg simultaneously
10:02:31 PM Sonarr returns 302 → /login for each image (invalid session)
10:02:34 PM SignalR WebSocket connection succeeds (101) via access_token in URL
~10:05 PM CrowdSec AppSec triggers heuristic rule http-probing: burst of failed requests from same IP
10:11:37 PM All requests from 82.XX.XX.XX return 403 — cs_reason=heuristic in nginx logs
10:13:34 PM Even /login is blocked — IP cannot authenticate

Root Cause

CrowdSec AppSec maintains an in-memory heuristic state, separate from LAPI decisions. When the browser simultaneously tries to load many resources and receives 302/403 from the upstream application (Sonarr), AppSec interprets the burst of failures as aggressive probing (http-probing) and blocks the source IP.

]]>