There’re a couple of things worth mentioning in relation to this situation. The behavior you describe is part of anomaly detection, in particular, the breached password detection. You can disable this functionality through your dashboard (IIRC, by default it starts as disabled for a new tenant/domain) which should then eliminate the source of the error message in question.
In addition, when using Lock, you can fully customize the text displayed by the library so in this case you could provide a custom error message by doing something similar to the following:
options.languageDictionary.error.login.password_leaked = "[your_custom_msg_with_context_here]";
Finally, it’s correct that the source of the issue not related to your client application, however, the end-user is performing authentication with credentials that are available online for someone sufficiently determined to find which means that the account that end-user has in your own client application can be controlled by attackers. In this scenario, even if the source of the issue is not your client application I would say the end-users would be more comfortable in knowing you prevented such an attack.