Apr 25, 2026·5 min read·17 visits
A stack exhaustion vulnerability in ParquetSharp allows an attacker to crash the host application by providing a crafted Parquet file with excessively large decimal column widths, leading to an uncatchable StackOverflowException.
ParquetSharp versions between 18.1.0 and 23.0.0.0 are vulnerable to a stack exhaustion Denial of Service (DoS) flaw. The vulnerability resides in the DecimalConverter class, where uncontrolled metadata values dictate unbounded stack allocation size.
ParquetSharp is a .NET library that provides a high-performance wrapper around the Apache Parquet C++ library. Applications use ParquetSharp to read and write Parquet files, a columnar storage format frequently employed in data engineering and analytics workloads. The vulnerability exists within the parsing mechanism for decimal data types stored as Fixed-Length Byte Arrays (FLBA).
When processing Parquet files, the library extracts metadata defining the physical structure of the columns, including the length of byte arrays used for decimal values. The DecimalConverter component utilizes this metadata to allocate memory during read operations.
The library fails to enforce an upper bound on the Length property derived from the untrusted file metadata. This architectural oversight classifies the defect as CWE-121, representing a stack-based buffer overflow specifically manifesting as stack exhaustion.
The technical root cause originates in the DecimalConverter.ReadDecimal and DecimalConverter.WriteDecimal methods. In .NET, the stackalloc keyword allows developers to allocate memory directly on the thread's execution stack rather than the managed heap. This technique bypasses garbage collection overhead and provides significant performance benefits for small, temporary buffers.
The vulnerability occurs because the stackalloc instruction receives its size parameter directly from the byteArray.Length property. This property represents the primitiveLength defined in the Parquet file's metadata schema.
Because the Parquet format allows files to self-describe their schema, an attacker maintains complete control over the primitiveLength value. When the application attempts to allocate an excessively large buffer, such as 10 megabytes, the allocation exceeds the thread's maximum stack size limit, which typically defaults to 1 megabyte in standard .NET environments.
The vulnerable implementation relies entirely on stack allocation regardless of the requested buffer size. The DecimalConverter method receives a ByteArray object and immediately initiates a stackalloc operation.
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static unsafe decimal ReadDecimal(ByteArray byteArray, decimal multiplier)
{
if (byteArray.Length == 0) return new decimal(0);
// Unbounded stack allocation based on untrusted length
var tmp = stackalloc byte[byteArray.Length];
for (var byteIdx = 0; byteIdx < byteArray.Length; ++byteIdx)
{
tmp[byteArray.Length - byteIdx - 1] = *((byte*) byteArray.Pointer + byteIdx);
}
// ...
}The patch resolves this by introducing a maximum threshold for stack allocations, defined as MaxStackAllocSize with a value of 1024 bytes. If the requested typeLength is less than or equal to this constant, the code maintains the high-performance stackalloc path.
If the requested length exceeds 1024 bytes, the patched code falls back to renting a buffer from the managed heap using ArrayPool<byte>.Shared.Rent. A finally block guarantees the buffer returns to the pool after the read operation completes, preventing memory leaks while safely handling arbitrarily large metadata values.
Exploitation requires the attacker to deliver a maliciously crafted Parquet file to a vulnerable application endpoint. The attacker structures the file with a decimal-type column utilizing the FIXED_LEN_BYTE_ARRAY physical type.
The attacker then modifies the file metadata to specify a disproportionately large primitiveLength for the decimal column. The specific value only needs to exceed the target environment's thread stack limit to guarantee a crash.
When the target application instantiates a ParquetFileReader and attempts to read the compromised column, the execution flow reaches the DecimalConverter.ReadDecimal method. The following proof-of-concept snippet demonstrates the precise API call sequence that triggers the condition.
using var decimalType = LogicalType.Decimal(precision: 9, scale: 4);
using var colNode = new PrimitiveNode("value", Repetition.Required, decimalType, PhysicalType.FixedLenByteArray, primitiveLength: 10_000_000);
using var schema = new GroupNode("schema", Repetition.Required, new Node[] { colNode });
// The groupReader parses the modified schema and passes the large length
using var columnReader = groupReader.Column(0).LogicalReader<decimal>();
// ReadAll triggers the unbounded stackalloc
var values = columnReader.ReadAll((int) groupReader.MetaData.NumRows);The vulnerability consistently results in a Denial of Service condition against the host application. In the .NET runtime, a StackOverflowException fundamentally differs from standard exceptions.
The runtime immediately terminates the executing process when a stack overflow occurs. Developers cannot intercept or handle a StackOverflowException using standard try-catch blocks, making the crash unavoidable once the vulnerable execution path triggers.
This termination affects all concurrent operations running within the application process. If the vulnerable ParquetSharp implementation operates within a web service or data ingestion pipeline, a single malicious file payload will cause complete service disruption, requiring a process restart to restore availability.
Organizations must update the ParquetSharp NuGet package to version 23.0.0.1 to eliminate the vulnerability. This version incorporates the ArrayPool fallback mechanism, which neutralizes the stack exhaustion vector while preserving parsing performance for standard files.
If immediate patching is unfeasible, developers should implement pre-processing validation on incoming Parquet files. This validation layer must inspect the logical schema and reject files containing decimal columns with a primitiveLength exceeding expected operational limits.
Security teams should also review dependency trees to identify indirect usages of ParquetSharp. Static analysis tools can detect invocations of ParquetSharp.DecimalConverter.ReadDecimal or ParquetSharp.ColumnReader<decimal>.ReadAll() to prioritize remediation efforts across large codebases.
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H| Product | Affected Versions | Fixed Version |
|---|---|---|
ParquetSharp G-Research | >= 18.1.0, < 23.0.0.1 | 23.0.0.1 |
| Attribute | Detail |
|---|---|
| Vulnerability Type | Stack Exhaustion (Denial of Service) |
| CWE ID | CWE-121 |
| Attack Vector | Local / Remote (via untrusted file) |
| CVSS Score | 5.3 (Moderate) |
| Exploit Status | Proof of Concept Available |
| KEV Status | Not Listed |
The application allocates memory on the stack based on an untrusted size parameter, leading to stack exhaustion and process crash.
A critical logical security flaw exists in Auth.js (formerly NextAuth.js) where signed anti-CSRF check cookies (state, nonce, and PKCE code_verifier) are not bound to the specific Identity Provider that initiated the authorization flow. In multi-provider environments, this allows an attacker to replay valid, cryptographically signed cookies minted during a flow with one provider against a callback handling a different provider. This vulnerability can lead to session hijacking, identity theft, or unauthorized account linking.
A security vulnerability in the email normalization logic of NextAuth.js and Auth.js allows remote attackers to bypass email validation constraints and achieve Account Takeover (ATO) through Unicode homoglyph smuggling. Under standard conditions, Unicode compatibility characters represent visually similar symbols that are normalized downstream to ASCII equivalents, facilitating structural validation bypasses. This issue specifically affects passwordless email authentication flows.
Auth.js (formerly NextAuth.js) contains a denial of service vulnerability due to an uncaught URIError in the getToken() token parser when processing malformed percent-encoded sequences in bearer tokens. Additionally, the library was vulnerable to session state confusion and replay attacks because OAuth check cookies (state, nonce, and PKCE) were not properly bound to specific providers, permitting cross-provider token reuse.
CVE-2026-53467 is a heap information disclosure vulnerability in the Multiple-image Network Graphics (MNG) decoder of ImageMagick. The vulnerability arises from a failure to zero-initialize newly allocated pixel cache memory buffers. A remote attacker can exploit this by submitting a crafted sparse MNG image file to trigger uninitialized memory preservation. The resulting output contains residual heap bytes, potentially leaking sensitive process memory or assisting in ASLR bypass.
An untrusted deserialization vulnerability exists in the c3p0 JDBC connection pooling library before version 0.14.0. Standard JDBC getter methods conform to the JavaBean property getter pattern, allowing introspection libraries like Apache Commons BeanUtils to evaluate connection properties dynamically during deserialization, leading to arbitrary code execution when chained with a vulnerable database driver or JNDI sink.
A heap-based buffer overflow vulnerability exists in the native C extension of the Ruby json gem (versions 2.9.0 through 2.19.8) during IO-based streaming serialization. An incorrect buffer size calculation can lead to memory corruption and process termination when processing large strings.