deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-69rh-hccr-cxrj
Package: lomkit/laravel-rest-api (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-1173: Improper Use of Validation Framework
Vulnerable versions: < 2.13.0
Patched in: 2.13.0

Summary: Laravel Rest Api has a Search Validation Bypass

Details:
A validation bypass vulnerability was discovered  prior to version 2.13.0, where multiple validations defined for the same attribute could be silently overridden. Due to how the framework merged validation rules across multiple contexts (such as index, store, and update actions), malicious actors could exploit this behavior by crafting requests that bypass expected validation rules, potentially injecting unexpected or dangerous parameters into the application.

Impact:

This could lead to unauthorized data being accepted or processed by the API, depending on the context in which the validation was bypassed.

Patch:

The issue was fixed in [PR #172](https://github.com/Lomkit/laravel-rest-api/pull/172) by ensuring that multiple rule definitions are merged correctly rather than overwritten.
GitHub Security Advisory: GHSA-xg53-mhh9-3cq7
Package: nitsan/ns-backup (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 13.0.1
Patched in: 13.0.1

Summary: The Backup Plus extension for TYPO3 (ns_backup) allows XSS

Details:
The ns_backup extension through 13.0.0 for TYPO3 allows XSS.
GitHub Security Advisory: GHSA-cvgc-mx2w-h3w8
Package: sjbr/sr-feuser-register (COMPOSER)
Severity: HIGH (CVSS 8.6)
CWE: CWE-425: Direct Request ('Forced Browsing'), CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.1.0, < 12.5.0
Patched in: 12.5.0

Summary: The Front End User Registration extension for TYPO3 (sr_feuser_register) allows Insecure Direct Object Reference

Details:
The sr_feuser_register extension through 12.4.8 for TYPO3 allows Insecure Direct Object Reference. This allows attackers to read arbitrary files.
GitHub Security Advisory: GHSA-463c-jhp2-4mm7
Package: nitsan/ns-backup (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 13.0.1
Patched in: 13.0.1

Summary: The Backup Plus extension for TYPO3 (ns_backup) allows command injections

Details:
The ns_backup extension through 13.0.0 for TYPO3 allows command injection when creating a backup. An authenticated backend user with access to the extensions backend module is required to exploit the vulnerability.
GitHub Security Advisory: GHSA-qfm8-78qf-p75j
Package: sjbr/sr-feuser-register (COMPOSER)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 5.1.0, < 12.5.0
Patched in: 12.5.0

Summary: The Front End User Registration extension for TYPO3 (sr_feuser_register) Remote Code Execution

Details:
The sr_feuser_register extension through 12.4.8 for TYPO3 allows Remote Code Execution via unsafe deserialization.
GitHub Security Advisory: GHSA-hq4f-5qjv-fwrg
Package: nitsan/ns-backup (COMPOSER)
Severity: HIGH (CVSS 8.6)
CWE: CWE-425: Direct Request ('Forced Browsing')
Vulnerable versions: < 13.0.1
Patched in: 13.0.1

Summary: The Backup Plus extension for TYPO3 (ns_backup) has a Predictable Resource Location

Details:
The ns_backup extension through 13.0.0 for TYPO3 has a Predictable Resource Location. This allows an unauthenticated remote user to download created backups and configuration files.
GitHub Security Advisory: GHSA-jjwh-4x89-7f5w
Package: renolit/reint-downloadmanager (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-425: Direct Request ('Forced Browsing'), CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 4.0.2
Patched in: 4.0.2

Summary: reint_downloadmanager TYPO3 Extension is susceptible to Insecure Direct Object Reference

Details:
Insecure Direct Object Reference in the reint_downloadmanager TYPO3 extension allows remote attackers to read arbitrary files via the downloaduid parameter in the downloadAction.
GitHub Security Advisory: GHSA-jjwh-4x89-7f5w
Package: renolit/reint-downloadmanager (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-425: Direct Request ('Forced Browsing'), CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.0.0, < 5.0.1
Patched in: 5.0.1

Summary: reint_downloadmanager TYPO3 Extension is susceptible to Insecure Direct Object Reference

Details:
Insecure Direct Object Reference in the reint_downloadmanager TYPO3 extension allows remote attackers to read arbitrary files via the downloaduid parameter in the downloadAction.
GitHub Security Advisory: GHSA-xxwr-wv9g-7jw3
Package: in2code/femanager (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-284: Improper Access Control, CWE-425: Direct Request ('Forced Browsing'), CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.5.0, < 5.5.5
Patched in: 5.5.5

Summary: The femanager TYPO3 extension allows Insecure Direct Object Reference

Details:
Insecure Direct Object Reference (IDOR) in the femanager TYPO3 extension allows attackers to view frontend user data via a user parameter in the newAction of the newController.
GitHub Security Advisory: GHSA-wfr5-454p-mjc2
Package: OpenTelemetry.Exporter.Instana (NUGET)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 1.0.7
Patched in: 1.1.0

Summary: OpenTelemetry.Exporter.Instana bypasses TLS certificate validation when a proxy is configured

Details:
### Summary

The `OpenTelemetry.Exporter.Instana` NuGet package does not validate HTTPS/TLS certificates are valid when sending telemetry to a configured Instana back-end when a proxy is configured using the `INSTANA_ENDPOINT_PROXY` environment variable.

If a network attacker can Man-in-the-Middle (MitM) the proxy connection, all OpenTelemetry telemetry data and the Instana API key are exposed to the attacker.

### Details

The [`Transport.ConfigureBackendClient()`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/b53b6a74fde21a4cee344e584b51a0fe5bf1f337/src/OpenTelemetry.Exporter.Instana/Implementation/Transport.cs#L132-L158) method creates an `HttpClient` instance that completely disables TLS server certificate validation if the `INSTANA_ENDPOINT_PROXY` is configured with a valid proxy URL with no ability to re-enable it.

### Impact

If the configured proxy is attacker-controlled (or a network attacker MitM the connection), or if it is possible for the process' configuration to be changed to add an attacker-provided value for `INSTANA_ENDPOINT_PROXY` then all Instana telemetry could be read by an unauthorized party and the service's Instana API key compromised, potentially before being forwarded to Instana presenting no noticeable loss of telemetry data without a valid TLS server certificate being presented to the client that matches the expected hostname or IP address.

### Mitigation

The proxy configured by the `INSTANA_ENDPOINT_PROXY` environment variable must be malicious or be possible to be subject to a MitM attack.

### Workarounds

Do not configure the `INSTANA_ENDPOINT_PROXY` environment variable.

### Remediation

[#4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153) refactors `HttpClient` creation so that TLS certificate validation is no longer disabled by default when using a proxy.

In environments where this capability is required, for example for local development, the previous behaviour can be restored using the `` option:

```csharp
builder.AddInstanaExporter((options) =>
{
    options.HttpClientFactory = () =>
    {
        var handler = new HttpClientHandler()
        {
#if NET
            ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator,
#else
            ServerCertificateCustomValidationCallback = static (_, _, _, _) => true,
#endif
        };
        return new HttpClient(handler, disposeHandler: true);
    };
});
```

### Resources

- [PR #4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153)
GitHub Security Advisory: GHSA-2cwq-pwfr-wcw3
Package: Nerdbank.MessagePack (NUGET)
Severity: HIGH (CVSS 7.5)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 1.1.62
Patched in: 1.1.62

Summary: Nerdbank.MessagePack: Attacker-controlled stackalloc in DateTime decoding causes process-terminating StackOverflowException

Details:
### Summary

Nerdbank.MessagePack contains an uncontrolled stack allocation vulnerability in DateTime decoding. A malicious MessagePack payload can declare an oversized timestamp extension length, causing the reader to allocate an attacker-controlled number of bytes on the stack. This can trigger a `StackOverflowException`, which is not catchable by user code and terminates the process.

### Impact

Applications are impacted if they deserialize MessagePack data from untrusted or attacker-controlled sources using Nerdbank.MessagePack and the target type contains a `DateTime` value.

A small malicious payload can cause process termination, resulting in a denial of service. This may affect services, APIs, workers, message consumers, or other long-running processes that deserialize untrusted MessagePack input.

The issue occurs because DateTime timestamp extension decoding derives `tokenSize` from the attacker-controlled extension length before validating that the timestamp length is one of the legal MessagePack timestamp sizes: 4, 8, or 12 bytes. When the buffer is incomplete, that unvalidated size is propagated to the streaming reader slow path, where it is used in a `stackalloc`.

### Patches

The 1.1.62 version contains the fix for this security vulnerability.

### Workarounds

If upgrading is not yet possible, avoid deserializing untrusted MessagePack payloads into type graphs that may contain `DateTime` fields or properties.

Input byte-size limits alone may not fully mitigate this issue, because the malicious payload can be small while declaring a very large extension length. Possible mitigations include:

- Pre-validating MessagePack extension headers before deserialization and rejecting timestamp extensions whose length is not 4, 8, or 12 bytes.
- Rejecting or filtering extension type `-1` timestamp values from untrusted input unless they are known to be valid.
- Running deserialization of untrusted payloads in an isolated process that can be safely restarted after termination.
- Restricting MessagePack deserialization to trusted producers until a patched version is available.

### Resources

- CWE-789: Uncontrolled Memory Allocation: https://cwe.mitre.org/data/definitions/789.html
- MessagePack timestamp extension specification: https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type
GitHub Security Advisory: GHSA-pggp-6c3x-2xmx
Package: Snappier (NUGET)
Severity: HIGH (CVSS 7.5)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: <= 1.3.0
Patched in: 1.3.1

Summary: Snappier has an infinite loop during SnappyStream decompression with malformed framed input

Details:
### Summary
`Snappier.SnappyStream` enters an uncatchable infinite loop when decompressing a malformed framed-format Snappy stream as small as 15 bytes.

### Details
The hang manifests as a userspace busy loop with SnappyStreamDecompressor.Decompress repeatedly calling Crc32CAlgorithm.Append. The exact non-terminating loop in or above Decompress has not been traced further.

### PoC
```csharp
using System.IO.Compression;
using Snappier;

byte[] data = { 0x00, 0x04, 0x00, 0x00, 0x64, 0x4e, 0x6c, 0x71, 0x79, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64 };
using var src = new MemoryStream(data);
using var snap = new SnappyStream(src, CompressionMode.Decompress);
using var dst = new MemoryStream();
snap.CopyTo(dst);   // never returns
```

### Impact
A caller using `SnappyStream` on attacker-controlled bytes can be made to spin forever and burn a thread until the process is killed. `try/catch` around the stream operation can't recover (no exception is thrown).
GitHub Security Advisory: GHSA-w2jh-77fq-7gp8
Package: OpenTelemetry.OpAmp.Client (NUGET)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 0.2.0-alpha.1
Patched in: 0.2.0-alpha.1

Summary: OpAMP client reads unbounded HTTP response bodies

Details:
### Summary

When receiving responses from the OpAMP server over HTTP, the OpAMP client allocates an unbounded buffer to read all bytes from the server, with no upper-bound on the number of bytes consumed.

This could cause memory exhaustion in the consuming application if the configured OpAMP server is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response. 

### Details

[#2926](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/2926) introduced the initial HTTP transport components which uses `ReadAsByteArrayAsync` to copy the `HttpResponseMessage.Content` into a byte array. This code path allows an unbounded read of the entire HTTP response message.

### Impact

If an application using the OpAMP client is configured to use an OpAMP server that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response, the application could have its memory exhausted and create a denial-of-service condition.

### Mitigation

The application's configured OpAMP server needs to behave maliciously. If the OpAMP server is a well-behaved implementation, response bodies should not be excessively large.

### Workarounds

None known.

### Remediation

[#4116](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116) updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB.

### Resources

- [#2926](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/2926)
- [#4116](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116)
- [CWE-789](https://cwe.mitre.org/data/definitions/789.html)
GitHub Security Advisory: GHSA-55m9-299j-53c7
Package: OpenTelemetry.Exporter.OneCollector (NUGET)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 1.15.0
Patched in: 1.15.1

Summary: OneCollector exporter reads unbounded HTTP response bodies

Details:
### Summary

When exporting telemetry to a back-end/collector over HTTP using the OpenTelemetry.Exporter.OneCollector exporter, if the request results in a unsuccessful request (i.e. HTTP 4xx or 5xx), the response is read into memory with no upper-bound on the number of bytes consumed.

This could cause memory exhaustion in the consuming application if the configured back-end/collector endpoint is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response.

### Details

The [`HttpJsonPostTransport`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Exporter.OneCollector/Internal/Transports/HttpJsonPostTransport.cs) class reads the response body when a non-200 HTTP status code is received when exporting telemetry to aid debugging by operators so that the error response is included in the logs emitted by the exporter.

An attacker who controls the configured endpoint, or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process.

### Impact

If an application using the OneCollector exporter is configured to use a back-end/collector endpoint that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response the application could have its memory exhausted and create a denial-of-service condition.

### Mitigation

The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs.

### Workarounds

Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the configured back-end/collector endpoint.

### Remediation

[#4117](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4117) updates the OneCollector exporter to limit the number of bytes read from the response body in an error condition to 4MiB.

### Resources

- [#4117](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4117)
GitHub Security Advisory: GHSA-vc24-j8c5-2vw4
Package: OpenTelemetry.Resources.Azure (NUGET)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 1.15.0-beta.1
Patched in: 1.15.1-beta.1

Summary: OpenTelemetry.Resources.Azure has an unbounded HTTP response body read

Details:
### Summary

`OpenTelemetry.Resources.Azure` reads unbounded HTTP response bodies from the Azure VM remote instance metadata service endpoint into memory.

This would allow an attacker-controlled endpoint or one acting as a Man-in-the-Middle (MitM) to cause excessive memory allocation and possible process termination (via Out of Memory (OOM)).

### Details

The [`AzureVmMetaDataRequestor`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.Azure/AzureVmMetaDataRequestor.cs) class makes HTTP requests to the relevant Azure VM instance metadata service (`http://169.254.169.254`) to obtain metadata about the running process and its infrastructure.

An attacker who controls the configured endpoint, or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process.

### Impact

Denial of Service (DoS). An attacker can destabilize or crash the application by forcing unbounded memory allocation through the Azure VM instance metadata HTTP response paths.

### Mitigating Factors

The application's reachable Azure VM metadata endpoint needs to behave maliciously or be subject to MitM. In normal usage response bodies should not be excessively large.

### Patches

Fixed in `OpenTelemetry.Resources.Azure` version `1.15.0-beta.2`.

The fix (#4121) introduce changes that introduce limits to `HttpClient` requests so that the response body is streamed rather than buffered entirely in memory. Responses greater than 4 MiB are ignored.

### Workarounds

- Disable the Azure VM resource detector.
- Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the Azure VM instance metadata endpoint.

### References

- [#4121](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4121)
GitHub Security Advisory: GHSA-88hf-wf7h-7w4m
Package: OpenTelemetry.Exporter.Zipkin (NUGET)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 1.15.2
Patched in: 1.15.3

Summary: OpenTelemetry's Zipkin remote endpoint cache could grow without bounds and increase memory pressure

Details:
### Summary

The Zipkin exporter remote endpoint cache accepted unbounded key growth derived from span attributes. In high-cardinality scenarios, this could increase process memory usage over time and degrade availability.

### Details

- Introduce a bounded, thread-safe LRU cache for remote endpoints.
- Enforce fixed maximum size to prevent unbounded growth.

### Impact

- A process using Zipkin export for client/producer spans could experience avoidable memory growth under sustained unique remote endpoint values.

### Resources

[#7081](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7081)
GitHub Security Advisory: GHSA-rrjr-v56m-ww88
Package: ParquetSharp (NUGET)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: >= 18.1.0, < 23.0.0.1
Patched in: 23.0.0.1

Summary: ParquetSharp: Possible Stack Overflow When Reading a ParquetFile with Large Decimal Type Width

Details:
`DecimalConverter.ReadDecimal` makes a stackalloc using what might be an attacker-supplied value. If an attacker declares a decimal column with some unreasonable width, this could lead to a stack overflow. In a service environment, this would potentially take down a service.

This affects applications using ParquetSharp to read untrusted Parquet files in a network service.
GitHub Security Advisory: GHSA-mr8r-92fq-pj8p
Package: OpenTelemetry.Exporter.OpenTelemetryProtocol (NUGET)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: >= 1.13.1, < 1.15.3
Patched in: 1.15.3

Summary: OpenTelemetry dotnet: Unbounded `grpc-status-details-bin` parsing in OTLP/gRPC retry handling

Details:
### Summary

When exporting telemetry over gRPC using the OpenTelemetry Protocol (OTLP), the exporter may parse a server-provided `grpc-status-details-bin` trailer during retry handling. Prior to the fix, a malformed trailer could encode an extremely large length-delimited protobuf field which was used directly for allocation, allowing excessive memory allocation and potential denial of service (DoS).

### Details

#5980 introduced a retry path that parses `grpc-status-details-bin` to extract gRPC retry delay information for retryable responses.

On that path:

- `OtlpGrpcExportClient` captures `grpc-status-details-bin` from retryable status responses (`ResourceExhausted` / `Unavailable`).
- `OtlpRetry` invokes `GrpcStatusDeserializer.TryGetGrpcRetryDelay` using this untrusted trailer value.
- `GrpcStatusDeserializer.DecodeBytes` decoded a protobuf varint length and allocated `new byte[length]` without validating the bounds against the remaining payload size.

A malicious or compromised collector (or a MitM in weakly-protected deployments) could return a crafted `grpc-status-details-bin` payload that forces oversized allocation and memory exhaustion in the instrumented process.

### Impact

If an OTLP/gRPC endpoint is attacker-controlled (or traffic is intercepted), a crafted retryable response can trigger large allocations during trailer parsing, which may exhaust memory and cause process instability/crash (availability impact / DoS).

### Mitigation

The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs.

### Workarounds

None known.

### Remediation

[#7064](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7064) updates `GrpcStatusDeserializer` to validate decoded length-delimited field sizes before allocation by ensuring the requested length is sane and does not exceed the remaining payload.

This causes malformed or truncated `grpc-status-details-bin` payloads to fail safely instead of attempting unbounded allocation.