[$250] Require a magic code when provisioning a new company card

[tgolen]

Coming from a discussion in this PR.

Problem

A bad actor can work to gain control of an account from an unsuspecting user by adding the attacker's contact method as a secondary contact method during the company card provisioning flow (it's in the WorkspaceCompanyCardAddWorkEmailPage component), then setting that to the primary contact method (to receive future magic codes).

Solution

• Prompt the user for a magic code (we have this same flow in many different places in the app, so you can use those for inspiration)
• Send that code to the API for setting the new default contact method
• It's fine to assume for now that these requests will always be successful, even if an invalid code is entered. Eventually, the backend will start verifying the codes and return an error message if it isn't successful

cc @rafecolton @shubham1286agra

Issue Owner

Current Issue Owner: @shubham1206agra

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049169261097777754
• Upwork Job ID: 2049169261097777754
• Last Price Increase: 2026-05-05

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

A bad actor can silently change a user's primary contact method by exploiting the company card provisioning flow. When a user submits an already-validated email in WorkspaceCompanyCardAddWorkEmailPage or WorkspaceExpensifyCardAddWorkEmailPage, the code calls setContactMethodAsDefault() directly — bypassing the magic code verification that the Settings > Contact Methods flow normally requires.

What is the root cause of that problem?

In both card provisioning pages, the handleSubmit function has three branches:

1. Email exists in loginList AND is validated → calls setContactMethodAsDefault() immediately with no verification
2. Email exists but NOT validated → navigates to WorkspaceVerifyWorkAccountPage (which does use ValidateCodeActionContent)
3. Email doesn't exist → calls ADD_WORK_EMAIL API

Branch 1 is the vulnerability. It lets an attacker who has added and validated their email as a secondary contact method use the card provisioning flow to promote it to primary — silently, with no magic code challenge.

Vulnerable code:

• WorkspaceCompanyCardAddWorkEmailPage.tsx:73
• WorkspaceExpensifyCardAddWorkEmailPage.tsx:67

What changes do you think we should make in order to solve the problem?

Add a magic code verification step before calling setContactMethodAsDefault in both card provisioning pages. When an already-validated email is submitted (branch 1 above):

1. Instead of calling setContactMethodAsDefault() directly, navigate to a magic code verification page
2. Use requestValidateCodeAction() to send a magic code to the user's current primary login
3. Use the existing ValidateCodeActionContent component to prompt for the code
4. Only after successful code entry, call setContactMethodAsDefault() with the validated code

This follows the exact same pattern already used in:

• NewContactMethodConfirmMagicCodePage.tsx
• ConfirmDelegateMagicCodePage.tsx

As noted in the issue, the backend verification of codes can be deferred — for now the code just needs to be sent and collected from the user before proceeding.

What alternative solutions did you explore? (Optional)

Considered reusing WorkspaceVerifyWorkAccountPage (already used for unvalidated emails in the same flow), but that page is tied to the validateAccountAndMerge / getAccessiblePolicies flow rather than the setContactMethodAsDefault flow, so a separate verification step or a new verification page is cleaner.

Related issues

• Expensify/App#87935 — "Require a magic code when changing the primary account login" (currently in Reviewing). That issue addresses the same underlying problem from the Settings side. Both issues should be fixed, as they are separate code paths.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Current assignee @shubham1206agra is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022049169261097777754

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user provisions a new company card and submits a work email through WorkspaceCompanyCardAddWorkEmailPage, the app silently switches the account's primary contact method to that work email if it is already a validated secondary login on the account. No proof-of-presence is requested from the user before the primary contact method changes.

This is the path inside handleSubmit where the existing already-validated secondary login is set as default with no challenge:

App/src/pages/workspace/companyCards/WorkspaceCompanyCardAddWorkEmailPage.tsx

Lines 67 to 95 in e69882b

	if (existingLoginKey) {
	if (!isExistingLoginValidated) {
	setEmail(submittedEmail);
	Navigation.navigate(ROUTES.WORKSPACE_COMPANY_CARD_VERIFY_WORK_EMAIL.getRoute(policyID, feed));
	return;
	}
	setContactMethodAsDefault(currentUserPersonalDetails, allPolicies, existingLoginKey, formatPhoneNumber, undefined, true);
	if (!feedInfo) {
	setEmail(submittedEmail);
	return;
	}
	setLoading(true);
	const feedValue = getCardFeedWithDomainID(feedInfo.feed, feedInfo.fundID) as CompanyCardFeedWithDomainID;
	linkCardFeedToPolicy(Number(feedInfo.fundID), policyID, CONST.COMPANY_CARD.LINK_FEED_TYPE.COMPANY_CARD, feedInfo?.country, feedInfo.feed as CompanyCardFeedWithNumber)
	.then(() => {
	updateSelectedFeed(feedValue, policyID);
	Navigation.closeRHPFlow();
	})
	.catch((error: TranslationPaths) => {
	addErrorMessage({}, INPUT_IDS.EMAIL, translate(error));
	})
	.finally(() => {
	setLoading(false);
	});
	} else {
	AddWorkEmail(submittedEmail);
	}
	setEmail(submittedEmail);
	};

A bad actor who briefly gained access to the user's account can plant their own address as a validated secondary login, then later (or by social-engineering the user through the company-card flow) trigger this code path to take over the primary contact method and intercept all future magic codes.

The other two branches in this same handleSubmit are not affected by this gap:

• The "existing-but-unverified" branch routes the user to WorkspaceVerifyWorkAccountPage, which already requires a magic code via ValidateCodeActionContent.
• The "brand-new email" branch goes through AddWorkEmail, which also requires verification before promotion.

The vulnerable branch is specifically the existingLoginKey && isExistingLoginValidated case at line 73, which calls setContactMethodAsDefault(...) directly with no challenge.

What is the root cause of that problem?

setContactMethodAsDefault in src/libs/actions/User.ts writes the new primary login optimistically and fires SET_CONTACT_METHOD_AS_DEFAULT to the API without any magic code:

App/src/libs/actions/User.ts

Lines 1058 to 1222 in e69882b

	function setContactMethodAsDefault(
	currentUserPersonalDetails: OnyxEntry<OnyxPersonalDetails>,
	policies: OnyxCollection<Policy>,
	newDefaultContactMethod: string,
	formatPhoneNumber: LocaleContextProps['formatPhoneNumber'],
	backTo?: string,
	skipNavigation?: boolean,
	) {
	const oldDefaultContactMethod = currentEmail;
	const optimisticData: Array<
	OnyxUpdate<typeof ONYXKEYS.ACCOUNT | typeof ONYXKEYS.SESSION | typeof ONYXKEYS.LOGIN_LIST | typeof ONYXKEYS.PERSONAL_DETAILS_LIST | typeof ONYXKEYS.COLLECTION.POLICY>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {
	primaryLogin: newDefaultContactMethod,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.SESSION,
	value: {
	email: newDefaultContactMethod,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.LOGIN_LIST,
	value: {
	[newDefaultContactMethod]: {
	pendingFields: {
	defaultLogin: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	errorFields: {
	defaultLogin: null,
	},
	},
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_DETAILS_LIST,
	value: {
	[currentUserAccountID]: {
	login: newDefaultContactMethod,
	displayName: PersonalDetailsUtils.createDisplayName(newDefaultContactMethod, currentUserPersonalDetails, formatPhoneNumber),
	},
	},
	},
	];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.LOGIN_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.LOGIN_LIST,
	value: {
	[newDefaultContactMethod]: {
	pendingFields: {
	defaultLogin: null,
	},
	},
	},
	},
	];
	const failureData: Array<
	OnyxUpdate<typeof ONYXKEYS.ACCOUNT | typeof ONYXKEYS.SESSION | typeof ONYXKEYS.LOGIN_LIST | typeof ONYXKEYS.PERSONAL_DETAILS_LIST | typeof ONYXKEYS.COLLECTION.POLICY>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {
	primaryLogin: oldDefaultContactMethod,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.SESSION,
	value: {
	email: oldDefaultContactMethod,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.LOGIN_LIST,
	value: {
	[newDefaultContactMethod]: {
	pendingFields: {
	defaultLogin: null,
	},
	errorFields: {
	defaultLogin: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('contacts.genericFailureMessages.setDefaultContactMethod'),
	},
	},
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_DETAILS_LIST,
	value: {
	[currentUserAccountID]: {...currentUserPersonalDetails},
	},
	},
	];
	for (const policy of Object.values(policies ?? {})) {
	if (!policy) {
	continue;
	}
	let optimisticPolicyDataValue;
	let failurePolicyDataValue;
	if (policy.employeeList) {
	const currentEmployee = policy.employeeList[oldDefaultContactMethod];
	optimisticPolicyDataValue = {
	employeeList: {
	[oldDefaultContactMethod]: null,
	[newDefaultContactMethod]: currentEmployee,
	},
	};
	failurePolicyDataValue = {
	employeeList: {
	[oldDefaultContactMethod]: currentEmployee,
	[newDefaultContactMethod]: null,
	},
	};
	}
	if (policy.ownerAccountID === currentUserAccountID) {
	optimisticPolicyDataValue = {
	...optimisticPolicyDataValue,
	owner: newDefaultContactMethod,
	};
	failurePolicyDataValue = {
	...failurePolicyDataValue,
	owner: policy.owner,
	};
	}
	if (optimisticPolicyDataValue && failurePolicyDataValue) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: optimisticPolicyDataValue,
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: failurePolicyDataValue,
	});
	}
	}
	const parameters: SetContactMethodAsDefaultParams = {
	partnerUserID: newDefaultContactMethod,
	};
	API.write(WRITE_COMMANDS.SET_CONTACT_METHOD_AS_DEFAULT, parameters, {
	optimisticData,
	successData,
	failureData,
	});
	if (!skipNavigation) {
	Navigation.goBack(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo));
	}
	}

The API parameter type only carries partnerUserID, with no challenge field:

App/src/libs/API/parameters/SetContactMethodAsDefaultParams.ts

Lines 1 to 5 in e69882b

	type SetContactMethodAsDefaultParams = {
	partnerUserID: string;
	};
	export default SetContactMethodAsDefaultParams;

So at every call site (the company card flow, and also ContactMethodDetailsPage.setAsDefault) the action can be invoked with no proof that the legitimate primary user is the one initiating it. The reported issue lives in the company-card flow because that is the path tgolen flagged in the linked PR discussion, but the root cause is that the action itself never asks for a magic code on the current primary contact method.

What changes do you think we should make in order to solve the problem?

The fix is to insert a magic-code challenge step between "user submits a work email that already exists and is validated" and the actual setContactMethodAsDefault call. The code is sent to the user's current primary contact method (so an attacker who only controls a secondary cannot intercept it). This mirrors the same pattern Expensify already uses in ReportCardLostConfirmMagicCodePage, ExpensifyCardVerifyAccountPage, IssueNewCardConfirmMagicCodePage, and UpdateDelegateMagicCodePage — all of which gate sensitive account actions behind ValidateCodeActionContent + requestValidateCodeAction().

1. Add a new validateCode parameter to the API call.

In src/libs/API/parameters/SetContactMethodAsDefaultParams.ts, add validateCode?: string so the action can forward the magic code to the backend. The backend will start enforcing this once it ships; until then it can ignore the field, as the issue text confirms. Make it optional so existing call sites (e.g. ContactMethodDetailsPage.setAsDefault, which is out of scope for this issue but uses the same action) compile without behavior change.

2. Update setContactMethodAsDefault to forward the code.

In src/libs/actions/User.ts, add an optional validateCode argument to setContactMethodAsDefault and include it in the parameters object passed to API.write:

App/src/libs/actions/User.ts

Lines 1210 to 1218 in e69882b

	const parameters: SetContactMethodAsDefaultParams = {
	partnerUserID: newDefaultContactMethod,
	};
	API.write(WRITE_COMMANDS.SET_CONTACT_METHOD_AS_DEFAULT, parameters, {
	optimisticData,
	successData,
	failureData,
	});

3. Add a new "confirm magic code" page in the company-card flow.

Create src/pages/workspace/companyCards/WorkspaceCompanyCardConfirmMagicCodePage.tsx. It receives policyID, feed, and the target work email as route params, renders ValidateCodeActionContent (the same component used by the existing magic-code pages listed above), and:

• Calls requestValidateCodeAction() from @libs/actions/User for sendValidateCode, which sends the magic code to the current primary contact method (proves the legitimate user is present, not an attacker who only controls the new email).
• On submit, calls setContactMethodAsDefault(currentUserPersonalDetails, allPolicies, targetEmail, formatPhoneNumber, undefined, true, validateCode), then runs the same linkCardFeedToPolicy → updateSelectedFeed → Navigation.closeRHPFlow() continuation that the original page does today (the post-promotion behavior must remain identical).
• Reads ONYXKEYS.VALIDATE_ACTION_CODE for isLoading / errors to drive the form state, mirroring ReportCardLostConfirmMagicCodePage.
• On close (onClose), calls resetValidateActionCodeSent() and navigates back to the add-work-email page so the user can retry or cancel cleanly.

4. Wire up the route + screen.

Add COMPANY_CARD_CONFIRM_MAGIC_CODE to src/SCREENS.ts next to the existing COMPANY_CARD_ADD_WORK_EMAIL / COMPANY_CARD_VERIFY_WORK_EMAIL entries, add WORKSPACE_COMPANY_CARD_CONFIRM_MAGIC_CODE to src/ROUTES.ts with policyID + feed params, and register it in the SettingsModalNavigator alongside the other two company-card pages.

5. Replace the silent direct call with navigation to the new page.

In WorkspaceCompanyCardAddWorkEmailPage.handleSubmit, change the existingLoginKey && isExistingLoginValidated branch (currently lines 67-90) so that instead of calling setContactMethodAsDefault(...) directly, it:

• Calls requestValidateCodeAction() to send the magic code to the current primary email.
• Navigates to ROUTES.WORKSPACE_COMPANY_CARD_CONFIRM_MAGIC_CODE.getRoute(policyID, feed, existingLoginKey).

The other two branches (unverified existing login → existing verify-work-email page; new email → AddWorkEmail) are already gated and stay unchanged.

6. Translations.

Add a small set of translation keys (title, description with the masked primary login, error message) under workspace.companyCards.* in src/languages/en.ts and src/languages/es.ts, in line with the existing strings used by WorkspaceVerifyWorkAccountPage.

After this change, the only way to flip the primary contact method through the company-card flow is to enter a code that was sent to the current primary contact method — closing the takeover path tgolen flagged in #88345.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/89121-companycard-magic-code-challenge?expand=1

What alternative solutions did you explore? (Optional)

• Reuse the existing WorkspaceVerifyWorkAccountPage route instead of adding a new page. Rejected: that page validates the new secondary email by calling getAccessiblePolicies(validateCode), so the code is sent to the email being added. That is the wrong target for this threat model — we need to challenge the current primary login, not the candidate. Mixing the two flows in one component would also tangle two different API write commands and two different success continuations.

• Add the magic-code challenge inside setContactMethodAsDefault itself (e.g. open a modal before the API.write). Rejected: action-layer functions in this codebase do not own UI; they are pure side-effect dispatchers, and inserting navigation/modal logic there would break the action-layer contract and break the other call site in ContactMethodDetailsPage. Keeping the prompt at the page/route layer matches every other magic-code-gated action in the app.

• Inline ValidateCodeActionForm directly inside WorkspaceCompanyCardAddWorkEmailPage (no new route). Rejected: the page currently renders a FormProvider keyed on ADD_WORK_EMAIL_FORM, and grafting a second form on top of the same screen creates conflicting submit handlers and confused back-button behavior. A dedicated route is what every other magic-code-gated flow in the app does (delegates, lost card, new card, verify account) and keeps the navigation stack predictable.

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.