Web Push notification account-binding issue corrected
Summary
On 2026-07-15, WAYSCloud identified an account-lifecycle issue affecting Web Push notifications in the meil.no Progressive Web App.
A browser push subscription could remain associated with an account after that account had logged out. If another account was subsequently authenticated in the same browser or installed PWA, the device could continue receiving notifications associated with the previously authenticated account.
The issue could expose limited notification metadata, depending on the affected account’s notification privacy settings. It did not make the underlying email, calendar event or account data accessible through the notification.
Opening an affected notification did not retrieve information from the account for which the notification had been generated. All subsequent requests remained authorised within the account that was currently authenticated on the device.
Our investigation found no evidence that email contents, calendar contents, credentials or account data were accessed by another customer. The confirmed report involved two accounts controlled by the same person on the same device.
The defect was identified, corrected and verified. No customer action is required.
What Happened
Web Push subscriptions are created by the browser and registered with meil.no so that new-email and calendar-reminder notifications can be delivered to a specific device.
A legitimate authenticated session was required when the subscription was originally created. In the confirmed case, push had first been enabled while account A was authenticated. The same device was later authenticated as account B, but the existing browser push subscription remained registered to account A.
This meant that the device could continue receiving notifications generated for account A while the visible application session belonged to account B.
Depending on the notification privacy setting selected for account A, the displayed notification could contain limited metadata, such as:
- a generic indication that a new message had arrived,
- the sender’s displayed identity,
- the message subject.
The notification did not contain the email body, attachments, mailbox credentials or an authenticated copy of the underlying message.
When the notification was opened, the application attempted to use the notification’s item identifier within the account that was currently authenticated. Because identifiers and mailbox access are account-scoped, account B could not retrieve the corresponding email or calendar data from account A.
The application therefore remained within account B and did not display the content associated with account A.
Root Cause
This was a stale push-subscription binding, not a failure of mailbox, calendar or tenant isolation.
The browser notification channel had been legitimately established while the original account was authenticated. The defect was that this device registration was not reliably removed or rebound when the application’s authenticated account later changed.
The underlying email and calendar APIs continued to enforce the currently authenticated user and workspace. A notification generated for one account did not grant the active account permission to retrieve the associated content.
The following lifecycle conditions combined to create the issue:
1. Logging out did not remove the browser’s Push Subscription or revoke its server-side registration.
2. Application startup repaired missing subscriptions but did not rebind an existing subscription to the currently authenticated account.
3. Server-side cleanup could not revoke an endpoint that remained associated with a previously active account.
4. Notification navigation did not verify that the currently authenticated account matched the account for which the notification had been generated.
As a result, limited notification metadata could remain visible on a device after the application session had changed, while the underlying account data remained inaccessible.
Impact
The confirmed incident involved two accounts belonging to the same person and authenticated on the same iPhone at different times.
We found no evidence that:
- another customer’s mailbox or calendar was opened,
- an email body or attachment was retrieved through the wrong account,
- calendar-event contents were retrieved through the wrong account,
- authentication credentials or session tokens crossed account boundaries,
- an item identifier in a notification could be used to bypass account authorisation,
- customer information was disclosed through the application to another authenticated account.
The information potentially visible through the push notification itself was limited to notification metadata and depended on the account’s configured notification-detail level.
This nevertheless represented a genuine privacy risk. If a device were shared, reused or transferred without being reset, its existing browser push subscription could potentially continue displaying metadata associated with the previous user.
Mobile devices are commonly reset before being transferred to another person, which reduces the practical likelihood of that scenario. WAYSCloud does not, however, consider user device-reset practices to be an adequate security control. The platform must remove or invalidate the notification relationship when the associated session ends or changes.
We therefore treated the issue as a security- and trust-relevant defect even though the underlying email and calendar information remained protected.
Security Boundary
The issue affected the notification display channel only.
A push notification could indicate that an event had occurred in a previously authenticated account, and could in some configurations expose limited descriptive metadata. It did not carry authority to access that account.
Access to emails and calendar events continued to require a valid authenticated session for the correct user and workspace. Being authenticated as another account on the same device did not satisfy this requirement.
Consequently:
- possession of the notification did not provide access to the underlying item,
- the currently authenticated account could not retrieve data belonging to the notification’s target account,
- opening the notification did not transfer or reuse the previous account’s authentication,
- no cross-account data fetch was successfully performed.
The remediation also prevents the application from attempting such a fetch by validating the intended account before opening a notification deep link.
Our Commitment
WAYSCloud publishes security- and trust-relevant findings even when the underlying account data remained protected and no unauthorised access has been identified.
In this case, the defect was limited to the continued display of push-notification metadata from a previously authenticated account. The notification did not provide access to the related email, calendar event or account.
The confirmed situation involved two accounts controlled by the same person. Nevertheless, the same stale device registration could have created a metadata-exposure risk on a shared or transferred device that had not been reset.
Because physical-device ownership and notification visibility are important privacy boundaries, we corrected the complete subscription lifecycle rather than relying on common user behaviour such as resetting a phone before transfer.
No customer mailbox or calendar data was accessed through the wrong account, and we found no evidence that information beyond limited notification metadata was disclosed to another customer or unauthorised third party.