Not sure if this is a vulnerability per se, but in lines 108 - 115, it is very easy to bypass the order_seqno check. The user can just input order_seqno=MAX_ORDER_SEQNO, and it'll skip the checks even if allow_arbitrary_order_seqno is set to false.
int order_seqno = in_msg_body~load_order_seqno();
if (~ allow_arbitrary_order_seqno) {
if (order_seqno == MAX_ORDER_SEQNO) {
order_seqno = next_order_seqno;
} else {
throw_unless(error::invalid_new_order, (order_seqno == next_order_seqno));
}
next_order_seqno += 1;
}
I think that's intended (I'd call such functionality "seqno autofill"). Though, if developers intended this in some other way, next_order_seqno should get checked.
Not sure if this is a vulnerability per se, but in lines 108 - 115, it is very easy to bypass the order_seqno check. The user can just input
order_seqno=MAX_ORDER_SEQNO
, and it'll skip the checks even ifallow_arbitrary_order_seqno
is set to false.Telegram: https://t.me/aadeux Wallet: UQAGRkodDhxfzq76kxqlw2DdO0aejUP_F_U9nfErnJMfWkHF