Bug report: AES-CTR does not appear to work correctly in CyberChef when the algorithm counter rollover occurs.

[CreativeGenious]

Describe the bug
When attempting to rollover the counter for AES in CTR mode, the CyberChef output is different from Open-SSL and Crypto++.

To Reproduce
Steps to reproduce the behaviour or a link to the recipe / input used to cause the bug:

In CyberChef, set up for AES Encrypt: https://gchq.github.io/CyberChef/#recipe=AES_Encrypt(%7B'option':'Hex','string':'000102030405060708090a0b0c0d0e0f'%7D,%7B'option':'Hex','string':'ffffffffffffffffffffffffffffffff'%7D,'CTR','Hex','Hex',%7B'option':'Hex','string':''%7D)&input=ODg5OWFhYmJjY2RkZWVmZjAwMTEyMjMzNDQ1NTY2NzdmZQ

Use the following inputs:
Key (128-bit): 000102030405060708090a0b0c0d0e0f
IV (128-bit): ffffffffffffffffffffffffffffffff
Plain Text: 8899aabbccddeeff0011223344556677fe

CyberChef result: b4ddb58902da6cdc64c680aa4a05dd6401

Expected behaviour
I expected the Crypto++/Open-SSL result in CyberChef: B4DDB58902DA6CDC64C680AA4A05DD6438

Screenshots

Desktop (if relevant, please complete the following information):

• OS: Windows 11
• Browser: Microsoft Edge, Version 123.0.2420.97 (Official build) (64-bit)
• CyberChef version: 10.17.0

Additional context
This was tested against two other models (one for a HW implementation). Both models agree with Crypto++ and Open-SSL