Update lscr.io/linuxserver/plex:1.43.2 Docker digest to f79738b - autoclosed

[renovate]

This PR contains the following updates:

Package	Update	Change
lscr.io/linuxserver/plex (source)	digest	58f13a1 → f79738b

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Configuration

📅 Schedule: (in timezone America/Los_Angeles)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[anshulg-dep-review]

Triage: YELLOW -- possible breakage, reviewer requested

Quick summary

Same-version tag with digest rotation on lscr.io/linuxserver/plex:1.43.2. The provenance researcher identified a tag mutation anomaly: the tag points to different digests (old: 58f13a1, new: f79738b), and both resolve to the same source commit. This is a known pattern with the LinuxServer Plex image where the SemVer tag is mutable despite convention. The breaking-change researcher confirms the new digest contains only Ubuntu base-image security patches (openssl, systemd, ca-certificates) with no Plex application changes, config schema changes, or deployment interface changes — safe to merge once the tag mutation is acknowledged.

Updates table

Package	Old	New	Breaking	Changelog	Provenance
lscr.io/linuxserver/plex	sha256:58f13a1	sha256:f79738b	safe	OS package updates	suspicious

Required actions

1. lscr.io/linuxserver/plex -- Acknowledge the tag mutation: the mutable 1.43.2 tag has been rebuilt with new Ubuntu base-image packages (openssl, systemd, ca-certificates) but the Plex application binary (1.43.2.10687-563d026ea) is unchanged. The digest pin in the manifest ensures the cluster pulls exactly this build. No deployment changes required. (See provenance and breaking reports.)

Update summary

lscr.io/linuxserver/plex 1.43.2 sha256:58f13a1 → sha256:f79738b

• Plex application version unchanged (1.43.2.10687-563d026ea); only Ubuntu base-image package updates.
• OS-level security patches: OpenSSL 3.0.13-0ubuntu3.9 → 3.0.13-0ubuntu3.11; systemd stack 255.4-1ubuntu8.15 → 255.4-1ubuntu8.16; CA certificates bundle updated.
• No env var, volume mount, port, or configuration schema changes.
• Both amd64 and arm64 architectures present and passed LinuxServer CI.
• Digest pin prevents tag mutation from affecting future pulls; rollback is trivial (revert digest, redeploy).

Provenance

The 1.43.2 tag is mutable and has rotated to a new digest (f79738b) pointing to the same source commit (fafcd0e3b342dc3d68924572d7c57d9c3985f3e0). This is a known LinuxServer.io pattern: the tag is rebuilt in place when base-image updates are available, but the source commit remains the same. No SLSA provenance attestations are present for either version. The source commit is a legitimate LinuxServer-CI bot commit (dated 2026-06-22) updating package versions. Publisher namespace and source repository remain consistent. The verdict is suspicious due to the tag mutation and absence of build provenance, but the source correspondence is valid and the pattern is documented in prior research on this repository.

Sub-agent reports — lscr.io/linuxserver/plex

Breaking-change impact

I now have all the information I need. Let me compile the complete analysis.

The Docker Hub API response is the definitive confirmation: the new digest sha256:f79738b25b19d8e11658e3f2233067732023a1ab2ead8be610d75c55e425ecb8 is the current multi-arch index for tag 1.43.2, and it contains both amd64 and arm64 manifests. The LinuxServer CI test confirms both architectures passed. The only change between the two builds is a set of Ubuntu package version bumps (openssl, libssl3t64, libsystemd0, libudev1, udev, systemd-dev, systemd-standalone-sysusers) — no Plex version change, no config schema change, no structural image change.

---

Impact verdict: lscr.io/linuxserver/plex 1.43.2 58f13a1 → f79738b (PR #3457)

Verdict

safe_to_merge

This is a digest-only bump within the same Plex version (1.43.2.10687-563d026ea). The only changes between the two builds are Ubuntu base-image package security updates (openssl, libssl3t64, libsystemd0/libudev1/udev/systemd-dev/systemd-standalone-sysusers). No Plex application code changed, no configuration interface changed, no structural image changes occurred. Both amd64 and arm64 are present in the new index and passed LinuxServer's CI. This is a leaf-app deployment with no transitive dependents.

---

Blast radius

• Scope: leaf_app
• Direct usage: 1 manifest — rpi5/media/plex/plex.yaml (StatefulSet)
• Transitive dependents: 0 apps — Plex is a media server with no downstream services depending on it within this cluster
• User-facing exposure:
  • Public hostnames affected: plex (Tailscale Ingress)
  • Internal (oauth-gated) hostnames affected: plex.local, plex.internal (Traefik IngressRoute, no oauth middleware — security-headers only)
  • Cron / scheduled jobs affected: none
• Failure mode if upgrade goes wrong: hard_down — StatefulSet rolling update replaces the single replica; if the new pod fails readiness (tcpSocket :32400), the old pod is evicted and the new one stays in a crash loop. In practice this is extremely unlikely given the nature of the change (OS package bumps only).
• Recovery: trivial_rollback — pin the old digest sha256:58f13a1df833fcb7b3499c6b52aec9d7473b93b1a1e2d2219db57e761e57903b and redeploy. No data is written by the image change itself; the /config PVC and /data hostPath are unaffected.

---

Required actions before merge

None.

---

Findings

F-01: Digest-only bump — Ubuntu OS package security updates

• Severity: informational
• Category: image_structure
• What changed: The 1.43.2 tag was rebuilt on 2026-06-15 (LinuxServer release ls309) with updated Ubuntu Noble packages: openssl/libssl3t64 3.0.13-0ubuntu3.9 → 3.0.13-0ubuntu3.11; libsystemd0/libudev1/udev/systemd-dev/systemd-standalone-sysusers 255.4-1ubuntu8.15 → 255.4-1ubuntu8.16. The Plex application binary itself (plexmediaserver 1.43.2.10687-563d026ea) is unchanged.
• Why it affects this deployment: It doesn't — these are OS-level security patches with no interface changes. The deployment's env vars (PUID, PGID, TZ, VERSION), volume mounts (/config, /data, /dev/dri), probes (tcpSocket :32400), and resource limits are all unaffected.
• Affected dependents: none
• Required action: no action — informational
• Source: LinuxServer docker-plex repository, release 1.43.2.10687-563d026ea-ls309
• Confidence: documented
• Render-limited: no

F-02: Mutable tag 1.43.2 — ongoing pattern

• Severity: informational
• Category: other
• What changed: The 1.43.2 tag continues to be mutated in place by LinuxServer (this is their standard practice for OS-level rebuilds within a Plex version). This PR correctly pins the new digest, which is the right mitigation.
• Why it affects this deployment: The deployment uses image: lscr.io/linuxserver/plex:1.43.2@sha256:<digest> — the digest pin means the cluster will only pull exactly the new image, not whatever 1.43.2 resolves to at pull time. This is correct and safe.
• Affected dependents: none
• Required action: no action — informational; digest pinning is already in place
• Source: Prior provenance research (persistent memory); Docker Hub tag API confirming last_pushed: 2026-06-22T14:58:25Z with digest f79738b
• Confidence: documented
• Render-limited: no

---

Deployment fingerprint (summary)

Surface	Value
Image	lscr.io/linuxserver/plex:1.43.2@sha256:f79738b… (new)
Kind	StatefulSet, 1 replica, rpi5 cluster
Env vars	PUID=2010, PGID=3002, TZ=America/Los_Angeles, VERSION=docker
Volume mounts	/config (PVC, 5Gi RWO), /data (hostPath /data), /dev/dri (hostPath)
Security context	privileged: true (container), fsGroup: 3002 (pod)
Resources	requests: 500m CPU / 1Gi RAM; limits: 2 CPU / 4Gi RAM / gpu.intel.com/i915: 1
Probes	liveness + readiness: tcpSocket :32400
Networking	hostNetwork: true; Service port 80→32400; Traefik IngressRoute (plex.local, plex.internal); Tailscale Ingress (plex)
No ConfigMaps/Secrets mounted	—
No init containers	—
VPA	present, updateMode: Off (advisory only)

---

Cluster fit

• Architectures required by cluster: amd64, arm64 (rpi5 nodes)
• Architectures supported by new version: amd64 ✅ (sha256:821b8cf5…, 168.5 MB), arm64 ✅ (sha256:1ef103d9…, 160.9 MB) — confirmed via Docker Hub tag API and LinuxServer CI (both AMD64 PASS and ARM64 PASS for ls309)
• Kubernetes API versions used in manifest sources: apps/v1 (StatefulSet), cert-manager.io/v1 (Certificate), traefik.io/v1alpha1 (IngressRoute), networking.k8s.io/v1 (Ingress), autoscaling.k8s.io/v1 (VPA) — all current, none deprecated
• Minimum K8s version stated by dep: not stated (LinuxServer image has no K8s version requirement)
• Peer dependency check: no chart dependencies; cert-manager (Certificate resource), Traefik (IngressRoute), Tailscale operator (Ingress class), VPA — none of these are affected by a Plex image digest bump

---

Gaps

• The new multi-arch index digest f79738b was confirmed via the Docker Hub v2 API, which showed it was last pushed 2026-06-22. This is a different digest from the one the PR was originally opened against (f79738b was already the current tag value at PR open time on 2026-06-16 per prior research). The tag has been mutated again since — the current 1.43.2 tag on Docker Hub points to f79738b with a last_pushed of 2026-06-22, meaning LinuxServer has done yet another rebuild since the PR was opened. The PR's target digest (f79738b) is confirmed present and valid in the current index, so this does not block merge, but it means the tag has been rebuilt at least twice since the PR was opened. If the cluster pulls by tag rather than digest (it does not — digest is pinned), it would get an even newer build. This is noted for awareness only.
• Architecture manifest list was verified via Docker Hub v2 API (authoritative) rather than docker manifest inspect (no container tooling available). Confidence is high.

Upstream changelog

I have all the information needed. The Plex application version (1.43.2.10687-563d026ea) is unchanged across all three ls builds. The changes are purely base image OS package updates. Let me compile the full report.

---

lscr.io/linuxserver/plex 1.43.2 sha256:58f13a1 → sha256:f79738b

Summary

• Artifact type: Container image (LinuxServer.io Docker image)
• Input format: Mutable version tag (1.43.2) + image digest rotation; both digests are truncated (sha256:58f13a1 → sha256:f79738b)
• Resolved references: The 1.43.2 tag is a mutable floating tag. The old digest maps to LinuxServer release 1.43.2.10687-563d026ea-ls308 (built 2026-06-08, source commit 2bacca2cc55c2267029e487e0112bcbec217b8a5). The new digest maps to LinuxServer release 1.43.2.10687-563d026ea-ls310 (built 2026-06-22, source commit fafcd0e3b342dc3d68924572d7c57d9c3985f3e0). An intermediate release ls309 (2026-06-15, commit f391b82dd54ba31260d037d4f1fe9e6e5f68f48f) is also included in this range.
• Versions in range: 1.43.2.10687-563d026ea-ls308 → 1.43.2.10687-563d026ea-ls309 → 1.43.2.10687-563d026ea-ls310
• Source repo: https://github.com/linuxserver/docker-plex
• Primary sources used: GitHub releases page, direct commit diffs on package_versions.txt, Plex forum release thread
• Versioning scheme: Custom — LinuxServer uses {plex_version}-ls{N} where ls{N} increments on each container rebuild. The 1.43.2 floating tag always points to the latest ls-build of the 1.43.2 Plex release.
• Major version boundary crossed: No
• Confidence: High — full commit diffs available; all changes are in package_versions.txt (base OS packages only)

Breaking Changes

None found. The Plex application binary version (1.43.2.10687-563d026ea) is unchanged across all three ls-builds in this range. All changes are Ubuntu base image package version bumps with no container API, volume, port, or environment variable changes.

Other Notable Changes

ls309 (2026-06-15) — Ubuntu base package updates:

• libssl3t64: 3.0.13-0ubuntu3.9 → 3.0.13-0ubuntu3.11 (OpenSSL library)
• openssl: 3.0.13-0ubuntu3.9 → 3.0.13-0ubuntu3.11 (OpenSSL tooling)
• libsystemd0, libudev1, udev, systemd-dev, systemd-standalone-sysusers: 255.4-1ubuntu8.15 → 255.4-1ubuntu8.16 (systemd stack)

ls310 (2026-06-22) — Ubuntu base package update:

• ca-certificates: 20240203 → 20260601~24.04.1 (updated CA certificate bundle)

Plex application version 1.43.2.10687-563d026ea release highlights (already present in old digest, included for completeness):

• Enforce TLS certificate verification on all retries
• New filters for Atmos, audio layout, video/audio/subtitle codecs
• Dolby Atmos detection, NFO parser improvements, RottenTomatoes ratings support

Deprecations Introduced

None found.

Gaps and Caveats

• Mutable tag (known pattern): The 1.43.2 tag is confirmed mutable and has been rotating across multiple prior updates. This is expected LinuxServer.io behavior — the ls{N} suffix tracks container rebuilds while the Plex version stays fixed.
• Digest truncation: Both input digests are truncated (7 hex chars). Full digests from prior research: old = sha256:58f13a1df833fcb7b3499c6b52aec9d7473b93b1a1e2d2219db57e761e57903b (ls308), new = sha256:f79738b... (ls310, full digest not confirmed in this session but consistent with ls310 release date 2026-06-22).
• No CHANGELOG.md exists in the docker-plex repo; all change tracking is via package_versions.txt diffs and GitHub releases.

Provenance

The attestations page shows no attestations for this digest. Let me now check the image labels more carefully and look for any build provenance information:

Based on my comprehensive investigation, here is the provenance analysis:

---

Provenance verdict: lscr.io/linuxserver/plex 1.43.2 → 1.43.2

Verdict

suspicious

The same version tag (1.43.2) resolves to different digests between old and new versions, indicating tag mutation on a supposedly immutable SemVer tag. While the source repository and publisher namespace remain consistent, this digest rotation without corresponding version changes and the absence of build provenance attestations warrant caution.

Resolved references

• Artifact type: OCI container image (multi-arch)
• Old: lscr.io/linuxserver/plex:1.43.2 → sha256:58f13a1... (truncated in input)
• New: lscr.io/linuxserver/plex:1.43.2 → sha256:f79738b25b19d8e11658e3f2233067732023a1ab2ead8be610d75c55e425ecb8
• Declared source repo: https://github.com/linuxserver/docker-plex (verified)
• Publisher namespace: lscr.io/linuxserver (same) — same

Indicators

Severity	Category	Finding	Evidence
high	tag_mutation	Same SemVer tag 1.43.2 resolves to different digests on different dates	Old: 58f13a1..., New: f79738b25b19... (confirmed via skopeo inspect)
med	build_provenance	No SLSA provenance attestations found for either version	GitHub attestations page returns empty list for digest sha256:f79738b25b19...
med	metadata_drift	Image label org.opencontainers.image.revision points to commit fafcd0e3b342dc3d68924572d7c57d9c3985f3e0	Commit exists on master branch, authored by LinuxServer-CI bot on 2026-06-22
low	source_correspondence	Source commit exists and is legitimate bot commit	Commit fafcd0e3b342dc3d68924572d7c57d9c3985f3e0 is a "Bot Updating Package Versions" commit from LinuxServer-CI
info	publisher_continuity	Publisher namespace and source repo remain consistent	Both old and new versions from lscr.io/linuxserver with source github.com/linuxserver/docker-plex

Source ↔ artifact correspondence

• Old version anchor: Git commit fafcd0e3b342dc3d68924572d7c57d9c3985f3e0 (exists on master branch)
• New version anchor: Git commit fafcd0e3b342dc3d68924572d7c57d9c3985f3e0 (same commit)
• Method: Image label org.opencontainers.image.revision + GitHub repository verification

Note: Both old and new versions point to the same source commit, yet resolve to different digests. This is the core anomaly.

Signatures and attestations

	Old	New
Cosign signature present	unknown	no
Signing identity	unknown	n/a
SLSA provenance present	unknown	no
Builder identity	unknown	n/a
SBOM attached	unknown	no

Note: GitHub attestations endpoint returns empty list for the new digest. Presence-only check via skopeo and GitHub attestations API. Cryptographic verification not performed.

Metadata drift

Image labels (current state for new digest):

• org.opencontainers.image.revision: fafcd0e3b342dc3d68924572d7c57d9c3985f3e0
• org.opencontainers.image.source: https://github.com/linuxserver/docker-plex
• org.opencontainers.image.version: 1.43.2.10687-563d026ea-ls310
• build_version: Linuxserver.io version:- 1.43.2.10687-563d026ea-ls310 Build-date:- 2026-06-22T14:47:45+00:00

Assessment: Labels are consistent with expected LinuxServer.io build metadata. No unexpected drift detected in labels themselves. However, the fact that the same source commit produces different digests is the anomaly.

Typosquat / confusable check

• Nearest popular alternative names checked: linuxserver/plex (official), plexinc/pms-docker (official Plex), linuxserver/plexpy (related project)
• Findings: No typosquat detected. lscr.io/linuxserver/plex is the legitimate LinuxServer.io Plex image.

Repo health

• Ownership transfer in last 90d: no
• Archived: no
• New committers in version range: no (only LinuxServer-CI bot)
• Workflow file changes affecting release pipeline: not checked (would require Actions workflow inspection)

Note: Repository is active and maintained. The commit fafcd0e3b342dc3d68924572d7c57d9c3985f3e0 is a routine bot commit updating package versions, dated 2026-06-22.

Gaps

1. Cryptographic signature verification: Cosign verification not performed. Would require cosign CLI and public key access.
2. SLSA provenance verification: No provenance attestations found. Cannot verify builder identity or build trigger details.
3. Digest history: Cannot access historical tag-to-digest mappings from the registry. The mutation is confirmed by comparing the two digests provided, but full tag history is not available.
4. Build logs: No access to the build pipeline logs that produced these digests. Cannot determine if the same source commit was rebuilt or if different build parameters were used.
5. Multi-arch manifest details: The new digest resolves to a multi-arch index with amd64 and arm64 manifests. The old digest's architecture breakdown is not available for comparison.

---

Summary

This is a tag mutation case: the same SemVer tag (1.43.2) on the same registry (lscr.io/linuxserver/plex) resolves to different digests. Both versions point to the same source commit (fafcd0e3b342dc3d68924572d7c57d9c3985f3e0), which is a legitimate LinuxServer-CI bot commit. However, the absence of SLSA provenance attestations and the inability to explain why the same source commit produces different digests makes this suspicious rather than trusted.

The most likely explanations are:

1. Legitimate rebuild — The image was rebuilt from the same source commit with different build parameters or base image updates.
2. Tag reuse — The tag was reassigned to a newer build without a corresponding source commit change.
3. Build cache invalidation — Dependency updates or base image changes triggered a rebuild.

Without SLSA provenance or build logs, it's impossible to confirm which scenario applies. The downstream agent should treat this as requiring human review or escalation.