[MantisClone]

Problem

Request actions could add new payment-network or content extensions to an existing request without requiring the payee’s signature.

An attacker could exploit this to supply missing payment instructions or content. Applications reading the request could then use that attacker-supplied information.

References REQ-902.

Attack scope

• The attacker would need to add a signed action to the request’s history. The SDK could accept an action signed by an unrelated wallet; the payee’s private key was not required.
• The SDK’s built-in payment helpers select the first payment-network extension. Adding another extension does not replace that selected network or its payment address. Applications that choose or override payment details themselves may behave differently.
• Existing extensions could not be overwritten by creating them again. Existing permissions for updating extensions still applied.
• Adding an extension did not itself transfer funds or change completed payments.

Proposed Solution

• Require the payee’s signature when adding an extension after request creation.
• Make meta payment-network updates explicitly reject extension creation actions.
• Add regression tests for these restrictions, including rebuilding requests from signed actions.

Design Rationale

Start with a strict payee-only rule. This excludes the payer and the payee’s delegates from adding extensions after creation. Delegate support can be considered separately.

Considerations

• The payee can still add extensions after request creation.
• The payer can still include extensions when creating a request.
• Permissions for updating existing extensions are unchanged.
• The fix is available in SDK 0.66.0: @requestnetwork/[email protected], with @requestnetwork/[email protected] and @requestnetwork/[email protected].
• Applications must upgrade their SDK dependencies to these versions or a later release containing the fix to enforce the new checks. These checks also apply to existing requests when the updated SDK rebuilds their state.
• Request actions could already include new extensions. If the new check rejects an extension during reconstruction, the whole action is ignored. For example, an old ACCEPT containing that extension can leave the request unaccepted.

UAT

Using local test requests and separate payer and payee identities:

1. Confirm the payer can include extensions when creating a request.
2. Confirm only the payee can add new extensions afterward.
3. Rebuild a request whose history contains a payer-signed ACCEPT that adds an extension. Confirm the extension is absent and the request remains unaccepted.
4. Add a normal payer-signed ACCEPT and rebuild again. Confirm the request becomes accepted.

Local tests cover these behaviors, including a signed-action regression that fails without the fix.

[MantisClone]

• fix: require payee signature for extensions added after request creation #1778 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; the previous dependency finding is fixed and no new actionable issues were found.

Summary

The PR limits new extensions after request creation to the payee and blocks nested payment-network creation through update actions.

• New extensions added after request creation need the payee's signature.
• Meta payment networks reject sub-network creation through a nested action.

_{Reviews (2) · Last reviewed commit: "chore: declare request logic test depend..." · Reviewed by Greptile}