I think that's the first thing you need to do before deciding how to react.
Did the author decide he'd created an unmanageable hack and push management to pull in a contractor to either clean up the project or simply suffer through trying to maintain it, so he could get back to focusing on his other work?
Did management rush the author to get something "usable" out the door so they could put him on another project, and you're just the mop-up crew?
It's very likely one of those two things. You could respond to either of them by simply "run, forrest, run!", or you could roll up your sleeves and get to work. If you choose to take it on, your approach will depend on why you are there. First off, trashing on the author won't get you anywhere with anyone, don't even consider it. The author may realize he made a mess, management may not. But right now the author is your best ally. Don't burn that bridge by running to management and telling them the reason it's going to be expensive to fix is because the author created a mess.
That being said, document everything, in case it comes back to bite you. You don't need to share that documentation with anyone unless necessary. It's your safety net in case the excrement strikes the oscillating unit and the author tries to blame the problems on you.
Have a private chat with the author and find out which of the two above is the reason you're there. You'll notice that in either case, he's probably very happy to have you taking over, and you should be able to easily leverage that to get his cooperation. That will make your job monumentally easier. Projects by good authors that get into this state are usually the result of inadequate planning, or a late change in requirements. The author probably had a fairly-well fleshed out plan that went south at some point, and that plan is probably not very clear to you right now. Ask about that plan, find out where the code was meant to go, why it didn't end up going there, and mosts importantly what problems did that create and how did he work around them. Those work-arounds are what's causing your grief. Knowing what they are is half the battle (that's why stuff broke when you edited), knowing why they were necessary is the other half. (THAT'S why other unrelated stuff started breaking) Get this information from the author.
At that point, you can take a very well-informed look at the project and decide if it's worth your hassle to take on. Then either take it or leave it. If you decide to bail, you can look back on your documentation and decide how much of that is necessary to justify your decision and get some compensation for your trouble. If you do decide to take on the project, discuss the issue again with the author and get their input on how to explain the maintenance costs. Even if it has to come down to "this is going to be expensive because Bob created a mess", giving him a chance to have some input on how this is addressed will help keep him in your corner down the road. If he's anywhere near reasonable, he'll understand that he's going to have to accept some of the responsibility for what he started.