MCP Security
Tel-Aviv University
MCP Security
Tel-Aviv University
MadeYouReset is a new HTTP2 vulnerability that exploits a common design flaw in HTTP2 implementation, enabling attackers to launch massive DoS attacks. The flaw has been assigned multiple CVEs, and corresponding patches have been released by many vendors.
MadeYouReset is comparable in power and core problem to the notorious Rapid Reset zero-day vulnerability which was exploited in 2023 and ultimately crashed large-scale services. DoS attacks are among the most serious threats to the Internet, overwhelming systems until legitimate users are denied access and causing significant disruption and losses.
HTTP2 powers much of today’s web, with over 60% of top sites using it and carrying about a third of global HTTP traffic. Its central role makes HTTP2 servers prime targets for DoS attacks.
Operationally, MadeYouReset bypasses the typical server-imposed limit of 100 concurrent HTTP2 requests per TCP connection from a client. This limit is intended to mitigate DoS attacks by restricting the number of simultaneous requests a client can send. With MadeYouReset, an attacker can send many thousands of requests, creating a denial-of-service condition for legitimate users and, in some vendor implementations, escalating into out-of-memory crashes.
This work highlights the importance of collaboration between the cybersecurity academic and industry communities. The discovery is part of research conducted at Tel-Aviv University. We thank CERT/CC for managing the disclosure process and the vendors for helpful feedback. This research is partly supported by Imperva.
Amplification Reflection Distributed Denial-of-Service (AR-DDoS) attacks remain a formidable threat, exploiting stateless protocols to flood victims with illegitimate traffic.
Recent advances have enabled data-plane defenses against such attacks, but existing solutions typically assume symmetric routing and are limited to a single switch. These assumptions fail in modern networks where asymmetry is common, resulting in
dropped legitimate responses and persistent connectivity issues.
This paper presents ReAct, an in-network defense for AR-DDoS that is robust to asymmetry. ReAct performs request-response correlation across switches using programmable data planes and a sliding-window of Bloom filters. To handle asymmetric
traffic, ReAct introduces a data-plane-based request forwarding mechanism, enabling switches to validate responses even when paths differ. ReAct can automatically adapt to routing changes with minimal intervention, ensuring continued protection even
in dynamic network environments. We implemented ReAct on both a P4 interpreter and NVIDIA’s BlueField-3, demonstrating its applicability across multiple platforms. Evaluation results show that ReAct filters nearly all attack traffic without dropping
legitimate responses-even under high-volume attacks and asymmetry. Compared to state-of-the-art approaches, ReAct achieves significantly lower false positives. To our knowledge, ReAct is the first data-plane AR-DDoS defense that supports dynamic, crossswitch collaboration, making it uniquely suitable for deployment
in networks with asymmetry.
Service Mesh has become essential for modern
cloud-native applications by abstracting communication between microservices and providing zero-trust security, observability, and advanced traffic control without requiring code changes. This allows developers to leverage new network capabilities and focus on application logic without managing network complexities.
However, the additional layer can significantly impact system performance, latency, and resource consumption, posing challenges for cloud managers and operators.
In this work, we investigate the impact of the mTLS pro-
tocol—a common security and authentication mechanism—on application performance within service meshes. Recognizing that security is a primary motivation for deploying a service mesh, we evaluated the performance overhead introduced by leading service meshes: Istio, Istio Ambient, Linkerd, and Cilium. Our experiments were conducted by testing their performance in service-to-service communications within a Kubernetes cluster.
Our experiments reveal significant performance differences (in terms of latency and resource consumption) among the service meshes, rooting from the different architecture of the service mesh, sidecar versus sidecareless, and default extra features hidden in the mTLS implementation. Our results highlight the understanding of the service mesh architecture and its impact on performance.