What

isFloat validates the format of a number against the locale's decimal
separator (decimal[options.locale]), but the numeric value used for the
min / max / lt / gt range checks was parsed with a hardcoded comma
replacement:

const value = parseFloat(str.replace(',', '.'));

That only normalizes . and ,. For locales whose separator is neither of
those, the replace is a no-op, so parseFloat stops at the separator and
silently drops the fractional part.

The Arabic locale (ar) and the Farsi locales (fa-IR, fa-AF) use ٫
(U+066B, Arabic decimal separator). So parseFloat('3٫14'.replace(',', '.'))
returns 3, not 3.14, and every range comparison for those locales is
wrong — in both directions.

Reproduction (against the published validator)

const validator = require('validator');
const ar = '٫'; // U+066B

// 3.14 is within [3.1, 4] — should be true
validator.isFloat('3٫14', { locale: 'ar', min: 3.1, max: 4 }); // => false  (false negative)

// 9.99 exceeds max 9 — should be false
validator.isFloat('9٫99', { locale: 'ar', max: 9 });           // => true   (false positive)

The false-positive case is the concerning one: a max used to enforce a
limit silently accepts out-of-range input for these locales.

Fix

Replace the locale's actual decimal separator before parsing:

const decimalSeparator = options.locale ? decimal[options.locale] : '.';
const value = parseFloat(str.replace(decimalSeparator, '.'));

Comma locales (de-DE, fr-FR, …) and the default . behavior are
unchanged; format validation is untouched.

Tests

Added an isFloat case for the ar locale with min/max bounds in
test/validators.test.js. It fails on the old code (the existing locale
tests only covered format validation, not range checks) and passes with the
fix. Full validators suite passes (249 passing).