CVE-2025-52494: Adacore Ada Web Server DoS Vulnerability

CVE-2025-52494 Overview

CVE-2025-52494 is a denial-of-service (DoS) vulnerability affecting Adacore Ada Web Server (AWS) versions prior to 25.2. The vulnerability stems from improper handling of SSL handshakes during connection initialization, allowing attackers to exhaust server resources by exploiting the absence of proper timeout configurations during the TLS handshake phase.

Critical Impact

Attackers can completely exhaust all available worker threads on vulnerable AWS instances, rendering the server unable to process any new legitimate HTTPS connections and effectively causing a complete service outage.

Affected Products

• Adacore Ada Web Server (AWS) versions before 25.2
• All HTTPS-enabled AWS deployments using default timeout configurations
• Systems with limited worker thread pools are particularly susceptible

Discovery Timeline

• September 3, 2025 - CVE-2025-52494 published to NVD
• September 8, 2025 - Last updated in NVD database

Technical Details for CVE-2025-52494

Vulnerability Analysis

This vulnerability represents a classic resource exhaustion attack vector (CWE-400) targeting the SSL/TLS handshake mechanism in Adacore Ada Web Server. The core issue lies in how the server processes incoming HTTPS connections during the initial handshake phase.

When a client initiates an HTTPS connection, AWS performs the SSL handshake before assigning the connection to a processing slot. The server architecture dedicates a worker thread (referred to as a "Line" in AWS terminology) to handle each connection. However, the handshake phase lacks a dedicated timeout mechanism, instead relying on the default socket timeout which is effectively infinite.

This design flaw creates a window where an attacker can send a specially crafted TLS ClientHello message with incorrect length values. The malformed packet causes the server to enter a blocking wait state, expecting additional data that will never arrive. Since no timeout terminates this wait, the worker thread remains occupied indefinitely.

Root Cause

The root cause is the absence of a specific timeout configuration for the SSL handshake phase during connection initialization. The server relies on the default socket timeout (effectively infinite) rather than implementing a dedicated, finite timeout for the handshake operation. This allows connections to remain in a pending state indefinitely, consuming worker thread resources without ever completing the handshake or being terminated.

Attack Vector

The attack exploits the network-accessible HTTPS interface and requires no authentication or user interaction. An attacker initiates multiple HTTPS connections to the target server, each sending a malformed TLS ClientHello message with deliberately incorrect length field values.

The malformed ClientHello causes the server's SSL implementation to wait for additional bytes that the attacker never sends. By repeating this process up to the server's maximum connection limit, all available worker threads become blocked waiting for data, preventing the server from accepting or processing any new legitimate requests.

The attack is particularly effective because:

1. Each malicious connection consumes minimal attacker resources (a single TCP socket)
2. The server commits a full worker thread per connection
3. No timeout exists to automatically free blocked threads
4. The attack persists until the server is restarted or connections are manually terminated

Detection Methods for CVE-2025-52494

Indicators of Compromise

• Unusual number of TCP connections in a half-open or handshake-pending state on HTTPS ports
• Worker thread exhaustion alerts or log entries indicating no available processing slots
• Increased connection timeouts reported by legitimate clients attempting to connect
• Network traffic analysis showing incomplete TLS handshakes from specific source IPs

Detection Strategies

• Monitor for connection counts per source IP that exceed normal thresholds, particularly connections that remain in handshake state
• Implement alerting on worker thread utilization metrics approaching maximum capacity
• Analyze TLS handshake completion rates; significant drops may indicate active exploitation
• Review server logs for patterns of connections that never progress past the handshake phase

Monitoring Recommendations

• Deploy network-level monitoring to track incomplete TLS handshake attempts
• Configure application performance monitoring to alert on worker thread saturation
• Establish baseline metrics for normal handshake completion times and connection throughput
• Implement connection rate limiting at the network perimeter for HTTPS services

How to Mitigate CVE-2025-52494

Immediate Actions Required

• Upgrade Adacore Ada Web Server to version 25.2 or later immediately
• Review and configure appropriate SSL handshake timeouts if manual configuration options are available
• Implement network-level rate limiting to restrict connection attempts per source IP
• Consider deploying a reverse proxy or load balancer with built-in TLS handshake timeout capabilities

Patch Information

Adacore has released version 25.2 of Ada Web Server which addresses this vulnerability. Organizations should consult the AdaCore Security Advisory SEC.AWS-0095 for detailed patching instructions and release notes. The patch introduces proper timeout handling for the SSL handshake phase, ensuring that connections that fail to complete the handshake within a reasonable timeframe are automatically terminated.

Workarounds

• Deploy a TLS-terminating reverse proxy (such as nginx or HAProxy) in front of AWS instances with configured handshake timeouts
• Implement connection rate limiting at the firewall or network level to reduce the impact of connection flooding
• Configure operating system-level TCP timeout parameters to provide a backstop against indefinite connection holds
• Reduce the maximum number of concurrent connections if the application can tolerate it, limiting the impact of resource exhaustion

# Example nginx configuration for TLS termination with handshake timeout
# Place nginx in front of AWS to handle TLS and enforce timeouts

server {
    listen 443 ssl;
    server_name your-aws-server.example.com;
    
    # SSL handshake timeout (default is 60s, reduce for protection)
    ssl_handshake_timeout 10s;
    
    # Connection timeouts
    proxy_connect_timeout 10s;
    proxy_read_timeout 30s;
    
    # Rate limiting
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;
    
    location / {
        proxy_pass http://localhost:8080;  # AWS backend
    }
}