EUVD-2026-40168
GHSA-9f32-pf5h-p947
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as operator/spectator
-
ExploitQuery payload_build_step via Hasura GraphQL
-
ExecutionBroken _or filter returns all operations' rows
-
ImpactRead cross-operation step_stdout/stderr/name/description
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated Mythic account with at least operator or spectator role on the target server (PR:L) and a multi-operation deployment where more than one operation's data exists to be disclosed - on a single-operation server there is nothing cross-tenant to leak. No user interaction, no special non-default configuration, and no elevated privileges are needed: the vulnerable select permission on the payload_build_step table is exploitable through ordinary GraphQL queries against the standard Hasura API. The limiting factors are that the attacker must already hold a valid (even low-privilege) login, exploitation only yields confidentiality impact (read access to step_stdout, step_stderr, step_name, step_description) with no write or service impact, and affected versions are strictly those before 3.4.0.60. |
| Impact | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) scores 7.1 and is internally consistent with the description: network-reachable, low complexity, requires low privileges (a valid operator/spectator login), no user interaction, with high confidentiality impact and no integrity or availability impact. This is purely an information-disclosure / authorization-boundary failure, not code execution. No EPSS score was provided, the CVE is not in CISA KEV, and no POC is referenced, so real-world exploitation pressure appears low; however, exploitation is technically trivial for any insider with a server account because it requires only a normal GraphQL query against a routinely-used table. The realistic risk is therefore contextual: high on shared/multi-tenant Mythic servers where teams must be isolated from one another, and lower on single-team deployments where all operators are already trusted to see all data. No data signals conflict in this case; the main missing inputs are EPSS and any independent confirmation of in-the-wild use. |
| Exploit ScenarioDerived | An operator or spectator who has been granted access to one engagement on a shared Mythic server logs in and issues a standard GraphQL query against the payload_build_step table. Because the permission filter is always satisfied, the server returns build step stdout/stderr, names, and descriptions for payloads belonging to every other team's operation, revealing their tooling and configuration. No special exploit code is required; no public POC has been published. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 29, 2026
Cross-operation information disclosure in Mythic C2 framework versions before 3.4.0.60 allows any authenticated operator or spectator to read payload build artifacts belonging to operations they are not assigned to. A broken Hasura GraphQL permission filter on the payload_build_step table contains an always-true _or clause, neutralizing the operation-scoped row-level access control and exposing step_stdout, step_stderr, step_name, and step_description across every operation on the server. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, but the fix is publicly committed and the conditions are trivial for any logged-in low-privilege user.
RemediationAI
Vendor-released patch: upgrade Mythic to version 3.4.0.60 or later, which corrects the Hasura select permission on payload_build_step (release notes at https://github.com/its-a-feature/Mythic/releases/tag/v3.4.0.60, fix commit 82648e8241b800a32e1882afc310e7316d98ebaa, advisory at https://www.vulncheck.com/advisories/mythic-broken-permission-filter-in-payload-build-step-table). If you cannot upgrade immediately, the most effective compensating control is to stop using a single shared Mythic instance for separate engagements - segregate operations onto dedicated servers so cross-operation reads have no untrusted data to expose, at the cost of additional infrastructure. As an interim measure on a self-hosted instance you can manually correct the Hasura metadata for the payload_build_step table by removing the always-true _or branch and enforcing the operation-membership filter, then reload metadata; this requires Hasura admin access and should be validated against the official patch to avoid drift. Additionally, restrict and audit operator/spectator account provisioning so only trusted personnel hold accounts on multi-team servers, recognizing this only narrows the insider population rather than closing the flaw.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Mythic is an open-source, multi-operator command-and-control (C2) framework used in red-team engagements; it relies on a Hasura GraphQL engine layered over PostgreSQL to enforce per-operation tenant isolation through declarative row-level permission filters. Access to sensitive tables is supposed to be scoped so an operator only sees data for operations they belong to. This vulnerability is a classic CWE-863 (Incorrect Authorization): the select permission on the payload_build_step table was defined with an _or boolean condition where one branch is always satisfied, so the intended operation-membership predicate is short-circuited and every row is returned regardless of the requesting user's operation. Because payload build steps capture compiler/agent build output (stdout, stderr, step names and descriptions), the leaked data can reveal payload configuration, infrastructure naming, and operational tradecraft of unrelated teams sharing the server.
Know when Mythic gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable Hasura API with only a low-privilege operator/spectator login (PR:L, AC:L); pure cross-operation data read gives C:H with no integrity or availability impact and unchanged scope.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
1DescriptionCVE.org
Mythic before 3.4.0.60 contains a broken hasura permission filter on the payload_build_step table with an always-satisfied _or condition that bypasses operation-scoped access controls. Authenticated operators and spectators can query payload_build_step to read step_stdout, step_stderr, step_name, and step_description across all operations on the server.
Executive ViewAI
Mythic C2 framework versions before 3.4.0.60 contain a broken access control vulnerability in the GraphQL permission layer that allows any authenticated user to read sensitive build artifacts and operational metadata from operations they should not have access to. No public exploit identified at time of analysis; however, the conditions are trivial for exploitation by any logged-in user. Organizations using Mythic C2 should identify affected instances immediately and implement compensating controls pending patch availability.
No vendor-released patch identified at time of analysis. Interim mitigations: Restrict GraphQL API access via firewall to trusted operator IPs; implement network segmentation to limit Mythic C2 exposure; enhance audit logging for payload_build_step table queries; monitor for step_stdout, step_stderr, step_name, and step_description access patterns across mismatched operations; consider additional authentication requirements (VPN/MFA) for operator access; subscribe to vendor security advisories for version 3.4.0.60 release notification.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Stored cross-site scripting in Mythic 3.2.16 through 3.4.0.61 allows an attacker who controls files on an agent-reachabl
Cross-operation authorization bypass in Mythic C2 framework before 3.4.0.60 exposes encryption keys and C2 profile confi
Authorization bypass in Mythic C2 framework before 3.4.0.60 allows authenticated spectator-role users to perform write o
Exploit-DB