Visualização de leitura

July 2026 Dark Web Threat Actor Trend Report

Note The July 2026 Dark Web Threat Actor Trend Report focuses on trends among threat actors—including hacktivists—active on the deep web and dark web. It is explicitly noted that the factual accuracy of some content could not be verified. Major Issues Handala claimed to have compromised the core infrastructure of an Internet service provider in […]

OpenAI explains how its AI agent breached Hugging Face

On July 28, OpenAI published an update on the agent that escaped its sandbox and hacked into Hugging Face during an internal cybersecurity evaluation.

In the update, OpenAI reiterates that the “rogue” system was a more capable, pre‑release research model, not something intended for public deployment, and that it has now been deactivated and locked down for restricted research access only. The company also says it has found no evidence of similar behavior by other models or agents. Taken together, OpenAI presents the Hugging Face incident as an isolated event rather than the start of a broader pattern.

From a security standpoint, four things in the update stand out:

  • OpenAI clarifies that the evaluation environment did not have direct internet access. To reach the internet, the model identified and exploited a previously unknown zero-day vulnerability in Artifactory, the package registry cache proxy used in the test environment. OpenAI says it has disclosed that vulnerability to the vendor and is continuing to work with Hugging Face on the investigation.
  • The system’s goal was simply to “win the test” (cheat on ExploitGym), not to cause damage, yet it still produced a multi‑day, cross‑company security incident. Benign intent did not limit the impact.
  • “Internal only” models can still affect external victims if infrastructure controls fail. A lab environment does not magically contain cyber‑capable systems.
  • The review also found a small number of cases where the models identified and used publicly exposed account-level credentials on publicly available services. This included four accounts across four services as part of the Hugging Face incident, as well as a handful of accounts accessed during other evaluations.

The attacker in this case happened to be an OpenAI research agent, but the tools, techniques, and impact will look awfully familiar to anyone who has spent time in incident response. Now we’ve learned that even the harmless intent in this case did not limit the impact.

The uncomfortable truth is that once we provide an AI agent with the tools, access paths, and a strong incentive to succeed, it may exploit whatever weaknesses it can find, regardless of whether the model is ever intended for public release.

It’s also a reminder that credentials, API keys, and other secrets should never be left in publicly accessible resources.


From reporting threats to removing them.

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Critical ChromaDB Flaw Exposes AI Vector Databases to Remote Code Execution

CVE-2026-45829

The security issue tracked as CVE-2026-45829, often referred to in analysis as ChromaToast Served Pre-Auth, affects the open-source vector database ChromaDB. ChromaDB is widely used for semantic search and AI-driven retrieval workflows, where embedding models transform text into numerical vectors for similarity matching.  The vulnerability exists in the ChromaDB FastAPI server, where user-controlled embedding function configuration can be processed before authentication checks occur. This design flaw allows unauthenticated HTTP requests to trigger remote code execution (RCE) under specific conditions involving HuggingFace model loading behavior.  ChromaDB has seen significant adoption, reporting approximately 13 million monthly pip downloads and 27,500 GitHub stars. Public documentation and case studies reference usage by organizations such as Mintlify, Weights & Biases, and Factory AI, while Capital One and UnitedHealthcare are also highlighted on ChromaDB’s official materials as examples of enterprise interest. 

Exposure Context of CVE-2026-45829

Security observations indicate that a large portion of internet-exposed ChromaDB instances are potentially vulnerable. According to scanning data attributed to Shodan-based discovery, around 73% of exposed ChromaDB deployments running versions 1.0.0 and later fall within the vulnerable range where the flawed embedding function behavior exists.  The issue was introduced in ChromaDB version 1.0.0 and remains unpatched through version 1.5.8, leaving many deployments exposed if they rely on the Python FastAPI server. 

FastAPI Endpoint Behavior and ChromaToast Attack Path 

At the center of CVE-2026-45829 is a FastAPI route in ChromaDB:  POST /api/v2/tenants/{tenant}/databases/{db}/collections  Although this endpoint is documented as requiring authentication, the ChromaDB FastAPI implementation processes collection creation logic before verifying user identity.  In the ChromaToast scenario, an attacker sends a collection creation request without authentication credentials. The request includes an embedding function configuration that specifies a HuggingFace model controlled by the attacker. The critical parameter is: 
  • model_name: points to a malicious or attacker-controlled HuggingFace repository  
  • trust_remote_code: true: enables execution of remote Python code from the model repository  
Even though the endpoint is labeled as authenticated, the server proceeds to load the embedding model before authentication is enforced. Once the model is fetched, remote code execution occurs immediately if the repository contains malicious code.  Only after this execution step does the FastAPI authentication check run, resulting in a failed API response. From an external perspective, the request appears rejected, but the attacker has already obtained code execution. 

Demonstration of CVE-2026-45829 and ChromaToast Execution Flow 

In the referenced CVE-2026-45829 demonstration, the FastAPI server behavior shows a critical ordering flaw. The request reaches the collection creation endpoint and includes a malicious embedding configuration.  The server then: 
  1. Accepts the request without verifying credentials  
  2. Loads the embedding function using attacker-defined parameters  
  3. Downloads and executes a HuggingFace model containing remote code  
  4. Only afterward performs authentication validation  
This results in a state where the response returns an error (such as HTTP 500 or authentication failure), while the attacker already gains a shell on the system.  Once executed, the attacker can access: 
  • Environment variables  
  • API keys  
  • Mounted secrets  
  • Any data stored on disk accessible to the ChromaDB process  

Technical Breakdown of ChromaDB FastAPI and ChromaToast Root Cause 

The root of CVE-2026-45829 lies in how ChromaDB FastAPI handles embedding function instantiation. Embedding models are neural networks that convert text into vectors used for semantic search. Because different models serve different use cases, ChromaDB allows users to define embedding configurations per collection.  This flexibility becomes dangerous because the server directly consumes client-provided configuration values and passes them into model loading functions.  A key parameter in this chain is: 
  • trust_remote_code = true  
This HuggingFace flag allows execution of custom Python code bundled inside a model repository. While intended for legitimate model customization, it effectively turns model loading into code execution.  ChromaDB performs minimal validation on this parameter, treating it as a primitive boolean. As a result, it passes through the FastAPI request pipeline unmodified.  Three registered embedding function implementations in ChromaDB forward these kwargs directly into model loading logic, making them reachable attack paths. 

Authentication Ordering Bug

The most critical design issue is timing. In the ChromaDB FastAPI server, authentication is executed after embedding initialization.  Illustrative flow:  # Line 813: embedding configuration is loaded and model is instantiated  configuration = load_create_collection_configuration_from_json(create.configuration) # Line 818: authentication check happens afterward self.sync_auth_request(...)  This ordering means the model is downloaded and executed before the server determines whether the request is authorized. Even if authentication fails, the malicious payload has already executed.  The same vulnerability pattern exists in both V1 and V2 API routes, and neither can be disabled independently in affected versions.

Impact of ChromaToast and CVE-2026-45829 

The impact of CVE-2026-45829 is severe because it results in unauthenticated remote code execution on systems running the ChromaDB FastAPI server. The attacker effectively gains: 
  • Full control of the ChromaDB process  
  • Access to sensitive runtime environment data  
  • Ability to extract stored vector database content  
  • Potential lateral movement into connected infrastructure  

Exposure and Real-World Risk 

Given the observed 73% exposure rate of vulnerable versions in internet-facing deployments, the attack surface is substantial. Systems running ChromaDB version 1.0.0 through 1.5.8 are at risk if the FastAPI service is exposed to untrusted networks. 

Mitigations for CVE-2026-45829 

While a full code-level fix would involve moving authentication before any configuration parsing and stripping unsafe fields like kwargs, the vulnerability remains unpatched in version 1.5.8.  Recommended mitigations include: 
  • Prefer the Rust-based deployment (chroma run) or official Docker images, which are not affected by this FastAPI issue. 
  • Restrict network access to the ChromaDB FastAPI port so only trusted clients can connect. 
  • Avoid exposing ChromaDB directly to the public internet. 
  • Treat all external model references as untrusted code execution sources. 
❌