I suppose it implies the existence of a class of potential problems if an application (1) accepts user input for timer delays, (2) requires a certain minimum delay, (3) only checks that the entered amount is >= the minimum without considering overflow behavior. But, since this behavior is well-documented (the MDN page on setTimeout covers it), it doesn't seem like any kind of notable discovery.
1) bypassing some timer in an API service requires the API to accept the string „Infinity“ and convert it to the JavaScript value Infinity - which is highly unlikely. Instead, the value would just fail the numeric validation.
2) bypassing some timer in client-side code by injecting Infinity seems overly complex - if you alter client-side code you might aswell just remove the validation instead of abusing edge cases of the language runtime.
Yeah, a more realistic bypass would be entering “3000000000”, which would trigger the same behavior.
Number(Infinity) -> Infinity
Infinity < 5000 -> will return false even though Infinity is acting as a 0 here
Because it's a relatively unknown side effect, most validations probably wouldn't check for Infinity.
Plus although Infinity pops off the timer at 0 seconds, a validation based on millisecond math would fail because Infinity > 25 minutes in milliseconds.
