technical perspective, ignoring business perspective: resolving the bugs by writing tests is excellent advice, especially once a component is sufficiently complex. get regression tests in place first, so you can sense how may new unknown defects a "fix" for a known defect is introducing. Michael Feathers' book "Working Effectively with Legacy Code" describes one approach.
somewhat political perspective: if the org doesn't value testing or software quality, wait until there's obviously a business need to lift quality. E.g. the CTO is saying things such as "constant defects in component X are destroying most of the value of our product", users complain that the Y feature keeps getting broken in successive releases, customers refuse to renew subscriptions or upgrade to a new version until Y feature works reliably. Then propose the plan to improve QA by setting up an automated regression test suite, to allow refactor-to-test of the offending code to happen in a controlled, low risk way.
somewhat political perspective: if the org doesn't value testing or software quality, wait until there's obviously a business need to lift quality. E.g. the CTO is saying things such as "constant defects in component X are destroying most of the value of our product", users complain that the Y feature keeps getting broken in successive releases, customers refuse to renew subscriptions or upgrade to a new version until Y feature works reliably. Then propose the plan to improve QA by setting up an automated regression test suite, to allow refactor-to-test of the offending code to happen in a controlled, low risk way.