IBM Aspera Faspex CVE-2025-36228

Requires a valid authenticated session on IBM Aspera Faspex 5 (versions 5.0.0 through 5.0.14.1); the attacker reaches features over the backend API that the web UI presents as disabled, because permission enforcement is inconsistent between the UI and the API layer (CWE-279). Limiting factors: exploitation is impossible without credentials (no anonymous access), there is no user-interaction or social-engineering vector, impact is confined to low confidentiality and low integrity effects from misusing the exposed features, and only the enumerated Faspex 5.0.x releases are affected. Realistically this is an insider or compromised-credential scenario rather than mass remote exploitation.

This is a low-severity, low-priority access-control weakness, not an urgent threat. The provided CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N) yields only 3.8 and already reflects the core limitation: an attacker must hold valid, privileged credentials (PR:H), and the resulting impact is limited (C:L/I:L, no availability or scope change). No EPSS score, CISA KEV listing, POC, or SSVC decision data was supplied, so there are no signals elevating this above its base score - no public exploit identified at time of analysis. The signals are internally consistent rather than conflicting: a network-reachable API combined with a required authenticated session and low technical impact. One note of tension: the CWE-279 (incorrect permission assignment) nature and the description - 'users to access features that appeared disabled' - suggest the real-world beneficiary is often a LOWER-privileged user who was never meant to reach the feature, which would argue for PR:L rather than the vendor's PR:H; this distinction is worth verifying with IBM but does not change the overall low-risk conclusion. Bottom line: a genuine defense-in-depth/least-privilege defect worth patching in normal maintenance cycles, but it is a low-real-risk issue, not an emergency.

An authenticated IBM Aspera Faspex 5 user notices that certain features are greyed-out or hidden in the web UI, then crafts direct calls to the backend API - which does not enforce the same restriction - to invoke those supposedly disabled features. No public exploit code is known, and because exploitation requires a valid account and remote API access, the attacker is typically an insider or a holder of compromised credentials rather than an anonymous outsider.