CVE-2026-64868 in new-api
Summary
by MITRE • 08/17/2026
New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.11, POST /api/stripe/webhook, POST /api/creem/webhook, and POST /api/waffo/webhook read and log full request bodies before signature validation in router/api-router.go and the payment controllers, allowing an unauthenticated attacker to cause memory pressure, container restarts, or disk exhaustion without forging a successful payment. This issue is fixed in version 1.0.0-rc.11.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in New API versions prior to 1.0.0-rc.11 represents a significant security flaw within the application's webhook handling architecture, specifically affecting endpoints designed for payment processing integrations with Stripe, Creem, and Waffo. As an LLM gateway and AI asset management system, New API relies heavily on external webhooks to synchronize state changes regarding payments and subscriptions. The core technical deficiency lies in the order of operations executed by the server when receiving POST requests at /api/stripe/webhook, /api/creem/webhook, and /api/waffo/webhook. Instead of first validating the cryptographic signature provided by the payment provider to ensure the request's authenticity and integrity, the application proceeds to read the entire HTTP request body into memory for logging purposes. This implementation detail creates a critical window where unauthenticated actors can exploit the system before any security checks are applied.
This flaw is categorized under CWE-400, which describes Uncontrolled Resource Consumption, as well as CWE-789, which pertains to Memory Exposure when sensitive data such as full request bodies containing potentially private information is logged without prior validation or sanitization. From an ATT&CK perspective, this vulnerability aligns with the T1496 technique of Resource Hijacking, where attackers leverage compromised resources for disruptive purposes rather than direct financial gain in this specific context. The attacker does not need to forge a valid payment signature because the damage is inflicted through resource exhaustion rather than unauthorized transaction processing. By sending large payloads or numerous rapid requests to these webhook endpoints, an unauthenticated user can force the application to allocate excessive amounts of memory and disk space for logging purposes.
The operational impact of this vulnerability is severe due to the typical deployment environments of such services, which often utilize containerized architectures like Docker or Kubernetes. When the server attempts to log massive request bodies, it consumes available RAM rapidly, leading to out-of-memory conditions that trigger automatic restarts by orchestration tools. Furthermore, if the logging mechanism writes these large bodies to disk logs without size limits or rotation policies tailored for webhook traffic, it can lead to rapid disk exhaustion. These events result in denial of service for legitimate users attempting to access the LLM gateway or manage AI assets. The system becomes unstable and unresponsive, disrupting business operations and potentially causing data loss if transactions are interrupted during restarts.
Mitigation strategies must address both the immediate code flaw and broader logging practices. The primary fix involves reordering the request processing pipeline so that signature validation occurs before any attempt to read or log the full body content. This ensures that only verified, authentic requests from trusted payment providers proceed to resource-intensive operations like logging. Additionally, developers should implement strict rate limiting on webhook endpoints to prevent abuse even after the code is patched. It is also advisable to configure logging frameworks with maximum payload size limits and avoid logging sensitive data such as full request bodies unless absolutely necessary for debugging, opting instead for metadata-only logs in production environments. Organizations running affected versions must upgrade immediately to version 1.0.0-rc.11 or later to resolve this issue and restore the integrity of their payment processing infrastructure.