[SECURITY] [Elastic.Transport] Fixes for CWE-331 (Insufficient Entropy) and CWE-404 (Improper Resource Shutdown)

[luxiaodui]

Hi Elasticsearch Official Team,

Hello!

I have discovered two security vulnerabilities during a code security scan of my project. After investigation, I confirmed that the root cause of these vulnerabilities lies in the Elastic.Transport module source code.

I have upgraded Elastic.Transport to the latest version, but verification shows that these two vulnerabilities remain unpatched.

The specific scan information is as follows:

Improper Resource Shutdown or Release (CWE ID 404)

Description

The application fails to release (or incorrectly releases) a system resource before it is made available for re-use. This condition often occurs with resources such as database connections or file handles. Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, it may be possible to launch a denial of service attack by depleting the resource pool.

Insufficient Entropy (CWE ID 331)

Description

Standard random number generators do not provide a sufficient amount of entropy when used for security purposes. Attackers can brute force the output of pseudorandom number generators such as rand().

To address the above issues, I have obtained the latest source code of Elastic.Transport and completed a self-fix based on it. The specific modifications are as follows:

---

Fix Overview

Fixed CWE-331 (Insufficient Entropy) and CWE-404 (Improper Resource Shutdown) security vulnerabilities.

Fix Date: 2026-03-04

---

Vulnerability 1: CWE-331 - Insufficient Entropy

Problem Description

Using the standard pseudo-random number generator System.Random produces insufficient entropy, allowing attackers to brute force the random number output.

Affected File

• src/Elastic.Transport/Components/NodePool/StaticNodePool.cs

Fix Content

1. Replace Random with RandomNumberGenerator.Create()
2. Add GetSecureRandomInt() method to generate cryptographically secure random integers
3. Use cryptographic random numbers for node sorting in SortNodes()
4. Implement Dispose() to release cryptographic random number generator resources

Code Changes

// Add using
using System.Security.Cryptography;

// Add field
private readonly RandomNumberGenerator _secureRng = RandomNumberGenerator.Create();

// Add method
private int GetSecureRandomInt()
{
    var randomBytes = new byte[4];
    _secureRng.GetBytes(randomBytes);
    return BitConverter.ToInt32(randomBytes, 0);
}

// Modify sorting method
protected IOrderedEnumerable<Node> SortNodes(IEnumerable<Node> nodes) =>
    _nodeScorer != null
        ? nodes.OrderByDescending(_nodeScorer)
        : nodes.OrderBy(n => Randomize ? GetSecureRandomInt() : 1);

// Add resource disposal
protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        _secureRng.Dispose();
    }
    base.Dispose(disposing);
}

---

Vulnerability 2: CWE-404 - Improper Resource Shutdown

Problem Description

The application fails to properly release system resources (such as Stream, HttpResponseMessage) before they are reused, which may lead to resource leaks and denial of service attacks.

Fixed Files List

File 1: InMemoryRequestInvoker.cs

Path: src/Elastic.Transport/Components/TransportClient/InMemoryRequestInvoker.cs

Issue: The responseStream created in BuildResponse and BuildResponseAsync methods may leak during exceptions.

Fix: Add try-catch blocks to ensure the stream is released during exceptions.

Code Changes:

// BuildResponse method
Stream responseStream = body != null ? boundConfiguration.MemoryStreamFactory.Create(body) : boundConfiguration.MemoryStreamFactory.Create(EmptyBody);

try
{
    var response = ResponseFactory.Create<TResponse>(..., responseStream, ...);

    if (!response.LeaveOpen)
    {
        responseStream?.Dispose();
    }
    else
    {
        response.LinkedDisposables = [responseStream];
    }

    return response;
}
catch
{
    responseStream?.Dispose();
    throw;
}

// BuildResponseAsync method - same pattern as above

---

File 2: DefaultResponseFactory.cs

Path: src/Elastic.Transport/Responses/DefaultResponseFactory.cs

Issue: The inMemoryStream created in CreateCoreAsync method may leak during exceptions.

Fix: Add try-catch blocks to ensure the memory stream is released during exceptions.

Code Changes:

var ownsStream = false;
MemoryStream? inMemoryStream = null;

try
{
    if (boundConfiguration.DisableDirectStreaming)
    {
        inMemoryStream = boundConfiguration.MemoryStreamFactory.Create();

        if (isAsync)
            await responseStream.CopyToAsync(inMemoryStream, BufferedResponseHelpers.BufferSize, cancellationToken).ConfigureAwait(false);
        else
            responseStream.CopyTo(inMemoryStream, BufferedResponseHelpers.BufferSize);

        details.ResponseBodyInBytes = BufferedResponseHelpers.SwapStreams(ref responseStream, ref inMemoryStream);
        ownsStream = true;
    }

    if (ValidateResponseContentType(boundConfiguration.Accept, contentType))
    {
        if (isAsync)
            response = await builder.BuildAsync<TResponse>(...).ConfigureAwait(false);
        else
            response = builder.Build<TResponse>(...);
    }

    if (ownsStream && (response is null || !response.LeaveOpen))
        responseStream?.Dispose();
}
catch
{
    inMemoryStream?.Dispose();
    throw;
}

---

File 3: TransportSerializerExtensions.cs

Path: src/Elastic.Transport/Components/Serialization/TransportSerializerExtensions.cs

Issue: The Utf8JsonWriter created in Deserialize<T> and Deserialize methods is not released.

Fix: Add using statement to ensure Utf8JsonWriter is released.

Code Changes:

// Deserialize<T> method
using var jsonDoc = JsonSerializer.Deserialize<JsonDocument>(ref reader);

memoryStreamFactory ??= TransportConfiguration.DefaultMemoryStreamFactory;
using var ms = memoryStreamFactory.Create();

using (var writer = new Utf8JsonWriter(ms))
{
    jsonDoc.WriteTo(writer);
    writer.Flush();
}
ms.Position = 0;

return serializer.Deserialize<T>(ms);

// Deserialize method - same pattern as above

---

Notes

1. All fixes follow the original code style and patterns
2. Use LinkedDisposables = [resource] pattern to maintain consistency with existing code
3. Fixes do not change any public API signatures, maintaining backward compatibility
4. Exception handling paths ensure resource release, normal path behavior remains unchanged

---

Please note that this fix currently only takes effect in my local project and will be overwritten once Elastic.Transport is upgraded to future versions. I sincerely hope the official team will review the aforementioned fix and consider integrating it into upcoming releases. This would help address the two identified issues and further enhance the security and reliability of Elastic.Transport.

Should you reach any decisions or require additional information or my cooperation in any way, please do not hesitate to contact me.

Thank you!