Distributed-workloads: github actions pinned by mutable tag/branch, including third-party snyk/actions/setup@master
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: The sources give no workaround. Limiting the affected pull_request_target workflow is the only option the facts point to, and they do not describe how to do that.
- Last modified
- FIRST's estimate of the chance attackers exploit it in the next 30 days, updated daily.What do these mean? →
- 0.24% · 14th percentile
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 45/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: total
Summary
The software is distributed-workloads, whose GitHub Actions workflows are pinned to mutable tags or branches, including a third-party Snyk action. A remote attacker who submits a specially crafted pull request could make the pull_request_target workflow run untrusted code with access to the base repository's secrets, such as the SNYK_TOKEN and default write token, and could then steal them, gaining access to the Snyk integration and possibly control of the repository.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
A flaw was found in distributed-workloads. A remote attacker could exploit a vulnerability in the pull_request_target workflow by submitting a specially crafted pull request. This workflow processes untrusted code from the pull request author while operating with the base repository's sensitive secrets, such as the SNYK_TOKEN, and its default write token. Consequently, an attacker could exfiltrate these secrets, leading to unauthorized access to the Snyk integration and potential control over the repository.
cve.now Index
- Exploitation0/40No signal
- Exposure20/25No login or user action needed, CISA rates it automatable · Unknown: Advisories don't say whether default setups are affected
- Reach10/20Shipped in major Linux distributions
- Severity10/10CVSS 9.1, total technical impact per CISA
- No patch5/5No patch listed yet
What would change the score
- Would score about 90 if added to CISA KEV
- Would score about 85 if CISA's SSVC rates exploitation active
- Would score about 50 if advisories confirm default setups are exposed
What to do
Workaround: The sources give no workaround. Limiting the affected pull_request_target workflow is the only option the facts point to, and they do not describe how to do that.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: total
- Record last updated
- Posted on X by cve.now
Affected versions
- rhoai/odh-training-cuda128-torch29-py312-rhel9
Version range not reported
Evidence 2
- Report
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-83493
Is CVE-2026-83493 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
The workflow uses third-party actions pinned to mutable tags or branches, such as snyk/actions/setup@master, so the code it runs can change without the repository changing. In a pull_request_target workflow, this could expose the SNYK_TOKEN and other base repository secrets.Source: access.redhat.com
Am I affected, and how do I check?
The affected component is the pull_request_target workflow in the red-hat-data-services/distributed-workloads repository. The sources do not list affected versions, so check that workflow file for actions referenced by a branch or tag rather than a fixed commit.Source: access.redhat.com
How do I fix CVE-2026-83493?
The sources list no fixed version or upgrade target. Check the advisory for updates before relying on any release.Source: access.redhat.com
What if there's no patch?
The sources give no workaround. Limiting the affected pull_request_target workflow is the only option the facts point to, and they do not describe how to do that.Source: access.redhat.com