Hall of Fame
Back to Hall of Fame Contents Back to WeKan Website

ZipBombBleed

CVEIconVulnerability nameDate Responsible Security Disclosure byStarsProcessVulnerabilities
-

ZipBombBleed 2026-10-02 xet7, alham-rizvi Gold starGold starGold star Found while auditing zip imports after the 2026-10-02 Hall of Fame review; fixed by xet7. Independently reported by alham-rizvi in GHSA-rmcq-68x2-3g5j and verified on 2026-10-03 as already fixed in v12.15.

The Trello zip import checked sizes from entry.vars.uncompressedSize, a field the zip library's directory entries do not have, so every check saw zero and an archive of a few hundred kilobytes inflated without limit in memory: any signed-in user could exhaust the server. The WeKan zip import read wekan.json with no limit at all, and POST /api/import/zip accepted any active member rather than one with write access.

Entries are read through one bounded reader that counts the bytes actually inflated, with a limit per entry and per archive, and the zip import requires write access.

CWE-409. High severity: a denial of service by any signed-in user. No CVE assigned. Fix prepared locally for the Upcoming release; not yet released.

Details

Both zip imports open the archive with unzipper. The Trello import meant to refuse oversized entries and read the size from entry.vars.uncompressedSize, but the directory entries the import uses carry it as entry.uncompressedSize, not under vars. Every check compared against undefined, saw nothing, and inflated the entry whole into memory.

Repetitive data compresses enormously, so a small upload could become gigabytes in the server's memory and stopped it. The WeKan zip import read its wekan.json with no limit at all, and the REST route POST /api/import/zip let any active member of the board import, where the method requires write access.

Fix

readZipEntryBounded inflates an entry while counting the bytes it actually produces and stops at a limit per entry and a limit for the whole archive, whatever the archive declares. Both imports read entries only through it. The zip import route requires write access to the board.

Detection

None. An oversized entry can be an honest large export, so a refusal does not identify an attack and is not recorded in Admin Panel → Problems.

Verification

Unit tests in tests/zipBombBleed.test.cjs build a real small archive that inflates to megabytes and show that the declared size is not where the old check looked, check that both imports read entries only through the bounded reader, and the negative test fails on any server code that inflates a zip entry whole or trusts entry.vars. The unit tests pass in the WeKan repository. The original verification did not include a browser test; see the later browser verification below.

Source fix and regression tests

Independent report verification, 2026-10-03

GHSA-rmcq-68x2-3g5j describes the native wekan.json path already fixed in commit e7ed71ee2ec90558abe775a48f17923e449a4d45, included in v12.15. The document is bounded to 256 MiB of actual decompressed output. The strengthened archive test names wekan.json and confirms a forged declared size does not bypass the byte counter.

Browser verification, 2026-10-03

Using build.sh source-mode startup and isolated local MongoDB, Chromium, Firefox and WebKit each passed all three focused scenarios: SAML error display, a real signed login followed by a different-subject takeover refusal, and native ZIP decompression-limit refusal followed by a valid import. The macOS Firefox launch initially failed on protected shared app data; isolating both Gecko app-data roots resolved it, with probes enabled and all browser sandboxes retained. Production identity providers were not tested.