Responsible disclosure of vulnerabilities where author probably doesn't have the ability to address the issues

I was recently evaluating a software to use for our organization. I had a look at the code (PHP) and it it is littered with vulnerabilities. I was able to do a XSS POC within 10 mins of looking at the code. Within an hour I found a dozen of XSS and SQL injection vulnerabilities. I informed the author a week ago. After initially refuting the issue the author stopped responding. There have been no updates to the software since.

The thing is the code looks like straight from the 90s. MySQL/PHP in HTML, $_GET straight embedded in the template, $_GET straight embedded in SQL queries, tons of duplication, ... It's a total mess. As far as I can tell it has been around in this state for a decade. The only way to fix this would be to completely rewrite the system (~45k lines of code). The system is widely used (forum has 1000s of posts/ product is one of the top search results for the use case). The system is used to manage sensitive customer information.

The question is what would be a recommended approach to disclose/approach this. Looking at the code I don't think the author has the ability to rewrite the system in a secure manner. The system has been around for a long time and by the looks of it there are no exploits in he wild (there was one CVE a few years ago with exploits but the particular issue has been fixed since). I don't have the time/expertise to support someone to rewrite their commercial product. Should I just ignore it? Or should I give the author x days to fix and then disclose? Or is there some middle ground?