IBM Aspera Faspex Authorization Bypass (CVE-2026-123218): Patch Now

What is known as of 13 November 2026

IBM published its bulletin for CVE-2026-123218 on 7 November 2026. The flaw is an incorrect authorization weakness (CWE-863) in IBM Aspera Faspex 5. IBM describes it as a way to craft a specific message that bypasses user authorization and gains full administrative privileges. IBM scores it 9.8 out of 10 under CVSS 3.1.

On 9 November 2026 CISA added it to the Known Exploited Vulnerabilities (KEV) catalog as 'IBM Aspera Faspex Incorrect Authorization Vulnerability'. CISA's entry gives 12 November 2026 as the due date for US federal civilian agencies, records known ransomware campaign use as 'Unknown' and says forensic triage is required under its BOD 26-04 directive. That deadline has now passed for those agencies. For everyone else, a KEV listing is a clear signal that this belongs at the front of the patching queue.

IBM's bulletin lists no workarounds or mitigations. The only vendor-supported remedy is the patch.

Which Faspex installations are affected

IBM's affected-versions table names IBM Aspera Faspex 5.0.0 through 5.0.19. The fixed release is 5.0.19 PL1 (patch level 1) for Linux. If you run a different Aspera product or an older Faspex generation, read IBM's bulletin for your exact product rather than assuming either way, because the affected-versions table only names Faspex 5.0.x.

The quickest check is on the Faspex host itself. Run this as root. It only reports the installed container image versions and changes nothing.

faspexctl version

Understanding the risk

The practical worst case is an attacker ending up with full administrative control of your Faspex server. Faspex is a file-exchange platform, so administrative access could expose the files, user lists and sharing configuration it holds. How far an attacker could go in your environment depends on what is stored there and who can reach the service.

There is one wrinkle worth knowing about. IBM's description says an 'authorized user' can craft the message, which implies the attacker already has an account. Yet the CVSS vector IBM published (AV:N/AC:L/PR:N/UI:N) says no privileges are required, which would mean no login at all. The sources checked do not explain the difference. Until IBM clarifies, assume the worse reading for any Faspex server reachable from the internet, and remember that on an internal-only server any ordinary account, including a compromised one, may be enough.

CISA's inclusion of the flaw in KEV is its statement of evidence of exploitation. The sources we could check do not describe who is exploiting it, how, or against whom. IBM's bulletin and the CVE record do not state whether exploitation has occurred.

Patching Faspex to 5.0.19 PL1

IBM's route to the fix is its procedure for patching container images, which pulls updated images for your current release tag. IBM notes you do not need to upgrade the Faspex 5 RPM for this procedure. Both commands below are run as root on the Faspex host.

Applying new images is a service-affecting change, so schedule it for a quiet period, tell your users and make sure you have a recovery point for the host (for example a virtual machine snapshot or your normal backup) before you start.

1. Run faspexctl version and note the current faspex-core image version. If it is outside 5.0.0 to 5.0.19, or already shows Fix Pack 1, stop and compare it against IBM's bulletin.
   bashCopy

   faspexctl version

2. Run faspexctl setup to apply the updated container images. Allow it time to finish, because images may need to be downloaded and services brought back up. Do not interrupt it.
   bashCopy

   faspexctl setup

3. Run faspexctl version again. IBM's bulletin says the faspex-core container image should show 5.0.19 with build 1ce4b13 and Fix Pack 1. If it still shows the old build, the patch has not been applied.
   bashCopy

   faspexctl version

4. Sign in to Faspex as an administrator and confirm the service responds and that a normal transfer or package send behaves as expected.

If you cannot patch straight away

IBM has no workaround, so nothing below is a substitute for the patch. These are general risk-reduction measures that reflect our engineering judgement, not IBM guidance.

The most effective interim step is to cut off who can reach the Faspex web interface. If it is published directly to the internet, restrict it to known addresses or put it behind a VPN until the patch is in. Keep a note of what you changed, because it may affect external partners who send or receive files through the service. CISA's KEV entry also asks organisations to assess the internet exposure of each affected asset, which is a sensible question for any Faspex server.

Checking whether anyone got in first

Patching closes the hole. It does not remove an attacker who has already used it. CISA's catalog flags forensic triage for this flaw, so it is reasonable for any organisation with an exposed server to look back as well as forward.

Look for evidence that someone gained administrative rights: administrator accounts or role changes you did not make, new users or access credentials you do not recognise, changed sharing or configuration settings, and unexpected file transfers or downloads. Check any logs you retain from Faspex and from the reverse proxy, firewall or load balancer in front of it, covering the period from at least 7 November 2026 and earlier where your retention allows. The vulnerability was published on that date but its exploitation window is not publicly documented, so earlier activity cannot be ruled out.

If you find anything suspicious, preserve the logs and the host before making further changes, rotate credentials and API keys that Faspex holds, and involve incident-response support. If you have no logs to examine, that is itself worth noting, because it limits how confidently you can say the server was untouched.

What has not been confirmed

No organisation has been publicly named as affected by this specific vulnerability in the sources checked, and we are not naming any. CISA's entry records ransomware use as unknown. Some secondary reports differ on how CISA's deadlines are described, so rely on CISA's catalog entry itself.

This page will be updated if IBM revises the bulletin, publishes further mitigation guidance or if authorities release more detail about exploitation.