security(high): authorize/charge use transferWithAuthorization — front-runnable, buyer funds permanently lost

[pviti]

Severity: High. From the 2026-07-29 cross-repo audit (functional/security/perf/style pass).

authorize (contracts/src/RAIL0.sol:275) and charge (:304) pull the buyer's funds with transferWithAuthorization:

IEIP3009(p.token).transferWithAuthorization(
    p.payer, address(this), p.amount, 0, p.authorizationExpiry,
    _authorizeNonce(paymentId, configHash), v, r, s
);

EIP-3009's transferWithAuthorization has no msg.sender restriction — receiveWithAuthorization exists in the EIP precisely to prevent third-party submission, and refund (:474) already uses it.

Failure scenario: the merchant broadcasts authorize; any mempool observer lifts (v, r, s) plus the deterministic nonce from the pending tx and calls token.transferWithAuthorization(payer, RAIL0, amount, 0, expiry, nonce, v, r, s) directly with a higher tip. The token moves amount from the buyer to the RAIL0 address and marks the nonce used forever; the merchant's authorize then reverts token-side, so no PaymentState is ever created. There is no sweep/rescue function and every payout path pays out only against a live _state[paymentId], so the balance is unrecoverable — pure griefing, the buyer loses the full amount, attacker cost is gas. Same applies to charge.

Suggested fix: switch both call sites to receiveWithAuthorization (the buyer signs the identical TransferWithAuthorization digest; to == msg.sender == RAIL0 then holds). Fund-moving change → version bump + full coordinated rollout (one version across all active chains). The README security model (README.md:288-300) should also mention mempool front-running explicitly.

[pviti]

Analysis: the fix is valid, but its scope is larger than this issue states

Two questions came up while reviewing the proposed fix. Both are now settled empirically, and the second one corrects the "Suggested fix" section above.

1. Does receiveWithAuthorization's to == msg.sender check hold here? — Yes

The doubt: authorize/charge are submitted by the merchant, and the funds ultimately land on the merchant (charge) or the buyer (refund), so the caller looks different from refund's.

It isn't. The confusion is between two distinct notions of "sender":

• from — the signer, whose balance is debited. Payer in authorize/charge, payee in refund. This does differ, but receiveWithAuthorization places no constraint on from — it is recovered via ecrecover from the signature and may be any third party.
• msg.sender as seen by the token — whoever presents the call. That is RAIL0 in all three cases, because RAIL0 makes the call. The merchant is tx.origin.

The reason to is always RAIL0 is that EIP-3009 only ever covers the inbound leg. The outbound leg is a plain ERC-20 transfer:

	inbound (EIP-3009)	outbound (plain transfer)
charge (:304)	payer → RAIL0, to = address(this)	_safeTransfer(token, p.payee, p.amount)
refund (:474)	payee → RAIL0, to = address(this)	_safeTransfer(token, p.payer, amount)

The signature never describes the full path — only "debit me and send it to RAIL0". The final recipient is not part of the signed data.

All three entry points are also identical at the EOA level: authorize (:260), charge (:297) and refund (:450) each revert NotPayee unless msg.sender == p.payee.

Evidence. A fork test on Base Sepolia against the deployed USDC (0x036CbD53842c5426634e7929541eC2318f3dCF7e), with a stand-in escrow contract, in exactly the disputed configuration — submitting EOA 0xBEEF (signed nothing), from = an unrelated payer who signed a ReceiveWithAuthorization, to = the escrow contract — passes: 500 USDC leave the payer and land on the escrow. receiveWithAuthorization pulls from a third party when a contract presents it, regardless of which EOA sent the transaction.

Separately, patching both call sites in RAIL0.sol to receiveWithAuthorization and running the suite gives 114 passed / 1 failed, and the single failure is test_Reentrancy_GuardBlocksInnerCall — MockReentrant implements only transferWithAuthorization, so the call lands on a non-existent function. A mock artifact, not a regression.

2. The two functions do NOT share a digest — this corrects the suggested fix

The issue implies the buyer keeps signing the same typed data. That is wrong. EIP-3009 defines two distinct typehashes, confirmed by reading the live token:

TRANSFER_WITH_AUTHORIZATION_TYPEHASH: 0x7c7c6cdb67a18743f49ec6fa9b35f50d52ed05cbed4cc592e13b44501c1a2267
RECEIVE_WITH_AUTHORIZATION_TYPEHASH:  0xd099cc98ef71107a616c4f0f941f04c322d8e254fe26b3c6668db87aae413de8

which match keccak256("TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)") and keccak256("ReceiveWithAuthorization(…)") respectively.

So the fix is not a one-word substitution in the contract. The buyer must sign ReceiveWithAuthorization, which changes the EIP-712 primaryType in every off-chain signer — gateway, CLI, admin and the SDKs — on top of the contract redeploy, version bump and coordinated multi-chain rollout already noted.

Worth knowing: test/RAIL0.t.sol:85,116 uses TRANSFER_WITH_AUTHORIZATION_TYPEHASH for both mock functions, so the current suite cannot detect this difference at all. Whatever shape the fix takes, the mock needs the two typehashes separated first, otherwise the tests will pass on an off-chain-incompatible implementation.

3. Probable root cause — a wrong doc comment

src/interfaces/IERC20.sol:21-28 states:

• transferWithAuthorization — called by the payer (sender) for authorize/charge.
[…] Both functions require the same EIP-712 TransferWithAuthorization typed-data signature — the only difference is who submits the transaction.

Both claims are incorrect: the caller is RAIL0, not the payer, and the typed data differs. This is very likely why the code was written this way, and it should be corrected regardless of when the fix itself ships.

Status

Issue stays open. Nothing implemented — this touches a funds path on six live deployments, so it is a deliberate, coordinated rollout, not an incremental fix.