# IBM Aspera Faspex CVE-2026-123218: detection pack

Authorization bypass to full admin in IBM Aspera Faspex 5 (IBM's managed file transfer server).

> **Status of this pack.** The KQL in `kql/` and the converted Sigma in `sigma/converted/` have NOT been run against a
> live Sentinel or Defender tenant. Test and tune them before you rely on them. IBM has published no indicators of
> compromise. Every hunting pattern here is our own, and items we could not confirm from IBM are marked [UNVERIFIED].

## Facts (primary sources, checked 9 Nov 2026)

| Item | Value | Source |
|---|---|---|
| CVE | CVE-2026-123218, "IBM Aspera Faspex Authorization Bypass" | cve.org record (CNA: IBM) |
| Weakness | CWE-863 Incorrect Authorization | IBM bulletin, cve.org, NVD |
| Severity | CVSS 3.1 base 9.8 Critical, `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` | Set by IBM as CNA (psirt@us.ibm.com). NVD has not scored it (status "Awaiting Analysis") |
| Affected | IBM Aspera Faspex 5.0.0 through 5.0.19 (Linux) | IBM bulletin, cve.org, NVD |
| Fixed | IBM Aspera Faspex 5.0.19 PL1. Check that `faspex-core` reads `5.0.19 (1ce4b13, Fix Pack: 1)` | IBM bulletin |
| Workaround | IBM lists "Workarounds and Mitigations: None" | IBM bulletin |
| Disclosed | 7 Nov 2026 (IBM bulletin "Initial Publication"; CVE published 2026-11-07 03:47 UTC) | IBM bulletin, cve.org |
| Exploited | Yes. CISA added it to the KEV catalogue on 2026-11-09 | CISA KEV |
| KEV due date | 2026-11-12 | CISA KEV |
| KEV forensic triage | "Yes" (forensics triage required under BOD 26-04) | CISA KEV |
| Ransomware use | "Unknown" | CISA KEV |
| IOCs | None published by IBM | IBM bulletin |
| Credit | None given (IBM's Acknowledgement section is empty) | IBM bulletin |

**The KEV due date applies to US federal agencies only (BOD 26-04). Patch now regardless.**

### Does an attacker need an account?

The written descriptions and the score disagree.

* IBM's description: "could allow an **authorized user** to craft a specific message to bypass user authorization and
  gain full administrative privileges."
* IBM's bulletin summary and CISA KEV: "could allow an **authenticated user** to craft a specific message to bypass
  authorization, causing privilege escalations."
* IBM's CVSS vector: `PR:N` (Privileges Required: None), which in CVSS terms means no account is needed.

**Our reading:** every written statement from IBM and CISA says the attacker must already be a logged in Faspex user,
so treat this as "any account, even a low privilege or external one, can become full admin". The `PR:N` in IBM's own
vector conflicts with that and IBM has not explained it. Do not tell clients it works with no account at all, and do
not tell them they are safe because they have no untrusted users: on servers with self registration or many external
accounts, getting an account may be easy.

## Patch first

1. Find every Faspex 5 server (KQL Q1, Q1b, Q1c), internet facing ones first.
2. Upgrade to 5.0.19 PL1 by following IBM's "Patching container images" procedure (`faspexctl setup`).
3. Run `faspexctl version` as root and confirm `faspex-core: 5.0.19 (1ce4b13, Fix Pack: 1)`. Feed the saved output to
   the checker below.
4. KEV marks this for forensic triage, so hunt (below) on every server that ran an affected version, even after patching.

**Our own hardening advice (not from IBM, which lists no workaround):** until patched, limit access to the web UI and
API by IP allow list or VPN, turn off self registration, remove external accounts you do not need, review all accounts
and roles, and rotate credentials for shared and external users. These reduce who can try the attack; they do not fix it.

## Contents

| Path | What it is |
|---|---|
| `kql/ibm-aspera-faspex-cve-2026-123218-hunting.kql` | Q1 to Q1c inventory and exposure; Q2, Q2b admin API use (CommonSecurityLog); Q3 bulk download specs; Q3b Syslog access logs; Q4, Q4b processes and faspexctl runs; Q5 file changes; Q6 new outbound, SMTP and LDAP destinations |
| `sigma/*.yml` | 5 rules: admin style API paths (webserver), admin API writes (webserver), download transfer spec (webserver), shell under container runtime (linux process_creation), file change under Aspera paths (linux file_event) |
| `sigma/converted/` | Kusto output for no pipeline, microsoft_xdr, microsoft_365_defender, sentinel_asim and azure_monitor |
| `scripts/check-faspex.sh`, `scripts/Check-Faspex.ps1` | Read-only offline checkers with identical output and exit codes |
| `tests/` | Bash tests, Pester tests (including a bash vs PowerShell parity check), synthetic fixtures, `run_all.sh` |

### Sigma conversion (sigma-cli 3.1.0, pySigma Kusto backend)

`sigma check`: 0 errors, 0 condition errors, 0 issues.

* The two Linux rules convert on every pipeline. `microsoft_xdr` and `microsoft_365_defender` map them to
  `DeviceProcessEvents` and `DeviceFileEvents`; `sentinel_asim` maps them to `imProcessCreate` and `imFileEvent`.
  Caveat: `azure_monitor` maps them to `SecurityEvent`, a Windows table, so that output is not usable for Linux hosts.
* The three webserver rules fail on `microsoft_xdr`, `microsoft_365_defender` and `azure_monitor` ("Unable to determine
  table name from rule") and on `sentinel_asim` (`cs-uri-stem` is not a supported field). They convert only without a
  pipeline, as bare field expressions you must point at your own table. Use KQL Q2, Q2b, Q3 and Q3b instead.

## Hunting (our patterns, not IBM indicators)

The exploit message is not public, so nothing here detects the exploit itself. These hunts look for what an attacker
would do once they are admin:

* New or changed admin accounts, users whose role went up, new API clients (Q2, Q2b, Faspex admin UI audit).
* Changes to SMTP, LDAP, SAML or other settings, and new SMTP or LDAP destinations from the server (Q2b, Q6).
* Unusual package downloads or bulk transfers (Q3, and the transfer logs in Faspex).
* Admin API calls from accounts or sources that are not known admins (Q2, Q3b). Web logs show the source IP, not the
  account, so match times against Faspex's own logs.
* Shells or downloaders under the container runtime, and file changes under Aspera paths (Q4, Q5). Admin access alone
  does not give a shell, so these are signs the attacker went further.

[UNVERIFIED] Admin endpoint names (`users`, `admin`, `configuration`, `smtp`, `ldap`, `saml`, `api_clients`,
`registration`, `accounts`) and `/transfer_spec/download` are our guesses. IBM documents the `/aspera/faspex/api/v5/`
base path, the token path `/aspera/faspex/auth/token`, `GET /api/v5/all/packages` (admin search),
`/packages/{id}/transfer_spec/upload` and that Users, SAML configuration and Nodes APIs exist.
[UNVERIFIED] Install and data paths (`/opt/aspera/`, `/etc/aspera/`), Faspex application log locations and field names,
and how Defender Vulnerability Management names Faspex.

**If you find signs of compromise:** isolate the server, keep the logs and container images, rotate every Faspex
credential and anything linked to it (SMTP, LDAP, SAML, node and API client secrets), check whether packages were
taken, and rebuild from a patched image. This response advice is ours; IBM's bulletin gives none. US federal agencies
must also follow CISA's forensics triage requirements.

## Checkers

Strictly read-only. They read files you supply and their arguments; they do not contact Faspex, open sockets, run
`faspexctl`, `docker` or anything else, or write files.

```
# On the Faspex host (as root), save the version output yourself, then copy it to where you run the checker:
#   faspexctl version > faspexctl-version.txt
bash scripts/check-faspex.sh --version-file faspexctl-version.txt --host fx01 [--log access.log ...]
bash scripts/check-faspex.sh --core "5.0.19 (1ce4b13, Fix Pack: 1)" --host fx01
bash scripts/check-faspex.sh --csv inventory.csv            # header: host,faspex_core
pwsh -File scripts/Check-Faspex.ps1 -VersionFile faspexctl-version.txt -HostName fx01 [-Log access.log]
pwsh -File scripts/Check-Faspex.ps1 -Csv inventory.csv
```

| Exit | Verdict | Meaning |
|---|---|---|
| 0 | PATCHED | faspex-core 5.0.19 build 1ce4b13 (Fix Pack 1 or not stated) |
| 1 | VULNERABLE | faspex-core 5.0.0 to 5.0.18, or 5.0.19 without build 1ce4b13 or Fix Pack 1 |
| 2 | UNKNOWN | No readable faspex-core version, or 5.0.19 with Fix Pack 1+ but a build other than 1ce4b13; also `--log` alone with no hits |
| 3 | NOT AFFECTED | Version outside IBM's 5.0.0 to 5.0.19 range |
| 4 | LOG REVIEW | Our log patterns matched (overrides the version verdict) |
| 5 | Usage or read error | |

CSV mode exits with the worst row (1 > 2 > 0 > 3). `--log` reads an nginx combined format access log and reports
successful (2xx) admin style API calls per source IP and download transfer spec requests at or above 20 per source IP
(our threshold). It cannot see which account made a request.

## Testing

`tests/run_all.sh` runs shellcheck, PSScriptAnalyzer, the bash tests, the Pester tests (including bash vs PowerShell
parity), guards (no network or write primitives in scripts, fixtures marked `FIXTURE_ONLY` with RFC 5737 IPs only,
no em or en dashes), both checkers inside a bwrap sandbox with no network and a read-only filesystem with a sha256
before and after check of the pack, and `sigma check` plus conversions. The fixtures are synthetic; `FIXTURE_ONLY` is
not a real value and no fixture contains an exploit message.

## ATT&CK mapping (MITRE)

T1190 Exploit Public-Facing Application, T1078 Valid Accounts, T1068 Exploitation for Privilege Escalation,
T1098 Account Manipulation, T1136 Create Account, T1213 Data from Information Repositories,
T1567 Exfiltration Over Web Service, T1059.004 Unix Shell.

## Sources

* IBM Security Bulletin: https://www.ibm.com/support/pages/node/7295921
* IBM docs, Patching container images: https://www.ibm.com/docs/en/aspera-faspex/5.0.x?topic=upgrades-patching-container-images
* IBM docs, Faspex 5 API differences: https://www.ibm.com/docs/en/aspera-faspex/5.0.x?topic=guides-differences-between-faspex-5-api-previous-versions
* IBM API Hub, Faspex 4 end of life notice (Sept 2023): https://developer.ibm.com/apis/catalog/aspera--aspera-faspex-client-sdk/
* NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-123218
* cve.org: https://www.cve.org/CVERecord?id=CVE-2026-123218
* CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (catalogue version 2026.11.09)
* CISA BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
* MITRE ATT&CK: https://attack.mitre.org/