1. 🟡 TypeError DoS in findByUserId via non-string conversationType .toLowerCase() call (FS store)

Description

findByUserId attempts to prefer a personal conversation by calling .toLowerCase() on conversationType.

• conversationType is loaded from the persisted JSON state file (msteams-conversations.json).
• The code uses optional chaining on the value (conversationType?.toLowerCase()), which only guards against null/undefined.
• If a corrupted/tampered state file (or otherwise untrusted data) sets conversationType to a non-string (e.g., object/number), the expression will attempt to call an undefined toLowerCase function and throw a TypeError.
• The exception is not caught in findByUserId, so it can crash the request/turn and cause a denial of service.

Vulnerable code:

const personal = matches.find(
  (m) => m.reference.conversation?.conversationType?.toLowerCase() === "personal",
);

Recommendation

Harden the check to only call .toLowerCase() on strings.

const ct = m.reference.conversation?.conversationType;
return typeof ct === "string" && ct.toLowerCase() === "personal";

Alternatively, use optional-call chaining on the method, but still ensure the value is a string if the semantics matter:

const ct = m.reference.conversation?.conversationType;
return ct?.toLowerCase?.() === "personal";

(Prefer the typeof ct === "string" guard to avoid treating objects with a custom toLowerCase as valid.)

2. 🟡 TypeError DoS in findByUserId via non-string conversationType .toLowerCase() call (memory store)

Description

findByUserId in the in-memory conversation store attempts to pick a personal conversation by calling .toLowerCase() on conversationType.

• Optional chaining (conversationType?.toLowerCase()) only prevents calls when conversationType is null/undefined.
• If a stored reference contains a non-string conversationType (e.g., object/number from malformed/untrusted activity payload or internal corruption), the .toLowerCase() property access/call will throw a TypeError.
• The exception is not caught in findByUserId, potentially crashing the handler/turn and causing denial of service.

Vulnerable code:

matches.find(
  (m) => m.reference.conversation?.conversationType?.toLowerCase() === "personal",
)

Recommendation

Guard the type before calling .toLowerCase().

const ct = m.reference.conversation?.conversationType;
return typeof ct === "string" && ct.toLowerCase() === "personal";

If you prefer a shorter form, use optional-call chaining but be aware it allows objects with a toLowerCase function:

const ct = m.reference.conversation?.conversationType;
return ct?.toLowerCase?.() === "personal";

3. 🟡 Conversation reference lookup not scoped by tenant, enabling cross-tenant proactive message misrouting

Description

findByUserId() selects a stored conversation reference solely by matching reference.user.aadObjectId or reference.user.id.

• Stored entries include reference.conversation.tenantId, but it is not used during lookup.
• If the bot is installed in multiple tenants (or stores entries across environments), a collision or reuse of user identifiers across tenants can cause the wrong conversation reference to be returned.
• The new selection logic (prefer conversationType: "personal") increases the chance of deterministically choosing the wrong tenant’s personal chat when multiple matches exist, leading to proactive messages being sent to an unintended recipient (data exposure / conversation hijack).

Vulnerable code:

if (reference.user?.aadObjectId === target || reference.user?.id === target) {
  matches.push(entry);
}
...
const personal = matches.find(
  (m) => m.reference.conversation?.conversationType?.toLowerCase() === "personal",
);

Recommendation

Scope conversation reference storage and lookup by tenant (and ideally by bot/app installation).

Option A (recommended): store keyed by tenantId + user id

• Require callers of findByUserId to pass tenantId.
• Filter matches by reference.conversation.tenantId.

Example:

async function findByUser(params: { tenantId: string; userId: string }) {
  const target = params.userId.trim();
  const tenantId = params.tenantId;
  const matches = (await list()).filter((e) =>
    (e.reference.user?.aadObjectId === target || e.reference.user?.id === target) &&
    e.reference.conversation?.tenantId === tenantId,
  );
  ​// then apply personal/lastSeen selection within the tenant
}

Option B: maintain separate stores per tenant (separate file per tenant) so collisions cannot occur.

Also consider verifying that proactive send flows always provide tenant context (from config/recipient) so lookups cannot accidentally cross tenants.