Mardi 28 juillet 2026

dompdf · Dompdf project dompdf

Dompdf is an HTML to PDF converter for PHP. Versions 3.15 and prior accept a BMP image and generates a PDF-compatible PNG based only on its declared header dimensions and never bounds width × height before the image is converted through GD. A 58-byte BMP whose header declares e.g. 6000×6000 is accepted and later drives imagecreatetruecolor($width, $height) (and PHP's native BMP decoder) to allocate the full pixel canvas. A payload can fit in a single HTTP request: the BMP can be inlined as a data:image/bmp;base64,… URI inside attacker-controlled HTML, so no upload, no remote fetch, and no chroot-reachable file is required. I measured a 169-byte request driving a dompdf render to ~412 MB peak RSS and ~4.8 s of CPU/wall time, versus ~34 MB for an identically-sized benign request — roughly a 12× memory amplification per request, repeatable and unauthenticated. This issue has been fixed in version 3.16.

gopacket · Gopacket gopacket

gopacket provides packet processing capabilities for Go. In version 1.6.0 and earlier, the Diameter AVP decoder computes an AVP data length by subtracting a fixed header size from an attacker-controlled AVP Length field, so a vendor-flagged AVP whose Length is smaller than the 12-byte header underflows the unsigned 32-bit value and drives an unbounded allocation of roughly 4 GiB, and two such messages in succession OOM-kill a collector, causing an unauthenticated remote denial of service. This issue is fixed in version 1.6.1.

gopacket · Gopacket gopacket

gopacket provides packet processing capabilities for Go. In version 1.6.0 and earlier, the sFlow ExtendedGatewayFlow decoder in layers/sflow.go reads an attacker-controlled 32-bit community count and AS path member count and sizes a slice allocation from those counts without bounding them against the bytes remaining in the datagram, so a 104-byte UDP datagram can drive an allocation of up to 16 GiB and cause an unauthenticated remote denial of service. This issue is fixed in version 1.6.1.

ninenines cowlib

Allocation of resources without limits vulnerability in ninenines cowlib allows an unauthenticated remote HTTP/2 or HTTP/3 peer to exhaust memory on the vulnerable server (or client) and cause a denial of service. The HPACK and QPACK prefixed-integer decoder cow_hpack_common:dec_big_int/3 in src/cow_hpack_common.hrl (invoked from cow_hpack:decode/2 in src/cow_hpack.erl and from cow_qpack:decode_field_section/3 in src/cow_qpack.erl) reads continuation octets until it sees one whose high bit is clear, evaluating Int + (Value bsl M) at each step with the shift M growing by seven per octet. No limit is enforced on the number of continuation octets, on the resulting bit width, or on the value; the decoder consumes whatever encoded length the peer supplies. Because Erlang integers are immutable, each intermediate Value bsl M and each accumulator update allocates a fresh bignum whose digit width grows linearly with the number of octets processed so far. Summed across the whole decode, the transient bignum digit materialization is on the order of the square of the encoded length. A single maximal HPACK indexed representation carried inside one HTTP/2 HEADERS plus one CONTINUATION frame at Cowboy's default max_frame_size_received can force hundreds of megabytes of transient allocation and garbage-collection churn before the resulting header-table index is rejected as invalid. Repeated or concurrent connections multiply the pressure and can drive the Erlang VM to memory exhaustion. Cowlib is the HTTP parser used by Cowboy, RabbitMQ's management plugin, and other Erlang and Elixir HTTP/2 and HTTP/3 servers and clients, so any exposed endpoint that accepts HPACK or QPACK from an untrusted peer is reachable. This issue affects cowlib: from 2.0.0 before 2.19.0.