Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-10952

CVE-2025-10952: ml-logger Information Disclosure Flaw

CVE-2025-10952 is an information disclosure vulnerability in geyang ml-logger affecting the stream_handler function. Attackers can remotely exploit this flaw to access sensitive data. This article covers technical details, impact, and mitigation.

Published:

CVE-2025-10952 Overview

CVE-2025-10952 is an information disclosure vulnerability in the geyang ml-logger project, an open-source logging and experiment tracking tool used in machine learning workflows. The flaw resides in the stream_handler function within ml_logger/server.py, part of the File Handler component. An attacker can manipulate the key argument to trigger unauthorized disclosure of information over the network. The issue affects code up to commit acf255bade5be6ad88d90735c8367b28cbe3a743. Because the project uses continuous delivery with rolling releases, no discrete affected or fixed version numbers are published. A public exploit has been disclosed, increasing the likelihood of opportunistic abuse. The weakness is classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

Critical Impact

Remote, unauthenticated attackers can retrieve information from systems running vulnerable ml-logger deployments by manipulating the key parameter passed to stream_handler.

Affected Products

  • geyang ml-logger up to commit acf255bade5be6ad88d90735c8367b28cbe3a743
  • ml_logger/server.py File Handler component
  • Rolling-release deployments (no discrete version boundaries)

Discovery Timeline

  • 2025-09-25 - CVE-2025-10952 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-10952

Vulnerability Analysis

The vulnerability exists in the stream_handler function of ml_logger/server.py. This handler is part of the File Handler subsystem that serves logging artifacts and streamed content over the network. By manipulating the key argument supplied to the handler, a remote attacker without credentials can cause the server to disclose information it should not expose. The exposure aligns with CWE-200, where insufficient validation or scoping of a user-controlled identifier permits access to data outside the requester's intended context. Because ml-logger is often deployed on internal experiment infrastructure that stores training artifacts, model metadata, and logs, disclosed content may include research data or environmental details useful for follow-on attacks.

Root Cause

The root cause is improper handling of the client-controlled key argument in stream_handler. The function does not adequately constrain or validate the key before using it to select or stream file-backed content. As a result, crafted values allow the response path to return data that the requester should not be authorized to read. Additional context is available in the GitHub Issue Discussion.

Attack Vector

Exploitation occurs over the network against a reachable ml-logger server. No authentication, user interaction, or elevated privileges are required. An attacker sends a request to the file-handling endpoint served by stream_handler with a manipulated key value. The server processes the request and returns information influenced by the attacker-supplied key. A public exploit has been referenced through VulDB entry #325822, so defenders should assume opportunistic scanning against exposed instances.

Detection Methods for CVE-2025-10952

Indicators of Compromise

  • Inbound HTTP requests to ml-logger endpoints backed by stream_handler in ml_logger/server.py from untrusted or unexpected source addresses.
  • Requests containing anomalous, encoded, or traversal-like values in the key parameter.
  • Unusual outbound response sizes from the ml-logger server for read operations that historically returned little or no data.

Detection Strategies

  • Enable verbose request logging on the ml-logger server and alert on key values that do not match the naming patterns used by legitimate experiments.
  • Deploy a web application firewall or reverse proxy in front of ml-logger with rules that inspect the key argument for suspicious characters and path fragments.
  • Correlate access logs with authenticated user or workload identities; flag requests that reach stream_handler without an associated session context.

Monitoring Recommendations

  • Monitor network exposure of ml-logger instances and alert when the service is reachable from outside the intended research subnet.
  • Track request rate and response volume per source IP to identify enumeration of key values.
  • Review server access logs regularly for repeated 200-response reads from a single client against distinct keys.

How to Mitigate CVE-2025-10952

Immediate Actions Required

  • Restrict network access to the ml-logger server so it is reachable only from trusted hosts, using firewall rules, security groups, or a VPN.
  • Place ml-logger behind an authenticating reverse proxy that enforces identity checks before requests reach stream_handler.
  • Audit stored artifacts and logs on the server to identify sensitive material that should be moved out of the ml-logger data directory.

Patch Information

The project uses continuous delivery with rolling releases, so no version-tagged fix is published. Track remediation progress in the upstream GitHub Issue Discussion and pull the latest commit from the repository once a maintainer merges a fix that validates the key argument in stream_handler.

Workarounds

  • Do not expose ml-logger directly to untrusted networks; bind it to localhost or a private interface.
  • Add an authentication layer, such as HTTP basic auth or mTLS, at the reverse proxy in front of the service.
  • Segregate sensitive experiments onto separate ml-logger instances with isolated data directories to limit blast radius.
bash
# Example: restrict ml-logger to localhost and require reverse-proxy auth
# Bind the server to the loopback interface only
python -m ml_logger.server --host 127.0.0.1 --port 8081

# Sample nginx reverse proxy with basic auth in front of ml-logger
# /etc/nginx/conf.d/ml-logger.conf
server {
    listen 443 ssl;
    server_name ml-logger.internal;

    auth_basic "ml-logger";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:8081;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.