[BUG][UPDATED TITLE] When a share URL is truncated/corrupted, the app silently falls back to the demo plan

[uqarni]

My engineer clicked on the URL I shared with him in Whatsapp, but Whasapp dropped the last few characters of the link.
And it pointed him to someone else's plan that was totally unrelated to ours.

This should not be possible if properly implemented.

[backnotprop]

A link would be helpful, otherwise this really isn't possible. That site is a static site, it's just hosted through CloudFront. There's no storage of plans.

Maybe there was an error reading the base64 from your URL, and therefore it showed the default demo plan: https://share.plannotator.ai/

If you load that site by itself, there's a default/hardcoded plan that is used for demos.

[backnotprop]

Investigation Report

Investigated the full sharing stack — encoding pipeline, static site deployment, and truncation behavior.

Architecture (no server-side storage)

• share.plannotator.ai is a pure static site (S3 + CloudFront). No backend, no database, no plan storage.
• The entire plan + annotations are compressed into the URL hash fragment using deflate-raw + base64url encoding (packages/ui/utils/sharing.ts).
• On load, the app reads window.location.hash, decompresses it client-side, and renders the plan. Nothing is sent to or retrieved from any server.

What happened with the truncated URL

When WhatsApp drops the last few characters of the share link, the truncated hash fails to decompress (deflate streams are not tolerant of truncation). The app's error handling path:

1. parseShareHash() catches the DecompressionStream error → returns null
2. isSharedSession stays false
3. App tries fetch('/api/plan') — static site returns 404
4. Falls back to the hardcoded demo plan (PLAN_CONTENT in packages/editor/App.tsx:37-328)

The "unrelated plan" your engineer saw was the built-in demo plan — "Implementation Plan: Real-time Collaboration" with WebSockets, operational transforms, etc. It's the same content anyone sees at https://share.plannotator.ai/ with no hash.

Conclusion

Not a security vulnerability — no one can see another user's plan. Plans exist only in the URL itself and are never stored server-side.

It is a UX bug — when a share URL is truncated/corrupted, the app silently falls back to the demo plan instead of showing an error message. This reasonably led to the assumption that another user's plan was being displayed.

Recommendation

Show an error state when a hash is present but fails to decompress, e.g. "This share link appears to be incomplete or corrupted. Ask the sender to re-share the full URL."

---

🤖 Generated with Claude Code

[backnotprop]

@uqarni ive changed the title to avoid scaring others... let me know if you disagree

[backnotprop]

Tangentially related: PR #146 adds the ability to self-host the share portal via PLANNOTATOR_SHARE_URL. For anyone with formal security concerns about share links pointing to an external domain, you can now host the portal on your own infrastructure and have all generated links point there.

To be clear (as noted in the original investigation above): the hosted portal at share.plannotator.ai is a static SPA with no backend — plan data is never stored or transmitted anywhere. It lives entirely in the URL hash and is decoded client-side. But for environments where even pointing at an external domain is a policy concern, self-hosting is now an option.

[uqarni]

Hey Michael Thanks for the quick response and yes all good. Just realized any truncation of the long uuid points to this default plan you have about websockets. Maybe that should point to something else like “this is a demo plan”? It definitely freaked us out. Also just wanna say I LOVE plannonator and am so glad we can continue using it and that you didn’t implement something that would have made no sense lol.

…

On Thu, Feb 12, 2026 at 1:24 PM Michael Ramos ***@***.***> wrote: *backnotprop* left a comment (backnotprop/plannotator#142) <#142 (comment)> Tangentially related: PR #146 <#146> adds the ability to self-host the share portal via PLANNOTATOR_SHARE_URL. For anyone with formal security concerns about share links pointing to an external domain, you can now host the portal on your own infrastructure and have all generated links point there. To be clear (as noted in the original investigation above): the hosted portal at share.plannotator.ai is a static SPA with no backend — plan data is never stored or transmitted anywhere. It lives entirely in the URL hash and is decoded client-side. But for environments where even pointing at an external domain is a policy concern, self-hosting is now an option. — Reply to this email directly, view it on GitHub <#142 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ3KKMXTE6FSBAMLNBZQXID4LTVQZAVCNFSM6AAAAACUZRE2UOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOJTGQ2TSNBVHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>