CVE-2026-57951: Mythic Auth Bypass Vulnerability

CVE-2026-57951 Overview

CVE-2026-57951 is an authorization flaw in the Mythic command-and-control framework maintained by its-a-feature. Versions prior to 3.4.0.60 ship a broken Hasura permission filter on the payload_build_step table. The filter contains an always-satisfied _or condition that bypasses operation-scoped access controls. Authenticated operators and spectators can query payload_build_step and read step_stdout, step_stderr, step_name, and step_description across every operation on the server. The issue maps to CWE-863: Incorrect Authorization.

Critical Impact
Any authenticated Mythic user, including low-privileged spectators, can read payload build output and metadata from operations they are not assigned to, exposing tradecraft, target details, and operator activity.

Affected Products

Mythic versions prior to 3.4.0.60
Mythic Hasura GraphQL API (payload_build_step table)
Mythic operator and spectator role scopes

Discovery Timeline

2026-06-29 - CVE-2026-57951 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-57951

Vulnerability Analysis

Mythic exposes its data model to authenticated users through a Hasura GraphQL layer. Hasura enforces row-level access through per-role permission filters that Mythic scopes to the caller's current operation. The payload_build_step table stores step-by-step output from payload build pipelines, including compiler messages, tool output, and step descriptions.

The permission filter on payload_build_step was defined with an _or clause containing a condition that evaluates to true for every row. The intended operation check never gets enforced. A query submitted by any operator or spectator returns rows belonging to every operation on the server. The exposed columns include step_stdout and step_stderr, which frequently contain payload artifact paths, target-specific strings, C2 profile parameters, and operator commentary.

Root Cause

The root cause is a logic error in the Hasura permission JSON for the payload_build_step role. An _or operator was combined with an unconditional predicate, producing a filter that resolves to true regardless of the requesting user's operation_id. Because Hasura evaluates the filter before returning rows, no additional server-side check exists to constrain results. The fix in commit 82648e8 and companion controller changes reintroduce explicit operation_id scoping on payload lookups.

Attack Vector

An attacker needs valid Mythic credentials with any role, including the read-only spectator role. The attacker issues a GraphQL query against payload_build_step through the Hasura endpoint. The response includes rows from operations the caller is not a member of. No user interaction is required and the attack originates over the network against the Mythic web interface.

// Patch excerpt: enforce operation scoping on payload lookups
// mythic-docker/src/webserver/controllers/c2profile_config_check_webhook.go
ginOperatorOperation, ok := c.Get("operatorOperation")
if !ok {
    logging.LogError(nil, "Failed to get operatorOperation information for CreateC2ParameterInstanceWebhook")
    c.JSON(http.StatusOK, gin.H{"status": "error", "error": "Failed to get current operation. Is it set?"})
    return
}
operatorOperation := ginOperatorOperation.(*databaseStructs.Operatoroperation)
// get the associated database information
payload := databaseStructs.Payload{}
if err := database.DB.Get(&payload,
    `SELECT id FROM payload WHERE uuid=$1 AND operation_id=$2`,
    input.Input.PayloadUUID, operatorOperation.CurrentOperation.ID); err != nil {
    logging.LogError(err, "Failed to find payload when doing a C2ProfileConfigCheckWebhook")
}

Source: Mythic commit 82648e8

Detection Methods for CVE-2026-57951

Indicators of Compromise

GraphQL queries against payload_build_step from users whose session operation_id does not match the operation_id of returned rows.
Spectator-role accounts issuing queries that select step_stdout or step_stderr in bulk.
Repeated introspection or schema queries against the Hasura endpoint from newly created operator accounts.

Detection Strategies

Enable Hasura query logging and alert on any authenticated request referencing payload_build_step with no where clause bounded by operation_id.
Correlate Mythic authentication events with GraphQL query volume to spot low-privileged accounts pulling large result sets.
Review database audit logs for SELECT statements against payload_build_step returning row counts inconsistent with the caller's operation membership.

Monitoring Recommendations

Forward Mythic container logs and Hasura access logs to a central log platform and retain them for at least 90 days.
Baseline normal per-user query patterns against the GraphQL endpoint and alert on deviations.
Track creation of new spectator or operator accounts and monitor their initial query behavior against sensitive tables.

How to Mitigate CVE-2026-57951

Immediate Actions Required

Upgrade Mythic to version 3.4.0.60 or later, which contains the corrected Hasura permission filter and controller-level operation_id checks.
Rotate any operator credentials that may have been exposed and review recent spectator account activity.
Audit historical Hasura logs for queries against payload_build_step originating from accounts outside the intended operation.

Patch Information

The fix ships in Mythic release v3.4.0.60 and is implemented in commit 82648e8. The patch corrects the broken _or filter and adds explicit operation_id scoping to payload lookups in controllers such as c2profile_config_check_webhook.go and c2profile_get_ioc_webhook.go. See the VulnCheck advisory and GitHub issue #563 for additional context.

Workarounds

Restrict network access to the Mythic web and Hasura endpoints to trusted operator networks or VPN segments.
Temporarily disable or remove spectator accounts until the upgrade is complete.
Manually edit the Hasura metadata for payload_build_step to enforce operation_id: { _eq: X-Hasura-Current-Operation-Id } if an immediate upgrade is not possible.

bash

# Verify installed Mythic version and upgrade
cd /opt/Mythic
git fetch --tags
git checkout v3.4.0.60
sudo ./mythic-cli stop
sudo ./mythic-cli start
sudo ./mythic-cli status