Deserialization of untrusted data in Apache Fory PyFory

CVE-2026-48207 is a deserialization-policy bypass in Apache Fory's Python package pyfory. The vulnerable path is ReduceSerializer during reduce-state restoration and global-name resolution, where documented DeserializationPolicy hooks are not consistently enforced. The vendor advisory says affected versions are pyfory 0.13.0 through 0.17.0, with the fix in 1.0.0; NVD models the range as 0.13.0 up to but excluding 1.0.0.

The raw 9.8 score overstates enterprise urgency because exploitation is not just "network reachable" in the real world. The attacker needs a target application that both accepts attacker-controlled serialized bytes and uses Python-native mode with xlang=False, has strict=False, and relies on DeserializationPolicy as the safety boundary. That is a real RCE-style failure mode when present, but it is a *conditional library exposure*, not a universally exposed service bug.

Why this verdict

• Downgrade from 9.8 for attacker position reality: the attacker does not win by finding a host with pyfory; they need a live application path that deserializes attacker-controlled bytes. That is a major narrowing from CVSS's abstract network assumption.
• Further downgrade for configuration dependence: the vulnerable scenario requires Python-native mode with strict=False and dependence on DeserializationPolicy for safety. Each prerequisite compounds downward pressure because many installs will not line up that way.
• Hold at HIGH because impact is still serious when the chain exists: if your app does expose that deserialization boundary, exploitation can cross directly into unsafe object reconstruction and probable RCE-like outcomes inside the service account context.

Why not higher?

I would reserve CRITICAL for bugs with a large, easy-to-reach exposed population or active exploitation evidence. Here, the exploit chain is gated by application design and unsafe configuration choices, and there is no KEV listing or strong real-world exploitation signal yet.

Why not lower?

This is not a harmless theoretical bug. Once an exposed app actually feeds hostile bytes into vulnerable pyfory with the unsafe mode combination, the path to process compromise is short and the security boundary being bypassed is the very control defenders may have been relying on.

1. Force strict=True where possible — Make registration-based deserialization the default safety control instead of trusting policy hooks on vulnerable paths. For confirmed affected apps, deploy this change within 30 days because that is the compensating-control deadline for a HIGH finding.
2. Block untrusted PyFory inputs at the edge — If a service accepts serialized blobs from clients, brokers, or partner systems, gate that path with authentication, allowlisted producers, and protocol-level rejection until the dependency is upgraded. Put those blocks in place within 30 days for any internet-facing or partner-exposed flow.
3. Disable Python-native mode for hostile inputs — Where the workflow permits it, move externally influenced traffic away from xlang=False Python-native object reconstruction and into safer typed formats or cross-language modes with tighter schemas. Treat this as a containment change to complete within 30 days on exposed applications.
4. Inventory imports and code paths — Use SBOM/SCA plus code search to separate simple package presence from *actual deserialization use on untrusted data*. Do this immediately so you do not waste time emergency-patching dormant developer tools while missing the one real RPC service.
5. Constrain the runtime — Run vulnerable Python services with low-privilege identities, no shell utilities they do not need, and tight egress controls, so a successful deserialization bypass has less room to turn into full environment compromise. Apply these hardening changes within 30 days on any confirmed exposed workload.

Run this on the target host that has the Python environment or container image you want to assess. Invoke it as python3 check_cve_2026_48207.py /path/to/app to check the installed pyfory version and optionally scan source files for risky Fory(... strict=False ...) usage; no admin rights are needed unless the code path you want to scan is unreadable to your current account.

#!/usr/bin/env python3
# CVE-2026-48207 verifier for Apache Fory PyFory
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import re
import sys
from pathlib import Path

try:
    from importlib.metadata import version, PackageNotFoundError
except Exception:
    print('UNKNOWN - importlib.metadata unavailable')
    sys.exit(2)

TARGET = Path(sys.argv[1]).resolve() if len(sys.argv) > 1 else None
PKG = 'pyfory'

def parse_ver(v):
    m = re.match(r'^(\d+)\.(\d+)\.(\d+)', str(v))
    if not m:
        return None
    return tuple(int(x) for x in m.groups())

def lt(a, b):
    return a < b

def scan_repo(root):
    findings = []
    if root is None or not root.exists():
        return findings
    exts = {'.py', '.pyw'}
    patterns = [
        re.compile(r'Fory\s*\([^\)]*strict\s*=\s*False', re.S),
        re.compile(r'Fory\s*\([^\)]*xlang\s*=\s*False', re.S),
        re.compile(r'DeserializationPolicy'),
        re.compile(r'pyfory\.(loads|deserialize)\s*\('),
        re.compile(r'\b(loads|deserialize)\s*\('),
    ]
    for p in root.rglob('*'):
        if not p.is_file() or p.suffix.lower() not in exts:
            continue
        try:
            text = p.read_text(encoding='utf-8', errors='ignore')
        except Exception:
            continue
        hits = []
        for pat in patterns:
            if pat.search(text):
                hits.append(pat.pattern)
        if hits:
            findings.append((str(p), hits))
    return findings

try:
    installed = version(PKG)
except PackageNotFoundError:
    print('UNKNOWN - pyfory not installed in this Python environment')
    sys.exit(2)
except Exception as e:
    print(f'UNKNOWN - failed to query package version: {e}')
    sys.exit(2)

installed_t = parse_ver(installed)
fixed_t = (1, 0, 0)

if installed_t is None:
    print(f'UNKNOWN - could not parse pyfory version: {installed}')
    sys.exit(2)

repo_findings = scan_repo(TARGET)
strict_false = False
python_native = False
policy_used = False
for _, hits in repo_findings:
    for h in hits:
        if 'strict\s*=\s*False' in h:
            strict_false = True
        if 'xlang\s*=\s*False' in h:
            python_native = True
        if 'DeserializationPolicy' in h:
            policy_used = True

if lt(installed_t, fixed_t):
    if strict_false and (python_native or policy_used):
        print(f'VULNERABLE - pyfory {installed} < 1.0.0 and code scan found risky usage (strict=False with Python-native/policy indicators)')
        if TARGET:
            for path, hits in repo_findings[:20]:
                print(f'  hit: {path} :: {", ".join(hits)}')
        sys.exit(1)
    else:
        print(f'UNKNOWN - pyfory {installed} is in the affected version range, but risky runtime usage was not confirmed from static scan alone')
        if TARGET and repo_findings:
            for path, hits in repo_findings[:20]:
                print(f'  context: {path} :: {", ".join(hits)}')
        sys.exit(2)
else:
    print(f'PATCHED - pyfory {installed} >= 1.0.0')
    sys.exit(0)

Sources

1. Apache Fory security advisory
2. NVD CVE entry
3. Openwall oss-security disclosure
4. CVE.org record
5. PyPI pyfory package page
6. Apache Fory GitHub releases
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS documentation