chore: bump @metamask/phishing-controller to 17.3.1

[adonesky1]

Description

Bumps @metamask/phishing-controller from ^17.3.0 to ^17.3.1 to pick up the address-poisoning fix from MetaMask/core#9699.

Before that fix, the known-recipients list used to detect address poisoning took txParams.to from confirmed transactions. For ERC-20/721/1155 transfers txParams.to is the token contract, not the address receiving the tokens, so two things were wrong:

• a lookalike of the real token recipient did not trigger address-poisoning detection
• a lookalike of the token contract address did trigger it, which is meaningless noise

17.3.1 decodes the actual recipient from calldata via the new getEffectiveRecipient utility, so token transfers now contribute the real recipient. Plain sends and other contract interactions are unchanged.

Why @metamask/transaction-controller moves to 69.4.0

phishing-controller@17.3.1 declares @metamask/transaction-controller: ^69.4.0, because getEffectiveRecipient is exported from 69.4.0.

This repo pins @metamask/transaction-controller to an exact version in resolutions, which collapses every range in the tree onto that one version. That pin has to move as well — leaving it at 69.3.0 would silently resolve phishing-controller@17.3.1 against 69.3.0, where getEffectiveRecipient exists only as an internal helper inside first-time-interaction and is not exported from the package entry point. The import would be undefined and would throw on every confirmed transaction. So this PR moves the resolutions pin and the declared range together, and the lockfile still has exactly one transaction-controller entry.

Two notes for reviewers on the dependency graph:

• network-controller is unaffected. transaction-controller@69.4.0 declares network-controller: ^35.0.0, but this repo's resolutions pin holds it at 34.0.0 and the lockfile still has exactly one 34.0.0 entry. That pin is safe here: the published 69.3.0 and 69.4.0 bundles are byte-identical apart from the getEffectiveRecipient export, an optional strategy?: string field on MetamaskPayMetadata, and the moved helper file. No compiled module in 69.4.0 references network-controller, NetworkClient, BuiltInNetworkClientId, or analyticsOptions, so its ^35.0.0 range is just the mechanical release-wide bump from Release/1163.0.0 core#9735 rather than an adoption of v35 APIs. accounts-controller is likewise held at 39.0.3 by its existing pin.
• remote-feature-flag-controller@5.0.0 is added next to the existing 4.2.2. These can't be deduped, since ^4.2.x cannot accept 5.0.0. transaction-controller@69.4.0 only references it from type declarations (dist/TransactionController.d.cts) and never from runtime JS, so nothing new gets pulled into the bundle. Happy to add a resolutions pin instead if the team would rather avoid the duplicate entry.

A scoped yarn dedupe collapses the core-backend, gas-fee-controller, and polling-controller ranges that 69.4.0 nudges forward, so those don't gain parallel copies either.

Changelog

CHANGELOG entry: Fixed address-poisoning detection so lookalikes of the actual recipient of a token transfer are flagged, and lookalikes of the token contract address are no longer flagged.

Related issues

Fixes:

• Consumes MetaMask/core#9699
• Released in MetaMask/core#9746 (@metamask/phishing-controller@17.3.1)

Manual testing steps

Feature: address-poisoning detection for token transfer recipients

Scenario: user is warned about a lookalike of a real token recipient
Given the user has previously sent an ERC-20 token to an address and that transaction is confirmed

When user starts a new transfer of that token and enters a recipient that matches the previous recipient's first four and last four hex characters but differs in the middle
Then the address-poisoning warning is shown

Scenario: user is not warned about a lookalike of the token contract
Given the user has previously sent an ERC-20 token and that transaction is confirmed

When user enters a recipient that is a lookalike of the token contract address
Then no address-poisoning warning is shown, because the contract is no longer treated as a known recipient

Scenario: plain sends and contract interactions are unchanged
Given the user has a confirmed plain ETH transfer and a confirmed generic contract interaction

When user enters a lookalike of either of those recipients
Then the address-poisoning warning is still shown

Screenshots/Recordings

Before

A lookalike of the real ERC-20 recipient produced no warning, while a lookalike of the token contract produced one.

After

A lookalike of the real ERC-20 recipient produces a warning; a lookalike of the token contract does not.

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

---

Note

Medium Risk
Touches security-sensitive address-poisoning logic and requires the transaction-controller pin to match; runtime impact is limited to dependency behavior, but incorrect resolution would break confirmed-tx handling.

Overview
Bumps @metamask/phishing-controller from ^17.3.0 to ^17.3.1 so address-poisoning detection uses the real token transfer recipient (via getEffectiveRecipient) instead of txParams.to, which for ERC-20/721/1155 is the token contract. Lookalikes of the actual recipient should warn; lookalikes of the contract should not.

Because 17.3.1 depends on an exported getEffectiveRecipient from @metamask/transaction-controller, this PR also moves the resolutions pin and dependency from 69.3.0 to 69.4.0 and refreshes yarn.lock (including transitive bumps such as remote-feature-flag-controller@5.0.0 alongside the existing 4.2.2). No application source files change—behavior comes from the upgraded packages.

^{Reviewed by Cursor Bugbot for commit 6155857. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[metamask-ci]

PR template — items to address before "Ready for review"

Warnings — informational, address before merging:

• Related issues section is empty. Add Fixes: #123 / Closes: <URL> / Refs: <Jira key>, or write a short rationale after the colon.
• Pre-merge author checklist has only 5 of the required 8 items. Every checklist row must be present and consciously checked — do not delete rows.

See docs/readme/ready-for-review.md for the full Definition of Ready for Review.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​metamask/​phishing-controller@​17.3.0 ⏵ 17.3.1				+1
	npm/​@​metamask/​transaction-controller@​69.3.0 ⏵ 69.4.0	+1		+1	+1

View full report

[socket-security]

Warning

MetaMask internal reviewing guidelines:

• Do not ignore-all
• Each alert has instructions on how to review if you don't know what it means. If lost, ask your Security Liaison or the supply-chain group
• Copy-paste ignore lines for specific packages or a group of one kind with a note on what research you did to deem it safe.
  @SocketSecurity ignore npm/PACKAGE@VERSION

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Potential code anomaly (AI signal): npm @metamask/transaction-controller is 75.0% likely to have a medium risk anomaly Notes: The code performs straightforward signature verification using ethers.js, returning true when the recovered signer matches the provided publicKey. While generally safe, the silent catch and potential mismatch between data formatting and signing process should be addressed to avoid silent failures. Overall, a benign utility with moderate input-format sensitivity. Confidence: 0.75 Severity: 0.50 From: package.json → npm/@metamask/transaction-controller@69.4.0 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@metamask/transaction-controller@69.4.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeAccounts, SmokeConfirmations, SmokeNetworkAbstractions, SmokeNetworkExpansion, SmokeSwap, SmokeStake, SmokeWalletPlatform, SmokeMoney, SmokePerps, SmokeMultiChainAPI, SmokePredictions, SmokeSeedlessOnboarding, SmokeBrowser, SmokeSnaps, SmokeMMConnect
• Selected Performance tags: @PerformanceSwaps, @PerformanceAssetLoading, @PerformanceLogin, @PerformanceLaunch
• Risk Level: high
• AI Confidence: 100%

click to see 🤖 AI reasoning details

E2E Test Selection:
Hard rule (controller-version-update): @MetaMask controller package version updated in package.json: @metamask/transaction-controller, @metamask/phishing-controller. Running all tests.

Performance Test Selection:
The transaction-controller bump (with network-controller minor and remote-feature-flag-controller major bumps) could affect performance in several areas: (1) @PerformanceSwaps - TransactionController is core to swap execution, any latency changes in transaction processing would show here; (2) @PerformanceAssetLoading - NetworkController changes could affect how quickly assets/balances load across networks; (3) @PerformanceLogin - RemoteFeatureFlagController major bump (^4→^5) is initialized in Phase 1 and could affect app startup/unlock time; (4) @PerformanceLaunch - RemoteFeatureFlagController is initialized early in the app lifecycle, a major version bump could affect cold start performance.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

⚠️ Performance Test Results

ℹ️ Performance test results are currently non-blocking and will not block this PR.

❌ 1 test failed · 5 tests · 1 device

📱 Devices tested (1)

Android: Google Pixel 8 Pro (v14.0)

❌ Failed Tests (1)

@metamask-mobile-platform

Measure Cold Start To Onboarding Screen

Platform	Device	Reason	Recording
Android	Google Pixel 8 Pro (v14.0)	Test error	📹 Watch

✅ Passed Tests (4)

Test	Platform	Device	Duration	Team	Recording
Asset View, SRP 1 + SRP 2 + SRP 3	Android	Google Pixel 8 Pro (v14.0)	4.65s	@assets-dev-team	📹 Watch
Cold Start: Measure ColdStart To Login Screen	Android	Google Pixel 8 Pro (v14.0)	4.45s	@metamask-mobile-platform	📹 Watch
Measure Warm Start: Warm Start to Login Screen	Android	Google Pixel 8 Pro (v14.0)	0.69s	@metamask-mobile-platform	📹 Watch
Measure Warm Start: Login To Wallet Screen	Android	Google Pixel 8 Pro (v14.0)	2.39s	@metamask-mobile-platform	📹 Watch

---

Branch: bump/phishing-controller-17.3.1 · Build: E2E · Commit: a07ab25 · View full run