On October 1, 2026, I reported an out-of-bounds write vulnerability in the ASN1SCC compiler maintained by the European Space Agency. The compiler generates C decoders from ASN.1 schemas that use ACN (ASN.1 Control Notation) encoding instructions. When it generated decoders for OCTET STRING and BIT STRING fields carrying an ACN size determinant, it emitted code that read the size from the wire and passed it to a memcpy without checking it against the field's declared SIZE constraint.
What I found
ASN1SCC translates an ASN.1 schema like this into C source code:
My-Msg ::= SEQUENCE {
payload OCTET STRING (SIZE (1..10))
}
-- ACN encoding: payload length is a 32-bit determinant on the wire
My-Msg [] {
payload [size payload.count,
encoding pos-int, size 32]
}
The SIZE constraint says the payload is at most 10 bytes. The ACN encoding says the length field on the wire is 32 bits wide, meaning it can represent values up to 4,294,967,295. The compiler should emit a guard that rejects any wire length above 10 before copying.
Instead, the generated decoder computed the maximum from getSizeDeterminantWireMax, which returns the largest value the wire format can carry, not the largest value the schema permits. The resulting C code looked like this:
Acn_Dec_Length(pBitStrm, &My_Msg_len, 32);
/* guard should check My_Msg_len <= 10 */
/* no guard was emitted */
memcpy(pVal->payload.arr, ..., (size_t)My_Msg_len);
An attacker who controlled the encoded message could set the 32-bit length to any value up to 223 (the maximum the wire format permits in the determinant encoding), and the memcpy would write that many bytes into a 10-byte stack-allocated array. Both the length and the content of the overwrite were attacker-controlled.
Root cause
The code generation path for ACN size determinants used getSizeDeterminantWireMax where it should have used the schema-declared uperRange. The former returns the maximum the wire encoding can physically carry. The latter returns the maximum the schema allows. The difference between those two values is the overflow window.
The same pattern appeared in both 32-bit and 4-bit determinant widths, producing overflows of different magnitudes depending on the wire format and the SIZE constraint.
Impact
Any system decoding ACN-encoded messages from an untrusted source with ASN1SCC-generated C code was exposed to a stack buffer overflow. The attacker controls the overflow length and content. Exploitation depends on the target architecture, compiler, and stack layout, but the vulnerability class is well understood: stack buffer overflows have led to denial of service, data corruption, and code execution in comparable systems.
ASN1SCC is used in the space and embedded systems sectors, where the generated decoders may process telemetry or command messages from external sources.
The fix
ESA patched the compiler in version 4.9.11.0. The emitted C now derives the maximum from the schema's SIZE constraint rather than the wire maximum, and the guard rejects any determinant that exceeds it before the memcpy executes.
Verification
I built the patched compiler, regenerated the C decoders from the original test schema, and confirmed three things. First, the emitted code now contains a bounds check (ret=(My_Msg_len<=10)) before the copy. Second, under AddressSanitizer, a message with an oversized determinant is rejected cleanly. Third, as a control, removing the new guard from the patched output restores the original overflow under ASAN, confirming the guard is the operative fix.
Timeline
01 Oct 2026 Submitted through ESA VDP on Intigriti, coordinated with ESACERT
09 Oct 2026 ESA released asn1scc 4.9.11.0 with the fix, retest confirmed
12 Oct 2026 GHSA-g49g-f3f6-g578 published, CVSS 8.2 High
Affected versions: 4.7.0.2 through 4.9.10.0. CWE-787 (Out-of-bounds Write), CWE-1284 (Improper Validation of Specified Quantity in Input).
A compiler that trusts the wire to stay within bounds has moved the security boundary from the generated code to the network, which is the one place the developer assumed they did not need to look.