CVE-2026-31852 is a critical flaw, scored 10.0, in a GitHub Actions workflow of the jellyfin-ios repository, not in Jellyfin's runtime code. The advisory says CI workflows were changed and secrets rotated, and that end users do not need to take any action.
What's affected
The code-quality.yml workflow in the jellyfin/jellyfin-ios repository. The advisory states this is not a code vulnerability but a problem in GitHub Actions workflows.
There is no affected version range and no new release. The advisory says no new version is required and that end users do not need to do anything.
If you maintain your own fork of jellyfin-ios or copied this workflow pattern, the lesson applies to you even though the fix does not.
How to check if you're exposed
For Jellyfin users there is nothing to check. For maintainers of other projects, review your own workflows with the same question the advisory raises: can a pull request from a fork run code in a job that holds write permissions or secrets?
Open each file under .github/workflows and look at the trigger, the permissions block, and any step that checks out code from the pull request. A trigger that runs fork code with the repository's token deserves a close look.
What to do now
- Jellyfin end users: no action is needed, per the advisory.
- Maintainers: audit workflows that run on pull requests from forks and cut their permissions to the minimum.
- Keep secrets out of jobs that execute untrusted code, and prefer short lived credentials.
- Pin third party actions to full commit SHAs and review them when they change.
- Forks of jellyfin-ios should pull the project's updated workflows.
Why it matters
The record lists CWE-269, improper privilege management. The workflow ran pull request code from forks while holding nearly all write permissions. The advisory lists the possible outcomes in the project's own words: repository takeover, theft of privileged secrets, a supply chain attack through App Store updates, package poisoning in the container registry, and organization wide compromise through a shared token.
That is a long list from one misconfigured job, and it shows how much a CI token can reach. The project responded by changing workflows in all affected repositories and rotating secrets, which is the right response for a pipeline flaw.
I found no statement in the record or the advisory that this was exploited. The record does not flag this CVE as listed in CISA's Known Exploited Vulnerabilities catalog, and no advisory I read says it is exploited in the wild. Treat it as a patch to schedule promptly, not a fire drill, unless your own logs say otherwise.
Quick check
Do I need to update my Jellyfin server or app?
No. The advisory says no new version is required and end users do not need to take any action.
Why does a CI bug get a CVE?
Because the compromise of a build pipeline can lead to malicious releases. The score reflects that potential reach.
Sources
Last reviewed: 19 October 2026.
