I've has an similar experience to the one you describe here. I need to make a simple change to a critical piece of code in the system I am responsible for after the coworker who wrote it had left the company. He had given me a walk through indicating what needed to be done, and essentially suggested it was a trivial change. Unfortunately time didnt permit me to do the change with him, and once he had gone it turned out that what he had explained was wrong. I spent a week debugging the code, tracing through the code, etc. And got nowhere. Changes I made seemingly did nothing. As I knew there were changes coming along that would be much more drammatic I decided that given a trivial change was turning it a huge effort the future changes would be signifigantly more difficult, and frankly not worth the time. End result I wrote a total replacment, in only a little more time than it had taken to decide the old code was unmaintainable.

That replacment provided a strong foundation for the much more drammatic enhancements that came down the pike. The time invested in rewriting and restructuring the code paid off big time as the new code base is much easier to extend, and has been pushed far beyond any of the changes I had thought were coming. Had I persevered with the original code base and taken another week to get that trivial change in place the stuff that came after would be impossible.

I think what the OP needs to do is present a structural argument as to whether the code base should be refactored. If the argument is convincing his boss will give him permission.