So let's look at ESLint's list of rules: https://eslint.org/docs/latest/rules/ Here are some examples:
* getter-return: Enforce `return` statements in getters
* no-constant-condition: Disallow constant expressions in conditions
* no-fallthrough: Disallow fallthrough of `case` statements
* no-irregular-whitespace: Disallow irregular whitespace
You might find real bugs with these linting rules, sure. But if I want to prioritize finding and fixing security defects, I'll prioritize fixing the security defects found by a tool designed to find the most likely kinds of security defects (e.g., look for XSS, SQL injection, etc.). Not these rules. You can have code that violates many ESLint rules and still works correctly for end-users.
That doesn't mean linters are useless. Quite the contrary, I think linters are really helpful & I strongly encourage their use. Fixing issues found by linters can not only fix real bugs, but they can sometimes encourage creation of simpler code that is easier to analyze by both humans and machines. But I wouldn't prioritize updating a linter over updating other tools and fixes. Yes, update linters, but when you have limited resources, that's not where you spend your first hour.
I think there's a lot of legitimate debate about autoformatters, that's a different topic.