Aspera Faspex flaw lands in CISA's KEV with a three-day clock

CISA added four vulnerabilities to its Known Exploited Vulnerabilities catalog on November 9, all of them on evidence of active exploitation. The one most likely to be sitting in an enterprise estate is CVE-2026-123218, an authorization bypass in IBM Aspera Faspex that IBM itself scores at CVSS 9.8.

The other three are CVE-2026-102895 in GPUStack, CVE-2026-116779 in SignalWire FreeSwitch, and CVE-2026-123158 in OpenBSD's OpenSSH, the Alpine password bypass we covered on November 6. That last one had not been in the catalog when we wrote about it. It is now.

The part that changed

A KEV listing used to mean a remediation date a few weeks out. Binding Operational Directive 26-04, which now governs federal vulnerability management, compresses that to three days for the flaws it treats as high risk, according to SecurityWeek's reporting on this batch. Count three days from a November 9 listing and agencies are already out of time as you read this.

The directive also narrows what agencies must rush. Speed is reserved for high-risk flaws on publicly exposed assets that hand an attacker complete control once exploited; lower-risk work waits. An internet-facing file transfer server, where the bug grants full administrative rights, is squarely what it has in mind.

The second change gets less attention and matters more. BOD 26-04 sets out when an agency has to establish whether intruders were already inside before the fix went on. Patching closes the hole. It does not tell you whether somebody walked through it last week, and for a flaw listed on evidence of active exploitation that is the open question.

None of this binds a private company. CISA's own line is that it "encourages all organizations" to work this way and put the catalog first. The useful part for a private estate is the clock and the triage step, not the legal obligation.

What IBM says about the Faspex bug

IBM published its bulletin on November 7. The flaw is CWE-863, incorrect authorization: an authorized user can craft a specific message to bypass user authorization and gain full administrative privileges. Versions 5.0.0 through 5.0.19 are affected. The fix is 5.0.19 PL1 on Linux, and IBM asks customers to validate that the faspex-core container image reads 5.0.19 (1ce4b13, Fix Pack: 1) once the upgrade is in.

Under workarounds and mitigations, IBM lists None. There is no configuration change to buy time with, which is the detail that decides the week: the upgrade is the only move available.

Note what IBM does not say. Its bulletin names no campaign, no victim and no attack method beyond a crafted message, and never states the flaw was exploited. CISA's listing is the only exploitation evidence here.

The OpenSSH entry has a tail

Our November 6 story has the fixed Alpine builds and the exposure checks. Two things are worth repeating now that the flaw is catalogued.

Installing the package does not restart a running sshd. The old binary stays in memory, still accepting connections, until the service is restarted. A patched package list is not a patched estate.

And the exploitation window was short. Previdian reported that its first observed attempt arrived "less than nine hours after CVE publication", and said it had seen the flaw yield root on one of its Alpine honeypots. If an exposed host ran an affected build at any point in the last week, the triage step is the work, not the patch.

What IT teams should do

• Inventory every Aspera Faspex instance, including any a business unit stood up for one customer transfer. Faspex exists to move files with outside parties, so exposure is the norm here.
• Upgrade to 5.0.19 PL1 and check the faspex-core image tag afterward. IBM offers nothing else.
• Work to the federal three-day window even though it does not bind you. It is short because this class of flaw gets used quickly; that timetable has already run out.
• Do the triage, not just the patch. For Faspex, review administrative actions and account changes made before the upgrade. For the OpenSSH hosts, check /var/log/messages for accepted password logins on accounts that should have no password, then review doas use, new local accounts and authorized_keys files.
• Where a login cannot be ruled out, treat the host as compromised rather than patched.
• Confirm sshd restarted on every host you patched last week.

Sources: CISA KEV additions, November 9, IBM Security Bulletin for CVE-2026-123218, Horizon3 on CVE-2026-123158, Help Net Security on the OpenSSH exploitation, SecurityWeek via TechBytes on the three-day window.