CVE-2026-57951: Mythic C2 Broken Hasura Permission Filter Enables Cross-Operation Data Disclosure

Technical summary

CVE-2026-57951 is an improper authorization vulnerability in Mythic's Hasura GraphQL permission layer affecting the payload_build_step table. The issue manifests as a broken permission filter with a logically defective _or condition that evaluates to true regardless of the operator's scope or role assignments. This bypasses operation-scoped access controls, allowing authenticated principals to execute queries that return step_stdout, step_stderr, step_name, and step_description fields across all operations in the Mythic instance. The vulnerability is classified under CWE-863 (Incorrect Authorization) and carries a CVSS v3.1 score of 6.5 (Medium severity) with a vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, reflecting high confidentiality impact, low complexity, and requirement for valid authentication.

Business impact

In a multi-tenant or multi-campaign Mythic deployment, this vulnerability enables unauthorized disclosure of operational details that should remain compartmentalized. Operators assigned to one campaign can read build step output from unrelated operations, exposing command sequences, payload configurations, staging output, and debug information. This information disclosure can compromise operational security, reveal payload construction techniques, and provide adversaries or disgruntled insiders visibility into concurrent activities across the infrastructure. Organizations relying on role-based compartmentalization of red team or threat emulation campaigns will find those controls ineffective.

Affected systems

All versions of Mythic C2 framework before 3.4.0.60 are affected. The vulnerability requires valid authentication (operator or spectator role) and impacts any deployment where multiple operators or campaigns share the same server instance. Single-operator, isolated Mythic instances or fully air-gapped deployments with restricted access still benefit from patching to eliminate the attack surface.

Exploitability

Exploitation requires valid Mythic credentials and network access to the server's API endpoint. No special privileges, complex exploitation chains, or user interaction are needed; an authenticated spectator can immediately query the payload_build_step table via GraphQL to extract step details. The low attack complexity and straightforward query structure make this trivial to exploit once authenticated. However, exploitation does depend on having at least a valid user account, which may not be accessible to external unauthenticated attackers in properly firewalled environments.

Remediation

Upgrade Mythic to version 3.4.0.60 or later, which contains corrected permission filters for the payload_build_step table. The patch replaces the faulty _or condition with proper authorization logic that enforces operation-scoped access. Organizations unable to patch immediately should restrict API access through network segmentation or Web Application Firewall rules, limit spectator role assignments, and audit query logs for unauthorized payload_build_step requests.

Patch guidance

Consult the official Mythic repository and release notes for version 3.4.0.60 or later. Apply patches according to your deployment model (container, source, or binary). Test in a staging environment to verify that operation-scoped filters function correctly after patching. If you are unsure of the exact patch version available for your distribution, verify against the vendor advisory from its-a-feature/Mythic.

Detection guidance

Monitor GraphQL query logs for queries against the payload_build_step table, particularly those requesting step_stdout, step_stderr, step_name, or step_description fields. Establish baselines for which users should legitimately query this table and alert on deviations. Check Mythic logs for cross-operation access patterns (e.g., spectators querying steps outside their assigned campaigns). If available, inspect Hasura introspection queries or schema queries to detect permission filter anomalies. Review user activity logs for recent credential changes or privilege escalations prior to large-scale payload_build_step queries.

Why prioritize this

Although exploitability is straightforward and impact is high, the requirement for valid authentication limits the risk surface in properly hardened environments. This is a classic lateral movement and information disclosure vector for insider threats or compromised accounts. Given the CVSS 6.5 (Medium) score and the nature of Mythic deployments (typically in sensitive red team or research infrastructure), this vulnerability should be prioritized within 30 days. Organizations with large, multi-team Mythic instances or strict role segregation requirements should patch within 2 weeks.

Risk score, explained

The CVSS 6.5 (Medium) score reflects high confidentiality impact (step output, build details, payload information) and the network-accessible, low-complexity exploit path, balanced against the requirement for valid authentication. No integrity or availability impact is present. The score appropriately captures the severity for most enterprise environments but may warrant higher priority in security-sensitive Red Team operations where compartmentalization is critical.

Frequently asked questions