The vulnerability in this release isn't just a missing authorization check — it's the combination of that check's absence with an endpoint specifically designed to grant unauthenticated access. The share token mechanism exists to let non-users view journey data without logging in, which means the token is architecturally a bypass around authentication, not a mishandled secret. The attack chain exploits this design: an attacker with any authenticated session can enumerate sequential journey IDs, harvest share tokens, then access those journeys permanently without any credentials at all. The enumeration is trivial because most ORMs default to auto-increment IDs, and the token retrieval endpoint returns data to any authenticated user regardless of ownership.
The CVSS 6.5 rating underweights the actual risk. It treats this as an authenticated-only vulnerability, but the downstream impact is unauthenticated, persistent access to personal data — gallery photos, location history, mood entries — that persists after the initial foothold is abandoned. There is no revocation mechanism, no alert when a token is accessed from a new context, and no rate limiting on token retrieval. Once harvested, tokens work indefinitely.
The critical question for your assessment: does version 3.1.0 add only the authorization check, or does it also implement token access logging, rate limiting, or non-sequential token generation? If the fix is limited to the authorization check alone, the architecture still contains a pathway that grants anonymous access to personal data, now protected only by token secrecy. That endpoint was the feature working as designed — it wasn't introduced by this vulnerability. The patch may have closed the enumeration vector, but if token access remains unmonitored, you have no way to detect whether tokens were already harvested before the fix was applied. Treat the share token endpoint as a sensitive authentication-equivalent surface going forward: log every retrieval, rate-limit aggressively, and consider whether the blast radius — which scales linearly with your user base — warrants architectural reconsideration of the unauthenticated access model itself.