getRecipients adds the conversation contact to CC when replying to a third party

[thecravatman]

Describe the bug

When an email conversation contains a message from someone other than the conversation contact, getRecipients adds the conversation contact to the CC list. Replying to that third party therefore copies the original contact in, without the agent choosing it and without an obvious signal.

Call site, unchanged between v4.13.0 and v4.17.1:

// chatwoot/chatwoot, app/javascript/dashboard/components/widgets/conversation/ReplyBox.vue:1263
const { cc, bcc, to } = getRecipients(
  this.lastEmail,
  conversationContact,
  inboxEmail,
  forwardToEmail
);

To reproduce

1. An email conversation exists with contact A.
2. An inbound message arrives on the same thread from B, a different address — a supplier, contractor or colleague who has joined the chain.
3. The agent replies to B's message.
4. Observe A pre-populated in CC.

Expected behaviour

Recipients for a reply should derive from the message being replied to. The conversation contact should not be added automatically when they were not a party to that message. If the current behaviour is deliberate for some flows, it would be safer as an explicit action the agent takes rather than a default.

Impact

Confidentiality. The realistic case is a contractor or supplier discussing trade pricing or a referral arrangement on a thread the end customer also started. The customer receives a copy. No agent action causes it and nothing draws attention to it, so it can recur for a long time before anyone notices.

We treat this as the highest-severity issue we have found in our deployment.

Related — worth reading before triaging

There is active work in this exact function, and it is the inverse of this bug:

• getRecipients drops incoming email To recipients from the reply CC #67 / fix: include incoming email To recipients in the reply CC #68 here — getRecipients drops incoming To-line recipients from the reply CC.
• fix: carry extra To recipients into CC on email reply chatwoot#15581 — the downstream half of that fix.

Those are about recipients wrongly falling out of CC. This report is about a recipient wrongly being put into CC. They touch the same branch, so it is probably worth settling the intended rule for that branch once rather than twice — a fix for one could easily mask or worsen the other.

Environment

Self-hosted Chatwoot v4.13.0, Docker. Behaviour re-checked against the v4.17.1 tag.

Offer

We have run a server-side mitigation in production since 26 August. Happy to work up a PR here, and happy to coordinate with whoever is on #68 so the two do not collide.