What is the CVSS score of CVE-2026-50076?

CVE-2026-50076 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.1%.

Which versions of Apache Fory are affected by CVE-2026-50076?

Apache Fory fory-core Java SDK versions before 1.1.0 contain a critical remote code execution vulnerability exploitable without authentication.. A patch is available.

How to fix or mitigate CVE-2026-50076?

Within 24 hours: Conduct asset discovery to identify all Java applications using Apache Fory fory-core; categorize by environment and criticality. Within 7 days: Deploy Apache Fory fory-core version 1.1.0 or later to all affected systems, prioritizing production workloads. Within 30 days: Complete patching across development and test environments, validate post-deployment stability, and review application logs for pre-patch exploitation indicators.

Apache Fory CVE-2026-50076

EUVD-2026-34300 CRITICAL

Deserialization of Untrusted Data (CWE-502)

2026-06-04

GHSA-8f39-v287-78jf

Apache Deserialization Java Fory

9.1

CVSS 3.1 · Vendor

Severity by source

Vendor (CNA) PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Primary rating from Vendor (CNA) · only source for this CVE.

CVSS VectorVendor

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Updated

Jun 04, 2026 - 18:29 vuln.today

v3 (cvss_changed)

Analysis Updated

Jun 04, 2026 - 18:28 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jun 04, 2026 - 18:22 vuln.today

cvss_changed

CVSS changed

Jun 04, 2026 - 18:22 NVD

9.1 (CRITICAL)

Patch available

Jun 04, 2026 - 18:01 EUVD

Analysis Generated

Jun 04, 2026 - 16:20 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

27 maven packages depend on org.apache.fory:fory-core (14 direct, 13 indirect)

Ecosystem-wide dependent count for version 1.1.0.

Description PRE-NVD

Disclosed via oss-security. NVD scoring and full description are pending.

AnalysisAI

Unsafe deserialization in Apache Fory fory-core Java SDK versions prior to 1.1.0 allows remote attackers to bypass the framework's class registration, TypeChecker, and DisallowedList security controls on Java/JVM platforms. By crafting malicious Fory-serialized payloads that exercise the replace-resolve path, an attacker can invoke arbitrary readResolve/readExternal hooks on any class present on the classpath, enabling gadget-chain abuse without authentication. No public exploit identified at time of analysis, but the CVSS 9.1 score and CWE-502 classification reflect the high impact typical of Java deserialization sinks.

Technical ContextAI

Apache Fory (formerly Apache Fury) is a high-performance multi-language serialization framework that ships a Java SDK (fory-core) for the JVM. Like Java's native ObjectInputStream, Fory supports the JDK's serialization callbacks readResolve and readExternal, which can run code during object materialization. To mitigate the well-known dangers of CWE-502 (Deserialization of Untrusted Data), Fory implements three layered defenses: an allowlist of registered classes, a TypeChecker that validates type metadata in the stream, and a DisallowedList that blocks known gadget classes. The vulnerability lies in the replace-resolve code path, where these checks are not consistently enforced before the JVM-level resolve hooks fire, allowing an attacker who controls the serialized bytes to reach arbitrary classpath classes and trigger their resolve/external hooks - the same primitive that powers ysoserial-style RCE gadget chains.

RemediationAI

The primary remediation is to upgrade fory-core to vendor-released patch version 1.1.0 or later, which the Apache Fory project has identified as the fix for this issue (see https://fory.apache.org/security and the oss-security disclosure at https://seclists.org/oss-sec/2026/q2/808). For deployments that cannot upgrade immediately, compensating controls include restricting Fory deserialization endpoints so they only accept payloads from authenticated, trusted producers (e.g., via mTLS or signed payloads), pruning the application classpath to remove known gadget libraries such as commons-collections, Spring AOP, and ROME where feasible, and inserting a network-layer filter that rejects unexpected Fory magic bytes on externally exposed channels. Each control has trade-offs: signing payloads requires producer-side changes and key management, classpath pruning can break unrelated features, and protocol filtering only blocks externally posted payloads, not malicious data already inside the queue or database. Do not rely on the existing TypeChecker or DisallowedList as workarounds, since those are the controls the bug bypasses.