Mythic 3.4.0.60 Broken Hasura Permission Filter Bypass

Executive Summary

CVE-2026-57951 is a security vulnerability in Mythic versions before 3.4.0.60 involving a broken Hasura permission filter on the payload_build_step table.

The vulnerability arises because the permission filter uses an always-true _or condition that bypasses operation-scoped access controls, allowing authenticated users—regardless of their role—to query and read sensitive fields such as step_stdout, step_stderr, step_name, and step_description across all operations on the server.

This flaw effectively bypasses Mythic's intended role-based access control (RBAC), exposing confidential build logs and potentially sensitive information like compilation paths, environment details, embedded command and control configuration values, encryption keys, and internal server paths.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have serious impacts, especially in environments where multiple teams or clients operate on the same Mythic server.

• Authenticated users can access sensitive payload build logs from all operations, not just their own.
• Exposure of confidential information such as compilation paths, environment variables, embedded C2 configuration details (callback hosts, ports, sleep intervals), encryption keys, and internal server paths.
• Bypassing of role-based access controls can lead to unauthorized data disclosure and potential compromise of operational security.

Overall, this can lead to information leakage, increased risk of attacks, and loss of trust in the security of the Mythic deployment.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves an improperly configured Hasura permission filter in Mythic that allows authenticated users to query the payload_build_step table and access sensitive build logs across all operations. Detection involves verifying if unauthorized access to these payload build logs is possible.

One way to detect this vulnerability is to attempt querying the payload_build_step table as an authenticated operator or spectator and check if you can read fields such as step_stdout, step_stderr, step_name, and step_description for payloads belonging to operations you should not have access to.

Since the issue is due to a broken Hasura permission filter, you can also inspect the Hasura metadata configuration, specifically the permission filter for the payload_build_step table, to see if it contains an always-true _or condition involving payloadtype_id.

Suggested commands (assuming access to Mythic's GraphQL API or Hasura console):

• Use a GraphQL query to request payload_build_step data for operations you are not authorized to access and see if the data is returned.
• Inspect Hasura metadata with commands or API calls to retrieve the permission filter for the payload_build_step table and check for the presence of an always-true _or condition.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation is to upgrade Mythic to version 3.4.0.60 or later, where the broken Hasura permission filter has been fixed.

The fix involves correcting the permission filter in the Hasura metadata to properly restrict access to the payload_build_step table by operation, removing the always-true _or condition.

Additionally, the Mythic project updated webhook controllers to validate operation context and ensure queries are scoped to the current operation, improving overall access control.

Until the upgrade is applied, restrict access to Mythic's GraphQL API and ensure only trusted authenticated users have access, to reduce the risk of unauthorized data exposure.

Useful 0 Not Useful 0