function confirm() {
$("#confirm-btn").click()
}
setInterval(confirm, 0)
This glitch also occurs with audios, hats, hairs, decals, meshes, models, shirts, t-shirts, and a bunch of other accessories.
This works on the international fedoras, but if a new limited comes out during initial sale, and this method is used imagine how big of an issue this could really be.
There is a youtuber by the name of “SharkBlox” recording himself doing this glitch and showing it off: https://www.youtube.com/watch?v=lx9HgEJBoHA
THIS DOES NOT WORK WITH LIMITEDS
Decided, to reproduce this and can confirm that this works. There must not be a proper cooldown on the endpoint.
function confirm() {
$("#confirm-btn").click()
}
setInterval(confirm, 0)
P.S. The “setInterval” function is not what determines the amount of items, the 0 just states that the function “confirm” should fire as many times as possible. It just so happens that it fires the endpoint five times before it recognises that you have the item already.
These issues should normally be reported via Exploit_Reports FYI. I happen to know someone already sent this one through to that inbox a week or so ago since it came through post approval. Though since the repro steps already seem to be widely known, I guess it doesn’t matter anymore to keep this one private.
I can reproduce this issue with all types of assets (including hats, hairs, decals, meshes, models, shirts, and t-shirts). Moreover, there appears to be some type of rate limitings between different requests.
It also seems to charge the user for the purchases
Tested, it works. Hopefully this gets fixed, I imagine that it could be bad if it was used on limiteds during initial sale.
Weird, it didn’t charge me extra for the four hacker fedoras, it just took 50 robux out of my balance.
In that case, that’s very serious and can be abused with limiteds.
Thanks!
Also, back to the topic, I made a video showing you that it still exists, and the magnitude of it: https://www.youtube.com/watch?v=CuuPoEAmaYA
