Invidious through 2

Invidious is a self-hosted, privacy-preserving frontend for YouTube written in Crystal (Kemal framework, Postgres backend). The bug is a classic IDOR (CWE-639) in the remove_video action on the playlist endpoint: the code accepted an attacker-supplied global video *index* without checking that the playlist actually belonged to the caller. Combined with the fact that per-video indices are exposed by the public playlist JSON API, any logged-in user of the same instance could permanently delete videos from *other users'* playlists. Affects Invidious ≤ 2.20260626.0; fixed in commit 77ad416 on the master branch.

Vendor pegged this at CVSS 6.5 MEDIUM with C:N/I:H/A:N. The integrity call is fair — data belonging to another user is mutated without authorization — but the deployment reality drags the operational severity down further. Invidious is not typically an enterprise application; it is deployed by hobbyists, privacy-focused communities, and small self-hosters. The affected data is playlist entries, not credentials, code, or business records. In practitioner terms this is LOW: real, worth fixing, but nowhere near patch-cycle-jumping territory.

Why this verdict

• Authenticated precondition (PR:L): attacker must hold a valid account on the same instance — implies either open registration or prior social engineering / account takeover. Removes drive-by exploitation.
• Integrity-only impact (C:N/I:H/A:N): no credential theft, no RCE, no denial of service, no data exfiltration. Damage is bounded to playlist row deletions, which are recoverable from any Postgres backup.
• Deployment-role audit — no high-value role exists for Invidious: it is a personal / community media frontend. It is not identity, not PKI, not backup, not hypervisor, not CI/CD, not an edge appliance. The role-multiplier floor rule does not raise the verdict because no realistic deployment role turns this bug into fleet, domain, or supply-chain compromise.
• Exposure population is tiny in enterprise terms: dozens of public instances, low hundreds of private ones. Sub-1% of the Fortune 5000 runs Invidious anywhere.
• No in-the-wild activity, no KEV, EPSS 0.2%. No opportunistic mass exploitation signal.
• Vendor 6.5 baseline is reasonable for an individual instance operator; downgrade to LOW reflects enterprise portfolio prioritization, not disagreement with the technical scoring.

Why not higher?

MEDIUM would imply the bug warrants scheduled remediation ahead of routine backlog. It does not — the impact is user-visible annoyance recoverable from Postgres backups, with no lateral movement or credential exposure. HIGH/CRITICAL are inapplicable: no code execution, no auth bypass, no cross-tenant escalation, no high-value-role component.

Why not lower?

IGNORE is not appropriate because the bug is real, trivially exploitable once the patch diff is public, and permanently destroys user data. Operators of public Invidious instances do need to upgrade; LOW correctly signals 'fix in the next window' rather than 'do nothing'.

1. Disable new-user registration on public instances until patched — Cuts off the primary attacker acquisition path (PR:L becomes unreachable). Set registration_enabled: false in config.yml and restart the container. As a LOW-severity finding under the noisgate mitigation SLA there is no mandatory mitigation deadline, but for public-facing instances treat this as a same-week hygiene step.
2. Snapshot the Postgres playlists and playlist_videos tables before patch and daily thereafter — Because the bug destroys rows with no soft-delete, backups are your only recovery. Run pg_dump -t playlists -t playlist_videos on cron; retain 30 days. Do this before you deploy 77ad416 so you have a known-good baseline.
3. Add a reverse-proxy rule that logs every POST to /playlist_ajax with the session user ID — Gives you post-facto attribution and lets you tell affected users what was deleted. Ten lines of nginx log_format plus a Loki/ELK query on action=remove_video where source user differs from playlist owner.
4. Pull master or wait for the next tagged release, then redeploy the container — The fix is a single commit — git pull && docker compose build && docker compose up -d. Under the noisgate remediation SLA for LOW you have up to 365 days, but there is no reason to wait: the delta is trivial and the fix does not change data schemas.

Run this on the Invidious host itself (the container host or the VM running the Crystal binary). It inspects the deployed git revision. Invoke as ./check-invidious-cve-2026-58447.sh /opt/invidious where the argument is the Invidious source directory. Requires read access to that directory; no root needed.

#!/usr/bin/env bash
# noisgate verifier — CVE-2026-58447 (Invidious IDOR in playlist remove_video)
# Output: VULNERABLE / PATCHED / UNKNOWN
set -u

INV_DIR="${1:-/opt/invidious}"
FIX_COMMIT="77ad416"
LAST_VULN_TAG="v2.20260626.0"

if [[ ! -d "$INV_DIR/.git" ]]; then
  echo "UNKNOWN: $INV_DIR is not a git checkout of iv-org/invidious"
  exit 2
fi

cd "$INV_DIR" || { echo "UNKNOWN: cannot cd to $INV_DIR"; exit 2; }

# Fetch tags/commits quietly so we can resolve the fix ref
git fetch --quiet --tags origin 2>/dev/null || true

# 1. Does the checked-out HEAD contain the fix commit in its history?
if git merge-base --is-ancestor "$FIX_COMMIT" HEAD 2>/dev/null; then
  echo "PATCHED: HEAD ($(git rev-parse --short HEAD)) contains fix commit $FIX_COMMIT"
  exit 0
fi

# 2. Fallback — check the tagged release string in the source
CURRENT_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "unknown")
if [[ "$CURRENT_TAG" == "$LAST_VULN_TAG" || "$CURRENT_TAG" < "$LAST_VULN_TAG" ]]; then
  echo "VULNERABLE: release $CURRENT_TAG is at or before $LAST_VULN_TAG and fix commit $FIX_COMMIT is not in history"
  exit 1
fi

echo "UNKNOWN: could not conclusively determine patch status (tag=$CURRENT_TAG, HEAD=$(git rev-parse --short HEAD))"
exit 2

Sources

1. Invidious release v2.20260626.0 (last vulnerable tag)
2. iv-org/invidious repository
3. Invidious official documentation — Instances
4. Invidious project site
5. OWASP API1:2023 Broken Object Level Authorization
6. CWE-639: Authorization Bypass Through User-Controlled Key
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS model