CVE-2026-41586 is a critical unsafe deserialization flaw (CVSS 9.8) in the deprecated fabric-sdk-java client library for Hyperledger Fabric. No patch exists. Do not pass untrusted bytes to its channel deserialization methods, and plan a move to the Fabric Gateway client.
What's affected
The GitHub advisory covers the Maven package org.hyperledger.fabric-sdk-java:fabric-sdk-java, versions 1.0.0 through 2.2.x, with no patched version. The record says there were no public patches at the time of publication. The advisory states the SDK is deprecated as of Fabric v2.5 and replaced by the fabric-gateway client, and that the code lives in a separate repository.
The flaw is in the client SDK, not in the Fabric peers. The advisory says channel data is not transmitted from peers, so this is a client side deserialization surface.
How to check if you're exposed
Find the dependency in your Java builds:
mvn dependency:tree | grep fabric-sdk-java
gradle dependencies | grep fabric-sdk-java
Then search your code for calls to deSerializeChannel and any code that reads serialized Channel objects from files, caches or messages. The risk is highest where those bytes come from a source outside the client's direct control. A dependency scan can list the library in each repository, and reachability analysis shows whether a deserialization call exists in your code.
What to do now
- Inventory every application that depends on fabric-sdk-java.
- Stop deserializing Channel bytes from untrusted or shared locations. Rebuild channel objects from trusted configuration instead.
- Plan the migration to the Fabric Gateway client, since the old SDK is deprecated and unpatched.
- Apply a JVM wide deserialization filter, for example through the
jdk.serialFiltersetting, to limit which classes can be deserialized. - Lock down file system access to wherever serialized channel data is stored.
Why it matters
The record lists CWE-502, deserialization of untrusted data. The advisory says Channel.java calls ObjectInputStream.readObject() on byte arrays without an ObjectInputFilter. Java deserialization can instantiate classes the code never meant to use, and if a suitable chain of classes exists on the classpath, that can lead to code execution.
The 9.8 score assumes an attacker can supply the bytes. The advisory is more careful: the attacker must reach the client with crafted data, for example through a writable file or an application that accepts such bytes. That makes this a case where architecture decides your real risk. The record does not flag this CVE as known exploited.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
With no patch, is there anything that really helps?
Yes. Remove untrusted input paths to the deserialization call, add a JVM deserialization filter, and migrate off the deprecated SDK.
Sources
Last reviewed: 19 October 2026.
