One Day, 125 Advisories, Seven Release Trains Back — Kiteworks Publishes a Year of Fixes at Once
Kiteworks pushed 125 security advisories to its public repository on 30 September 2026. Press coverage settled on two different totals — BleepingComputer reported 126 vulnerabilities, securityonline.info counted 78 — and both numbers are defensible depending on when you looked and what you counted. We counted the source instead: the kiteworks/security-advisories repository holds 148 advisories in total, of which 125 carry a 30 September 2026 publication date. That batch breaks down as 12 critical, 49 high, 52 medium and 12 low.
The headline flaw deserves its headline. CVE-2026-54154 (GHSA-5xhq-9wq3-rvj6) is rated CVSS 10.0 — the maximum — and the advisory's own impact line is blunt: "A remote attacker may be able to execute arbitrary code with root privileges." It chains CWE-22 (path traversal), CWE-94 (code injection) and CWE-306 (missing authentication) in publicly reachable endpoints of the Email Protection Gateway, needs no credentials and no user interaction, and was reported through Kiteworks' bug bounty programme on YesWeHack by the hunters credited as wlayzz, icare and truff.
The number that matters is not 125
Read the batch by fixed-in version rather than by severity and a different story appears. Only 33 of the 125 advisories describe flaws fixed in the newest release, 9.5.1. Another 42 were fixed in 9.5.0. The remaining 50 were fixed in 9.2.1, 9.3.0, 9.3.1, 9.4.0 or 9.4.1 — releases that shipped well before this disclosure date. CVE-2026-54154, the 10.0, is one of them: its fix is 9.4.1, not 9.5.1.
This is not an accident or a backlog that got away from someone. It is written policy. The repository's SECURITY.md states it plainly: "We disclose vulnerability details up to 12 months after a fix has been released." Customers are pointed to the release notes bundled with each update for the real-time picture. The public advisory stream, by design, trails the patch stream by up to a year.
That policy is coherent from a vendor's chair and corrosive from a defender's. An operator who patched promptly to 9.4.1 in the normal course of business was protected from a CVSS 10.0 pre-auth root RCE without ever knowing it existed. An operator who deferred that upgrade as routine maintenance — no CVE, no advisory, no severity to escalate with — carried an unauthenticated path to root on an internet-facing mail gateway for however long the deferral lasted. Both made their decision with the same information: none.
What the 125 actually contain
Sorted by impact class, the batch reads like a full-platform audit rather than a point fix: 23 arbitrary code execution, 23 information disclosure, 18 privilege escalation, 16 security bypass, 11 access to internal network resources, eight unauthorised data modification, seven account takeover, seven spoofing, five unauthorised file modification, four denial of service and three cross-user script execution. By product: 66 in Core, 28 in Email Protection Gateway, 28 in Secure Data Forms, three in MFT Server.
The weakness tally points at systemic rather than incidental problems. The most common CWE across the batch is CWE-22 path traversal (14), followed by CWE-639 authorization bypass through user-controlled key (13), then CWE-306 missing authentication for critical function (12) and CWE-918 server-side request forgery (12), with CWE-269 improper privilege management (9), CWE-89 SQL injection (7) and CWE-78 OS command injection (7) behind them. Thirteen authorization-bypass-through-user-controlled-key findings in one batch is the signature of an access-control model that was checked object-by-object rather than enforced centrally.
Five of the twelve criticals are a single SSRF cluster — CVE-2026-102095, 102102, 102103, 102104 and 102105, each CVSS 9.1, each "access to internal network resources" in the Email Protection Gateway, all fixed in 9.5.0. A gateway that can be steered into making requests on an attacker's behalf is a pivot into whatever the mail path can reach.
The two criticals that genuinely required the newest release are worth naming. CVE-2026-102149 (CVSS 9.4, EPG, CWE-306 plus CWE-639) and CVE-2026-102147 (CVSS 9.3, Core, CWE-79) are both account takeover, both fixed only in 9.5.1. The NVD record for 102147 describes a stored XSS an unauthenticated attacker can plant, which then executes in an administrator's authenticated session and permits creating a new administrative account. Separately, CVE-2026-102115 (CVSS 9.8, fixed in 9.5.0) is a password-reset parameter the application failed to validate: an unauthenticated attacker who knows a target's email address could reset a locally stored password without the emailed link and authenticate as that user, administrators included.
The shutdown and the batch are two different events
The timing invites a conflation worth resisting. Last week Kiteworks told customers to power their servers off for nine hours on threat intelligence about an imminent attack, then lifted the advisory after fixing a previously unknown critical flaw confined to a capability enabled for under 1% of customers — with no CVE assigned and no technical detail published.
This 125-advisory batch is not that flaw. These advisories were published on 30 September with fixed-in versions stretching back to 9.2.1; the shutdown flaw remains, as of this writing, untracked by any CVE identifier. An organisation reading the batch as "the shutdown bug, now documented" would close the wrong gap. Threat watchdog Shadowserver was tracking close to 400 internet-exposed Kiteworks instances at the time of the 1 October reporting, with no public breakdown of how many are patched or are honeypots.
No source we reviewed reports in-the-wild exploitation of any CVE in this batch, and none of them appears in CISA's Known Exploited Vulnerabilities catalog at the time of writing. That is the one genuinely reassuring fact here, and it is perishable: a CVSS 10.0 pre-auth root RCE with a now-public CWE chain, against a product class that attackers have mined repeatedly, is a research target from the moment the advisory lands. Kiteworks, formerly Accellion, knows this history better than most.
What to do
- Upgrade to 9.5.1, and stop treating version currency as optional hygiene. No single lower version covers the batch: the criticals are spread across 9.4.1 (CVE-2026-54154), 9.5.0 (nine of them) and 9.5.1 (CVE-2026-102147, CVE-2026-102149). Only 9.5.1 is above all of them.
- Reconstruct your exposure window from release history, not from the advisory date. Because 50 of these were fixed in 9.2.1 through 9.4.1, the question your incident review needs to answer is not "when did we patch after 30 September" but "what version were we running, for how long, and was it reachable from the internet." An instance that sat on 9.3.x through 2026 was exposed to the 10.0 regardless of when the advisory appeared.
- Prioritise the EPG, then Core. The Email Protection Gateway carries the 10.0 and the five-CVE SSRF cluster, and it is the component most likely to be internet-facing. Core carries the largest raw count (66) and the 9.8 password-reset flaw.
- Hunt before you assume you are clean on CVE-2026-102147. Stored XSS that fires in an administrator's session and can create a new admin account leaves an artefact: review administrative account creation and privilege changes across the exposure window, not just current account state.
- Read the vendor's disclosure policy as a monitoring requirement. A documented "up to 12 months after fix" lag means advisory feeds will systematically understate your current risk for this vendor. For products with that policy, treat release notes as the security feed and subscribe to them directly; a CVE-triggered patch process will always be running a year late by design.
Our verification was documentary and source-first. We enumerated all 148 advisories directly from the official kiteworks/security-advisories GitHub repository via the GitHub API and computed the batch counts, severity split, product split, fixed-in distribution, impact classes and CWE tallies ourselves from that data rather than relying on any outlet's total — which is why our figure (125 advisories dated 30 September 2026) differs from both the 126 and 78 reported in the press. The CVE-2026-54154 impact wording, CWE chain, affected range and YesWeHack credits are quoted from the GHSA-5xhq-9wq3-rvj6 advisory body. CVE-2026-102115 and CVE-2026-102147 descriptions and CVSS vectors were confirmed against their NVD records. The 12-month disclosure policy is quoted from the repository's own SECURITY.md. Exposed-instance and press-total context came from BleepingComputer's 1 October 2026 report. We tested no Kiteworks deployment and sent no traffic to any third-party system.
Sources:
- kiteworks/security-advisories — official advisory repository (148 advisories total; 125 published 2026-09-30; severity, product, fixed-in and CWE data enumerated via the GitHub Security Advisories API)
- GHSA-5xhq-9wq3-rvj6 — CVE-2026-54154, CVSS 10.0, EPG before 9.4.1, root RCE; CWE-22/94/306; YesWeHack reporter credits
- Kiteworks SECURITY.md — "We disclose vulnerability details up to 12 months after a fix has been released"
- NVD — CVE-2026-102115 (CVSS 9.8, Kiteworks Core password-reset parameter validation, account takeover including administrators)
- NVD — CVE-2026-102147 (CVSS 9.3, stored XSS in Kiteworks Core executing in an administrator session, enabling creation of a new administrative account)
- BleepingComputer — "Kiteworks patches max severity code injection vulnerability" (1 October 2026; 126 vulnerabilities reported; CVE-2026-54154 fixed in 9.4.1; ~400 exposed instances per Shadowserver; prior precautionary shutdown context)
- securityonline.info — "Kiteworks Patches 78 Vulnerabilities, Including Critical Account Takeover Flaw" (1 October 2026; alternative press total; no confirmed in-the-wild exploitation)