Cross-user attribute leak in JSON:API and HAL item normalizers due to missing isCacheKeySafe gate

CVE-2026-49858 is a cross-request cache-key bug in API Platform's JSON:API and HAL item normalizers. Affected ranges are api-platform/core >=2.6.0,<4.1.29 || >=4.2.0,<4.2.25 || >=4.3.0,<4.3.8, plus the split packages api-platform/json-api and api-platform/hal in their corresponding vulnerable ranges. If your app uses #[ApiProperty(security: ...)] rules that vary by requester, the normalizer can reuse a component layout calculated for a more privileged user and expose attribute/relationship structure to a less privileged or even anonymous requester.

The vendor's MEDIUM 5.9 is defensible in theory but too generous for fleet prioritization. Real exploitation needs four things to line up at once: JSON:API or HAL output, user-dependent property security, a request ordering race where a privileged request warms the cache first, and a long-lived PHP worker model that preserves in-memory state across requests. That is not the default Symfony/PHP-FPM reality in most enterprises, so this should be treated as a narrow information-disclosure bug, not a front-of-queue internet fire.

Why this verdict

• Downgrade 1 — requires non-default runtime behavior: classic php-fpm is explicitly called out as much harder to exploit in practice, so a huge chunk of ordinary PHP estates fall out immediately.
• Downgrade 2 — requires app-specific field-level security: the vulnerable path matters only when #[ApiProperty(security: ...)] decisions vary by requester. If your team never built per-property auth rules, there is no practical attack.
• Downgrade 3 — narrow blast radius: the leak is about response structure in JSON:API/HAL, not arbitrary object values, code execution, integrity loss, or service interruption.
• Downgrade 4 — attacker position is weaker than it looks on paper: PR:N is technically true because an anonymous user can be the recipient, but the exploit usually *implies prior privileged traffic on the same worker*. That is a hidden dependency, and it matters.

Why not higher?

There is no KEV listing, no active exploitation signal, and no public weaponized PoC located. More importantly, the exploit chain compounds friction at every stage: specific serializer formats, specific auth annotations, privileged cache priming, and same-worker reuse in a persistent runtime.

Why not lower?

It is still a genuine cross-user authorization leak, not a theoretical code smell. In deployments using persistent PHP workers and user-dependent property security, an unauthenticated or low-privilege caller can receive data structure they were not meant to see, and that deserves remediation rather than documentation-only treatment.

1. Disable JSON:API and HAL where unused — Remove the affected serializer paths from applications that do not require them. This is the cleanest exposure reduction and should be deployed within backlog hygiene cadence for a LOW issue, ahead of the actual library update if change control is slower.
2. Pin affected services to classic php-fpm request isolation — If you currently run FrankenPHP worker mode, RoadRunner, Swoole, or similar, reverting the impacted API services to classic request-isolated php-fpm breaks the cache persistence assumption behind this bug. Use this as a temporary control where upgrade lead time is long.
3. Audit ApiProperty(security=...) usage on JSON:API/HAL resources — Inventory resources that apply per-property security depending on the requesting user and are serialized through JSON:API or HAL. Those endpoints are your high-value subset; review them first and keep the audit inside the normal LOW-severity remediation cycle.
4. Override the normalizers if you cannot upgrade quickly — The advisory explicitly suggests overriding the JSON:API and HAL ItemNormalizer services to gate cache_key with a resource-class security check. Use this only when package upgrades are blocked and document the local patch.

Run this on the application host, build workspace, or CI runner that has the target app's composer.lock. Invoke it as python3 check_cve_2026_49858.py /var/www/app/composer.lock. It needs only read access to the lockfile; no root privileges are required.

#!/usr/bin/env python3
# Check exposure to CVE-2026-49858 in API Platform packages.
# Usage: python3 check_cve_2026_49858.py /path/to/composer.lock
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import json
import os
import re
import sys
from typing import Optional, Tuple

AFFECTED = {
    'api-platform/core': [
        ((2, 6, 0), (4, 1, 29)),
        ((4, 2, 0), (4, 2, 25)),
        ((4, 3, 0), (4, 3, 8)),
    ],
    'api-platform/json-api': [
        ((4, 0, 0), (4, 1, 29)),
        ((4, 2, 0), (4, 2, 25)),
        ((4, 3, 0), (4, 3, 8)),
    ],
    'api-platform/hal': [
        ((4, 0, 0), (4, 1, 29)),
        ((4, 2, 0), (4, 2, 25)),
        ((4, 3, 0), (4, 3, 8)),
    ],
}

FIXED = {
    'api-platform/core': '4.1.29 / 4.2.25 / 4.3.8',
    'api-platform/json-api': '4.1.29 / 4.2.25 / 4.3.8',
    'api-platform/hal': '4.1.29 / 4.2.25 / 4.3.8',
}

SEMVER_RE = re.compile(r'^(?:v)?(\d+)\.(\d+)\.(\d+)')


def parse_version(v: str) -> Optional[Tuple[int, int, int]]:
    m = SEMVER_RE.match((v or '').strip())
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def in_range(ver: Tuple[int, int, int], start: Tuple[int, int, int], end_exclusive: Tuple[int, int, int]) -> bool:
    return start <= ver < end_exclusive


def load_packages(lockfile: str):
    with open(lockfile, 'r', encoding='utf-8') as fh:
        data = json.load(fh)
    packages = []
    packages.extend(data.get('packages', []))
    packages.extend(data.get('packages-dev', []))
    return packages


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN - usage: python3 check_cve_2026_49858.py /path/to/composer.lock')
        sys.exit(2)

    lockfile = sys.argv[1]
    if not os.path.isfile(lockfile):
        print(f'UNKNOWN - composer.lock not found: {lockfile}')
        sys.exit(2)

    try:
        packages = load_packages(lockfile)
    except Exception as exc:
        print(f'UNKNOWN - failed to parse composer.lock: {exc}')
        sys.exit(2)

    found = []
    vulnerable = []
    unknown_versions = []

    for pkg in packages:
        name = pkg.get('name')
        version = pkg.get('version', '')
        if name not in AFFECTED:
            continue
        found.append((name, version))
        parsed = parse_version(version)
        if parsed is None:
            unknown_versions.append((name, version))
            continue
        for start, end_exc in AFFECTED[name]:
            if in_range(parsed, start, end_exc):
                vulnerable.append((name, version, FIXED[name]))
                break

    if vulnerable:
        details = '; '.join([f'{n} {v} (fixed in {f})' for n, v, f in vulnerable])
        print(f'VULNERABLE - {details}. Note: exploitability additionally requires JSON:API/HAL + user-dependent ApiProperty security + long-running PHP worker reuse.')
        sys.exit(1)

    if unknown_versions:
        details = '; '.join([f'{n} {v}' for n, v in unknown_versions])
        print(f'UNKNOWN - installed package versions could not be parsed: {details}')
        sys.exit(2)

    if found:
        details = '; '.join([f'{n} {v}' for n, v in found])
        print(f'PATCHED - installed API Platform packages are outside known affected ranges: {details}')
        sys.exit(0)

    print('PATCHED - none of api-platform/core, api-platform/json-api, or api-platform/hal were found in composer.lock')
    sys.exit(0)


if __name__ == '__main__':
    main()

Sources

1. GitHub Security Advisory GHSA-pjhx-3c3w-9v23
2. Packagist: api-platform/core
3. Packagist: api-platform/json-api
4. Packagist: api-platform/hal
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS API documentation
7. Prior related API Platform advisory GHSA-428q-q3vv-3fq3