Security Vulnerability: Channel invite code leaked via message links (Enables unauthorized channel access)

[pooh-winnie]

Thanks for the thorough follow-up testing! The subchannel behavior is a real gap. The original fix only blocked the copy-link action and prevented non-members from auto-joining parent channels via deep links, but subchannels inherit access differently and weren't covered.

I'll do a dedicated pass on subchannel access control. The guest-preview idea is genuinely interesting but it's a much bigger change that'd need its own design pass, so that's more of a longer-term thing. The immediate priority is just making sure non-members can't load subchannel history or post by crafting a link.

Will update here when there's something to test.

[ancsemi]

Pushed a hardening pass in 5c94f6d. Private and hidden channels no longer expose copy-link actions, and deep links no longer auto-join channels when the user is not already a member. This closes the message-link path that was leaking joinable private channel codes. Please retest with a non-member account and let me know if you still see a bypass path.

[pooh-winnie]

Thanks so much for the quick update and for working on this! I really appreciate your time and effort on this project.

I did some additional testing with the new changes and wanted to share a few friendly findings and thoughts. Hopefully, this helps fine-tune the feature!

1. A small note on the UI ("Copy Link")

Hiding the "Copy Link" action definitely stops the leak for parent channels! However, from a user experience perspective, legitimate members of a private channel might still want to share message links with each other inside the channel. Total removal works as a quick safety net, but maybe down the road, we could find a way to keep the button for existing members?

2. Behavior with Subchannels (Child Channels)

It looks like subchannels handle the links a bit differently right now. Here is what I noticed during testing:

• If a non-member opens a subchannel deep link (like app.html?channel=af741d0d&message=2124), the subchannel loads completely. They can view the history and even post a message (though they don't stay joined after a page refresh).
• The same happens if they copy just the subchannel code (af741d0d) and put it into "Join a Channel".
• It seems the routing grants access based on the channel parameter alone, while the message ID acts more like a visual scroll anchor.

Ideas for a future implementation (Secure Preview)

Just as a suggestion for whenever you have the time and inspiration, we could potentially solve both the UX and security sides like this:

1. For channel members: The link opens normally, takes them to the channel, and highlights the message.
2. For guests/non-members: If they open the link, the system could show only that specific message ID in a read-only "Guest Preview" mode, without loading the full channel history or allowing them to type.

Thank you again for amazing work on Haven!

[ancsemi]

Thanks for the thorough follow-up testing! The subchannel behavior is a real gap. The original fix only blocked the copy-link action and prevented non-members from auto-joining parent channels via deep links, but subchannels inherit access differently and weren't covered.

I'll do a dedicated pass on subchannel access control. The guest-preview idea is genuinely interesting but it's a much bigger change that'd need its own design pass, so that's more of a longer-term thing. The immediate priority is just making sure non-members can't load subchannel history or post by crafting a link.

Will update here when there's something to test.

[ancsemi]

Got the subchannel gap closed. The hole was on the server: entering or crafting a subchannel's code added you straight into that subchannel without ever checking whether you belonged to its parent, and since loading history and posting only check membership, that one step was enough to get in. Now a subchannel can only be joined if you're already a member of its parent, and private subs aren't grantable by code at all (those need an explicit add). So a crafted ?channel= link or pasting the bare subchannel code into "Join a Channel" just returns the generic invalid-code error now, with no history load and no posting. Top-level channels are unchanged.

This is on main for the next build. If you get a chance to retest with a non-member account once it's out, let me know if you can still reach any subchannel you shouldn't. The guest-preview idea is still a neat one for down the road, but this at least shuts the access path.