Threat Intelligence Database

ThreatFox IOCs for 2026-06-10

A security vulnerability (CVE-2026-10118) in the Poppler PDF rendering library used by Red Hat Enterprise Linux 10 has been identified. The flaw is an integer overflow in the Poppler SplashOutputDev::tilingPatternFill function, which leads to a heap buffer overflow due to unchecked dimension multiplication. Red Hat has issued an important security advisory and released updated packages to address this issue. The vulnerability affects multiple architectures and variants of Red Hat Enterprise Linux 10 and CodeReady Linux Builder 10. Users are advised to apply the provided updates to mitigate the risk.

A security vulnerability (CVE-2026-49975) affecting the mod_http2 Apache httpd module in Red Hat Enterprise Linux 9 allows remote denial of service via a compression bomb and Slowloris-style attack. The vulnerability impacts HTTP/2 protocol handling on httpd 2. 4 servers. Red Hat has released an important security update to address this issue in mod_http2 version 2. 0. 26-6. el9_8. 1. The update mitigates the risk of remote denial of service attacks exploiting this flaw.

NET 8. 0 on Red Hat Enterprise Linux 10 has two security vulnerabilities: a local file tampering issue via link following (CVE-2026-45491) and an ASP. NET Core denial of service caused by uncontrolled resource consumption (CVE-2026-45591). Updated . NET SDK 8. 0. 128 and Runtime 8. 0. 28 packages addressing these issues are available. The vulnerabilities affect multiple architectures and variants of Red Hat Enterprise Linux 10 and CodeReady Linux Builder 10.

Red Hat OpenShift Container Platform 4. 19. 33 includes a security update addressing multiple vulnerabilities identified by CVE-2026-1784 and related CVEs. This update provides bug fixes and enhancements for the Kubernetes-based cloud computing platform designed for on-premise or private cloud deployments. The advisory covers updated container images and references RPM package updates in a related advisory. Users of OpenShift Container Platform 4. 19 are advised to upgrade to this release to apply the security fixes.

Dulwich is a pure-Python implementation of the Git file formats and protocols. Starting in version 0.23.2 and prior to version 1.2.5, `dulwich.porcelain.submodule_update`, and by extension `porcelain.clone(..., recurse_submodules=True)`, materializes attacker-controlled submodule paths from a crafted upstream repository without path validation. A malicious `.gitmodules` plus a matching tree gitlink whose `path` is `.git/hooks` (or any other directory inside the parent repository's `.git` directory) causes the attacker's submodule tree contents to be written directly into the victim's `.git/hooks/` directory, preserving executable mode bits. The dropped executables are then run by any subsequent `git` or `dulwich` command that invokes the matching hook, resulting in arbitrary code execution. This is the dulwich equivalent of the upstream Git fixes for CVE-2024-32002 / CVE-2024-32004, which were never propagated into dulwich's separately implemented submodule porcelain. Version 1.2.5 patches the issue.

Dulwich is a pure-Python implementation of the Git file formats and protocols. Starting in version 0.1.0 and prior to version 1.2.5, a client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received. Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler - are impacted. The issue is patched in 1.2.5. add_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size. Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment. On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches and/or run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.

Dulwich is a pure-Python implementation of the Git file formats and protocols. Starting in version 0.24.0 and prior to version 1.2.5, dulwich.porcelain.format_patch(outdir=...) derives each patch filename from the commit's subject line. Prior to this fix, get_summary only replaced spaces with dashes - path separators (/, \), parent-directory components (..), and other filename-hostile characters (e.g. :) were preserved verbatim and passed straight into os.path.join(outdir, f"{i:04d}-{summary}.patch"). A malicious commit subject could therefore direct the generated patch file outside the requested outdir. This is fixed in Dulwich 1.2.5. Users should upgrade to 1.2.5 or later. dulwich.patch.get_summary now mirrors git's format_sanitized_subject: only `[A-Za-z0-9._]` are kept, runs of other characters collapse to a single -, consecutive . collapse to a single ., trailing ./- are stripped, and the result is length-limited. This makes the returned string safe to embed as a filename component, so format_patch can no longer be steered out of outdir via the commit subject. Until upgrading, callers that pass untrusted commits to porcelain.format_patch can use stdout=True and write the patch to a destination they control, rather than letting format_patch choose the filename; validate the chosen path before opening - e.g. compare os.path.realpath(returned_path) against os.path.realpath(outdir) and reject any patch whose resolved path is not inside outdir; and/or pre-screen commits and refuse to format any whose subject's first line contains /, \, .., or other characters that are not safe on the target filesystem.

Boxlite is a sandbox service that allows users to create lightweight virtual machines (Boxes) and launch OCI containers within them to run untrusted code. In versions 0.8.2 and prior, Boxlite allows users to configure a timeout for services running inside the virtual machine. When the timeout is triggered, Boxlite sends a signal to kill the process. However, instead of using the uncatchable SIGKILL signal, Boxlite uses the catchable SIGALRM signal. Malicious code running inside the sandbox can exploit this vulnerability to continue running after the timeout is triggered, leading to resource exhaustion within the virtual machine and affecting the availability of the Boxlite service. This issue has been patched via commit 28159fc.

Boxlite is a sandbox service that allows users to create lightweight virtual machines (Boxes) and launch OCI containers within them to run untrusted code. Prior to version 0.9.0, Boxlite allows users to specify the OCI image used by containers in the sandbox. However, when processing tar entries in OCI images, Boxlite does not account for the possibility that entries may be symlinks pointing to absolute paths. An attacker can craft a malicious OCI image and distribute it on image hosting platforms such as DockerHub, tricking users into using it. Once a user loads the malicious image, the attacker can write arbitrary content to any path on the host, which can further lead to remote code execution on the host. This issue has been patched in version 0.9.0.