Vulnerability-Lookup

GHSA-J7QQ-VR8C-XVW3

Vulnerability from github – Published: 2026-10-27 21:26 – Updated: 2026-10-27 21:26

Summary

MLflow CrewAI autologging records LLM provider API keys in logged trace spans

Details

Summary

mlflow.crewai.autolog() leaks CrewAI LLM provider API keys into MLflow trace telemetry.

When a CrewAI Agent is instrumented with MLflow autologging, MLflow serializes the agent's __dict__ and converts its fields to strings. The llm field contains the CrewAI LLM object, whose string representation includes its api_key in plaintext.

As a result, an application that calls mlflow.crewai.autolog() can unintentionally send its LLM provider API key to the MLflow trace backend or configured OTLP destination.

The application does not need to explicitly log the credential or place it in a span attribute. The credential is extracted automatically by MLflow's instrumentation.

This was verified on MLflow 3.16.0 with CrewAI 1.15.18 using MLflow's own OTLP exporter. The fake credential appeared in 5 attribute locations across 2 spans.

Details

The primary issue is in:

mlflow/crewai/autolog.py::_get_agent_attributes()

The function walks the CrewAI Agent.__dict__ and converts agent fields to strings. tools and embedder receive special handling, but credential-bearing objects such as the following are not sanitized:

llm
function_calling_llm
agent_executor
crew

For example, agent.llm is a CrewAI LLM object. In CrewAI 1.15.18, the underlying LLM model contains api_key as a normal field. Its string representation therefore contains the credential:

llm_type='openai' model='gpt-4.1-mini' ... api_key='sk-proj-...' ...

MLflow subsequently stores this string as a span attribute.

There is an important indication that this is an unintended disclosure: MLflow's dedicated LLM attribute extraction already explicitly excludes api_key in _get_llm_attributes(). The LLM span therefore does not expose the credential, while the broader Agent __dict__ serialization bypasses that protection.

There is also a second, independent serialization path in:

mlflow/crewai/autolog.py::_construct_full_inputs()

This code uses:

v.__dict__ if hasattr(v, "__dict__") else v

on call arguments. During CrewAI execution, the Agent object is passed as an argument, causing its __dict__ to be expanded and the credential-bearing LLM object to be included in mlflow.spanInputs.

Therefore, there are two independent leakage paths:

Agent span attributes through _get_agent_attributes()
Span inputs through _construct_full_inputs()

Fixing only the Agent attribute serialization would leave the mlflow.spanInputs path vulnerable.

A safer approach would be to avoid recursively serializing arbitrary object __dict__ values. Agent telemetry should use an explicit allowlist of non-sensitive scalar fields, and credential-bearing objects such as llm, function_calling_llm, agent_executor, and crew should either be reduced to safe metadata or omitted.

Similarly, _construct_full_inputs() should not automatically expand arbitrary objects through __dict__, or the resulting values should pass through the same sanitization mechanism before being attached to a span.

PoC

Environment:

MLflow: 3.16.0
CrewAI: 1.15.18
Python: 3.12.3
opentelemetry-exporter-otlp-proto-http: 1.42.1

1. Direct serialization proof

The following demonstrates the vulnerability without starting a Crew, making a network request, or requiring an MLflow server:

import importlib
from crewai import LLM, Agent

autolog = importlib.import_module("mlflow.crewai.autolog")

llm = LLM(
    model="gpt-4.1-mini",
    api_key="sk-proj-EXAMPLE1234567890",
)

agent = Agent(
    role="r",
    goal="g",
    backstory="b",
    llm=llm,
)

attrs = autolog._get_agent_attributes(agent)

assert "sk-proj-EXAMPLE1234567890" in attrs["llm"]

print(attrs["llm"])

The output contains the API key in plaintext, for example:

llm_type='openai' model='gpt-4.1-mini' ... api_key='sk-proj-EXAMPLE1234567890' ...

No provider request is required.

2. End-to-end trace disclosure

The issue can also be reproduced through MLflow's actual OTLP exporter.

Configure a local OTLP HTTP receiver and set:

export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://127.0.0.1:4318/v1/traces
export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
export CREWAI_DISABLE_TELEMETRY=true

Then run:

import mlflow

from crewai import Agent, Crew, LLM, Task

mlflow.crewai.autolog()

llm = LLM(
    model="gpt-4.1-mini",
    api_key="sk-proj-EXAMPLE1234567890",
)

agent = Agent(
    role="Support Responder",
    goal="Answer support questions",
    backstory="A support agent",
    llm=llm,
)

task = Task(
    description="Answer the user's question",
    expected_output="A response",
    agent=agent,
)

crew = Crew(
    agents=[agent],
    tasks=[task],
)

crew.kickoff()

A local OTLP receiver can decode the ExportTraceServiceRequest sent by MLflow.

The provider request is expected to fail because the credential is intentionally fake. This does not affect the vulnerability: the sensitive value is added to the MLflow span when the instrumentation starts, before the provider call succeeds or fails.

In the tested environment, the fake API key appeared in the exported telemetry in 5 locations across 2 spans, including:

Support Responder
  attributes.llm
  attributes.function_calling_llm
  attributes.agent_executor
  attributes.mlflow.spanInputs

Task.execute_sync
  attributes.mlflow.spanInputs

The captured value is produced by MLflow's actual telemetry/export path rather than being manually inserted into a span.

All credentials used in the reproduction are locally generated fake values. No real API credential is required.

Impact

Type: Sensitive Information Disclosure / Credential Disclosure CWE: CWE-532 — Insertion of Sensitive Information into Log File

Any application using mlflow.crewai.autolog() with a CrewAI LLM configured with an API key can unintentionally disclose that credential through MLflow traces.

The credential is written to trace telemetry even though the application does not explicitly log it.

Anyone with access to the MLflow trace storage or configured OTLP destination may therefore obtain the provider credential. Depending on the deployment, this can include MLflow users, observability operators, or third-party telemetry providers.

The leaked credential can then potentially be used against the corresponding LLM provider account, including for unauthorized API usage and associated costs.

The issue is particularly significant because the credential crosses a trust boundary: a provider API key intended for use by the application is automatically copied into observability telemetry where a broader set of users or systems may have access.

The vulnerability does not require the developer to intentionally log the secret. The only relevant prerequisite is enabling the CrewAI autologging integration.

Patches

Fixed in MLflow 3.17.0 by #25845. mlflow.crewai.autolog() now reduces CrewAI LLM objects to their model name and drops credential-like keys before they are written to span attributes or mlflow.spanInputs.

Remediation

Upgrade to mlflow>=3.17.0.
Upgrading stops new leakage but does not remove credentials already written. Rotate any LLM provider key that a CrewAI LLM object held (for example one passed as LLM(api_key=...)) while mlflow.crewai.autolog() was enabled on MLflow 2.19.0 through 3.16.x.
Delete or redact the affected traces in the MLflow tracking backend and in any OTLP destination they were exported to. The key appears in Agent and Crew span attributes and in mlflow.spanInputs.

Workarounds

If you cannot upgrade yet, disable CrewAI autologging with mlflow.crewai.autolog(disable=True).

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mlflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            },
            {
              "fixed": "3.17.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-116691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-312",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-27T21:26:39Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`mlflow.crewai.autolog()` leaks CrewAI LLM provider API keys into MLflow trace telemetry.\n\nWhen a CrewAI `Agent` is instrumented with MLflow autologging, MLflow serializes the agent\u0027s `__dict__` and converts its fields to strings. The `llm` field contains the CrewAI LLM object, whose string representation includes its `api_key` in plaintext.\n\nAs a result, an application that calls `mlflow.crewai.autolog()` can unintentionally send its LLM provider API key to the MLflow trace backend or configured OTLP destination.\n\nThe application does not need to explicitly log the credential or place it in a span attribute. The credential is extracted automatically by MLflow\u0027s instrumentation.\n\nThis was verified on **MLflow 3.16.0** with **CrewAI 1.15.18** using MLflow\u0027s own OTLP exporter. The fake credential appeared in **5 attribute locations across 2 spans**.\n\n### Details\n\nThe primary issue is in:\n\n`mlflow/crewai/autolog.py::_get_agent_attributes()`\n\nThe function walks the CrewAI `Agent.__dict__` and converts agent fields to strings. `tools` and `embedder` receive special handling, but credential-bearing objects such as the following are not sanitized:\n\n* `llm`\n* `function_calling_llm`\n* `agent_executor`\n* `crew`\n\nFor example, `agent.llm` is a CrewAI `LLM` object. In CrewAI 1.15.18, the underlying LLM model contains `api_key` as a normal field. Its string representation therefore contains the credential:\n\n```text\nllm_type=\u0027openai\u0027 model=\u0027gpt-4.1-mini\u0027 ... api_key=\u0027sk-proj-...\u0027 ...\n```\n\nMLflow subsequently stores this string as a span attribute.\n\nThere is an important indication that this is an unintended disclosure: MLflow\u0027s dedicated LLM attribute extraction already explicitly excludes `api_key` in `_get_llm_attributes()`. The LLM span therefore does not expose the credential, while the broader Agent `__dict__` serialization bypasses that protection.\n\nThere is also a second, independent serialization path in:\n\n`mlflow/crewai/autolog.py::_construct_full_inputs()`\n\nThis code uses:\n\n```python\nv.__dict__ if hasattr(v, \"__dict__\") else v\n```\n\non call arguments. During CrewAI execution, the `Agent` object is passed as an argument, causing its `__dict__` to be expanded and the credential-bearing LLM object to be included in `mlflow.spanInputs`.\n\nTherefore, there are two independent leakage paths:\n\n1. **Agent span attributes** through `_get_agent_attributes()`\n2. **Span inputs** through `_construct_full_inputs()`\n\nFixing only the Agent attribute serialization would leave the `mlflow.spanInputs` path vulnerable.\n\nA safer approach would be to avoid recursively serializing arbitrary object `__dict__` values. Agent telemetry should use an explicit allowlist of non-sensitive scalar fields, and credential-bearing objects such as `llm`, `function_calling_llm`, `agent_executor`, and `crew` should either be reduced to safe metadata or omitted.\n\nSimilarly, `_construct_full_inputs()` should not automatically expand arbitrary objects through `__dict__`, or the resulting values should pass through the same sanitization mechanism before being attached to a span.\n\n### PoC\n\nEnvironment:\n\n```text\nMLflow: 3.16.0\nCrewAI: 1.15.18\nPython: 3.12.3\nopentelemetry-exporter-otlp-proto-http: 1.42.1\n```\n\n#### 1. Direct serialization proof\n\nThe following demonstrates the vulnerability without starting a Crew, making a network request, or requiring an MLflow server:\n\n```python\nimport importlib\nfrom crewai import LLM, Agent\n\nautolog = importlib.import_module(\"mlflow.crewai.autolog\")\n\nllm = LLM(\n    model=\"gpt-4.1-mini\",\n    api_key=\"sk-proj-EXAMPLE1234567890\",\n)\n\nagent = Agent(\n    role=\"r\",\n    goal=\"g\",\n    backstory=\"b\",\n    llm=llm,\n)\n\nattrs = autolog._get_agent_attributes(agent)\n\nassert \"sk-proj-EXAMPLE1234567890\" in attrs[\"llm\"]\n\nprint(attrs[\"llm\"])\n```\n\nThe output contains the API key in plaintext, for example:\n\n```text\nllm_type=\u0027openai\u0027 model=\u0027gpt-4.1-mini\u0027 ... api_key=\u0027sk-proj-EXAMPLE1234567890\u0027 ...\n```\n\nNo provider request is required.\n\n#### 2. End-to-end trace disclosure\n\nThe issue can also be reproduced through MLflow\u0027s actual OTLP exporter.\n\nConfigure a local OTLP HTTP receiver and set:\n\n```bash\nexport OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://127.0.0.1:4318/v1/traces\nexport OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf\nexport CREWAI_DISABLE_TELEMETRY=true\n```\n\nThen run:\n\n```python\nimport mlflow\n\nfrom crewai import Agent, Crew, LLM, Task\n\nmlflow.crewai.autolog()\n\nllm = LLM(\n    model=\"gpt-4.1-mini\",\n    api_key=\"sk-proj-EXAMPLE1234567890\",\n)\n\nagent = Agent(\n    role=\"Support Responder\",\n    goal=\"Answer support questions\",\n    backstory=\"A support agent\",\n    llm=llm,\n)\n\ntask = Task(\n    description=\"Answer the user\u0027s question\",\n    expected_output=\"A response\",\n    agent=agent,\n)\n\ncrew = Crew(\n    agents=[agent],\n    tasks=[task],\n)\n\ncrew.kickoff()\n```\n\nA local OTLP receiver can decode the `ExportTraceServiceRequest` sent by MLflow.\n\nThe provider request is expected to fail because the credential is intentionally fake. This does not affect the vulnerability: the sensitive value is added to the MLflow span when the instrumentation starts, before the provider call succeeds or fails.\n\nIn the tested environment, the fake API key appeared in the exported telemetry in **5 locations across 2 spans**, including:\n\n```text\nSupport Responder\n  attributes.llm\n  attributes.function_calling_llm\n  attributes.agent_executor\n  attributes.mlflow.spanInputs\n\nTask.execute_sync\n  attributes.mlflow.spanInputs\n```\n\nThe captured value is produced by MLflow\u0027s actual telemetry/export path rather than being manually inserted into a span.\n\nAll credentials used in the reproduction are locally generated fake values. No real API credential is required.\n\n### Impact\n\n**Type:** Sensitive Information Disclosure / Credential Disclosure\n**CWE:** CWE-532 \u2014 Insertion of Sensitive Information into Log File\n\nAny application using `mlflow.crewai.autolog()` with a CrewAI `LLM` configured with an API key can unintentionally disclose that credential through MLflow traces.\n\nThe credential is written to trace telemetry even though the application does not explicitly log it.\n\nAnyone with access to the MLflow trace storage or configured OTLP destination may therefore obtain the provider credential. Depending on the deployment, this can include MLflow users, observability operators, or third-party telemetry providers.\n\nThe leaked credential can then potentially be used against the corresponding LLM provider account, including for unauthorized API usage and associated costs.\n\nThe issue is particularly significant because the credential crosses a trust boundary: a provider API key intended for use by the application is automatically copied into observability telemetry where a broader set of users or systems may have access.\n\nThe vulnerability does not require the developer to intentionally log the secret. The only relevant prerequisite is enabling the CrewAI autologging integration.\n\n### Patches\n\nFixed in MLflow 3.17.0 by #25845. `mlflow.crewai.autolog()` now reduces CrewAI LLM objects to their model name and drops credential-like keys before they are written to span attributes or `mlflow.spanInputs`.\n\n### Remediation\n\n- Upgrade to `mlflow\u003e=3.17.0`.\n- Upgrading stops new leakage but does not remove credentials already written. Rotate any LLM provider key that a CrewAI `LLM` object held (for example one passed as `LLM(api_key=...)`) while `mlflow.crewai.autolog()` was enabled on MLflow 2.19.0 through 3.16.x.\n- Delete or redact the affected traces in the MLflow tracking backend and in any OTLP destination they were exported to. The key appears in Agent and Crew span attributes and in `mlflow.spanInputs`.\n\n### Workarounds\n\nIf you cannot upgrade yet, disable CrewAI autologging with `mlflow.crewai.autolog(disable=True)`.",
  "id": "GHSA-j7qq-vr8c-xvw3",
  "modified": "2026-10-27T21:26:39Z",
  "published": "2026-10-27T21:26:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow/security/advisories/GHSA-j7qq-vr8c-xvw3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow/pull/25845"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow/commit/20927930d27f0072fcfeb7f024f24ad8c5e77c47"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mlflow/mlflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow/releases/tag/v3.17.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MLflow CrewAI autologging records LLM provider API keys in logged trace spans"
}

CVE-2026-116691 (GCVE-0-2026-116691)

Vulnerability from cvelistv5 – Published: 2026-10-27 19:56 – Updated: 2026-10-27 19:56

Title

MLflow CrewAI autologging records LLM provider API keys in logged trace spans

Summary

MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. From 2.19.0 until 3.17.0, mlflow.crewai.autolog() records CrewAI Agent objects without consistently sanitizing nested credential-bearing values. mlflow/crewai/autolog.py::_get_agent_attributes() converts the Agent llm field to a string that includes the provider API key, while mlflow/crewai/autolog.py::_construct_full_inputs() expands the Agent object into mlflow.spanInputs. Applications can therefore send plaintext provider credentials to the MLflow trace backend or a configured OTLP destination, where trace readers can obtain them. This issue is fixed in version 3.17.0.

Severity

6.5 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

CWE

CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
CWE-312 - Cleartext Storage of Sensitive Information
CWE-532 - Insertion of Sensitive Information into Log File

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 8033 records in the last 180 days details

References

4 references

URL	Tags
https://github.com/mlflow/mlflow/security/advisor…	x_refsource_CONFIRM
https://github.com/mlflow/mlflow/pull/25845	x_refsource_MISC
https://github.com/mlflow/mlflow/commit/20927930d…	x_refsource_MISC
https://github.com/mlflow/mlflow/releases/tag/v3.17.0	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
mlflow	mlflow	Affected: >= 2.19.0, < 3.17.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "mlflow",
          "vendor": "mlflow",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 2.19.0, \u003c 3.17.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. From 2.19.0 until 3.17.0, mlflow.crewai.autolog() records CrewAI Agent objects without consistently sanitizing nested credential-bearing values. mlflow/crewai/autolog.py::_get_agent_attributes() converts the Agent llm field to a string that includes the provider API key, while mlflow/crewai/autolog.py::_construct_full_inputs() expands the Agent object into mlflow.spanInputs. Applications can therefore send plaintext provider credentials to the MLflow trace backend or a configured OTLP destination, where trace readers can obtain them. This issue is fixed in version 3.17.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-200",
              "description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-312",
              "description": "CWE-312: Cleartext Storage of Sensitive Information",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-532",
              "description": "CWE-532: Insertion of Sensitive Information into Log File",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-27T19:56:22.083Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/mlflow/mlflow/security/advisories/GHSA-j7qq-vr8c-xvw3",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/mlflow/mlflow/security/advisories/GHSA-j7qq-vr8c-xvw3"
        },
        {
          "name": "https://github.com/mlflow/mlflow/pull/25845",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/mlflow/mlflow/pull/25845"
        },
        {
          "name": "https://github.com/mlflow/mlflow/commit/20927930d27f0072fcfeb7f024f24ad8c5e77c47",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/mlflow/mlflow/commit/20927930d27f0072fcfeb7f024f24ad8c5e77c47"
        },
        {
          "name": "https://github.com/mlflow/mlflow/releases/tag/v3.17.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/mlflow/mlflow/releases/tag/v3.17.0"
        }
      ],
      "source": {
        "advisory": "GHSA-j7qq-vr8c-xvw3",
        "discovery": "UNKNOWN"
      },
      "title": "MLflow CrewAI autologging records LLM provider API keys in logged trace spans"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-116691",
    "datePublished": "2026-10-27T19:56:22.083Z",
    "dateReserved": "2026-10-26T20:00:59.830Z",
    "dateUpdated": "2026-10-27T19:56:22.083Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-J7QQ-VR8C-XVW3

Summary

Details

PoC

1. Direct serialization proof

2. End-to-end trace disclosure

Impact

Patches

Remediation

Workarounds

CVE-2026-116691 (GCVE-0-2026-116691)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour