nforum closes a cross-project back door in folder handling

Three document-organization endpoints were trusting folder IDs without checking which project they belonged to - nforum tightened all three.

securityknowledge-management

When you move, delete, or reassign folders inside a matter, the system should make sure the folder actually lives in that matter. nforum found three places where it didn't: a caller who happened to know a valid folder ID from a different project could trigger operations that reached across the boundary - including quietly knocking documents loose from their folder in a project that wasn't theirs.

The fix adds a single shared check that every one of those endpoints now runs before doing anything: confirm the folder belongs to this project, or return a not-found. It's a small, clean change, but it shuts a real authorization gap. nforum also flags that the same loose pattern may exist elsewhere in the project's routes - worth a wider sweep.

So what Anyone running Mike with multiple clients or matters in one instance should care: this is the kind of quiet data-isolation bug that turns into a breach-notification conversation.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from nforum/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
7062a300 fix project folder boundary checks Eli Fayerman 2026-05-04 ↗ GitHub
e178b995 Merge PR #28: fix project folder boundary checks Bojan Plese 2026-05-07 ↗ GitHub

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-52.md from inside the repo you want the changes in.

⬇ Download capture-thread-52.md