[BUG] Refresh the self-contained Lidarr payload from .NET 8.0.12

[Feberdin]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

The self-contained Lidarr payload in the public image lscr.io/linuxserver/lidarr:latest at digest sha256:bfec0ec2dc351fa5928379d785b08be395886f109393b9040ed7973bd1008060 includes .NET 8.0.12 runtime components.

Fixed patch releases are available:

• Microsoft.AspNetCore.App.Runtime.linux-musl-x64 8.0.12: 8.0.21 or newer fixes CVE-2025-55315; later .NET 8 patches include additional fixes.
• Microsoft.NETCore.App.Runtime.linux-musl-x64 8.0.12: 8.0.29 or newer fixes CVE-2026-47302, CVE-2026-50524, CVE-2026-50528, CVE-2026-50651, and CVE-2026-57108.

The image label is 3.1.0.4875-ls38 and its creation timestamp is 2026-08-05T04:33:02.117520988Z. This is a bundled runtime maintenance report; no Lidarr application-level exploitability is claimed.

Expected Behavior

The current public image should include a self-contained Lidarr payload built with a supported, security-patched .NET 8 runtime.

Steps To Reproduce

1. Inspect the immutable public image digest listed above for the x86-64 platform.
2. Scan it with Trivy 0.73.0 and Grype 0.116.1.
3. Observe the embedded .NET 8.0.12 runtime components.
4. Compare them with the fixed patch releases listed above.

The Dockerfile downloads the self-contained Lidarr release archive, so the runtime is part of that payload rather than a separately installed Alpine package.

Environment

• OS: Public image artifact; detected base is Alpine 3.24.1
• How docker service was installed: Not applicable; reproduction operates on the public registry artifact and does not require a running container

CPU architecture

x86-64

Docker creation

Not applicable; no container needs to be created to reproduce the embedded runtime versions.

Container logs

Not applicable; the finding is present in the immutable image layers before container startup.

Suggested remediation

1. Coordinate or consume a Lidarr release built with a current supported .NET 8 patch runtime.
2. Rebuild the image with that release archive.
3. Publish an immutable digest and verify that .NET 8.0.12 is absent.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[Roxedus]

Dear sloperator(if this term made you feel things, it was the purpose), please read this post before letting your agents loose. A ban could follow.
https://www.linuxserver.io/blog/image-vulnerability-scanning-and-you

[Feberdin]

You are right. I should have verified component ownership and practical applicability, and I should have read the LinuxServer.io reporting guidance before opening multiple scanner-driven issues. That was my mistake. Sorry for the noise and the unnecessary triage work. I will not refile these findings here.