I'm not aware of any versions where the standard reply contains color codes, so $strip isn't needed.
As this is, it's possible for this to have false positives and false negatives.

It can be a false positive because people can, and often do, attach their script to check for the version check then reply their own script's version along with mirc's. so this can trigger when a script sends "Bob's super-duper script which requires mIRC v7.55 or greater"

It can be a false negative because it's possible to block or change the version reply by using ON PARSELINE, but we'll not worry about that. Nor will we worry about people using /ignore -t to block all ctcp's causing them to make no reply at all.

It can also be a false negative if you want to ban versions older than a certain version. For example if you want to ban mIRC versions of v7.55 and older (or at least warn them) because they're vulnerable to the CVE fixed in v7.56

The version reply is always 2 words, so you can narrow down the flag by changing your match text to only check like:

Code
on 1:CTCPREPLY:VERSION*:{
becomes
on 1:CTCPREPLY:VERSION mIRC &:{


which triggers only if there's exactly 1 word behind the "mirc". Then instead of checking if it's equal to the last version that can be vulnerable to the exploit, check if it's less-than-or-equal:

Code
if (%banversion isin $strip($2-)) {
becomes
if ($2- <= %banversion) {


If you want to ban ONLY the specific version instead of that-version-and-all-earlier, then the <= can change to just ==

You could alternatively remove "mirc" from %banversion then check $3 instead of $2-
If you make the 2nd code change without the 1st, then this triggers in error for clients whose name is alphabetically prior to "M"