From a business process standpoint you have the concept of risk:
- How likely is something to go wrong?
- What is the possible impact if it does go wrong?
- Do you accept, mitigate, or avoid that risk?
You are approaching the process of wanting to avoid the risk while your manager seems to be on the side of accepting that risk.
On the flip side, there is also opportunity cost:
- What is the potential gain of doing an action?
- How likely is that action going to pay off?
- Do you accept, mitigate, or avoid the opportunity?
You have a customer that is paying you to host, and if you refuse to do so, you lose that money--and potentially the contract.
That said, there is that middle ground that I don't think you've explored yet. The middle ground of "mitigation".
It's common practice to put externally facing web applications in a De-Militarize Zone (DMZ), where there are firewalls on either side of the DMZ so that you mitigate bad actors from outside and bad code inside the DMZ.
You might look at adding another set of firewalls around your 3rd party code, assuming that copy and deploy is all you need to get it working. Usually there is further configuration required as well.
We can all argue back and forth whether the code is safe or not, but that really isn't the question we should be asking. It's how badly can this impact your environment and operations. In business there is always a balance of risk and reward. At the end of the day, as long as everyone is working within the legal constructs of your company, someone has to make the decision of how to handle the risk. If your manager decides to accept the risk (and he has the legal right to do so), then he is ultimately responsible if something does go wrong.
In short, if you can't quantify your concerns, or they turn out to be within acceptable limits, you'll have to go with what your manager says to do. If you can come up with a low cost solution to minimize potential damage to your infrastructure then you can propose that.