You need a threat model in order to assess risk. You don't have one.
Yes, an attacker could insert new password hashes into a stolen copy of the database. That is relatively easy to do. In fact, you can assume any attacker who bothers to steal a database is capable of mounting, reading, and modifying that database in its entirety.
But what is the harm associated with replacing password hashes on his copy of the database? This will not allow him to do anything useful. Exception: If the database has used some horribly flawed home-brew encryption, then he may be able to retrieve encrypted records from the database. Don't roll your own security unless you have a team of full-time experts.
Once the database is stolen, you will never load it back onto your production systems. If he has replaced the password hash on an account in his copy, it doesn't change anything on your instance. He cannot log into your users' accounts that way.
Lacking a clear path to a negative outcome...
A threat model would include a technical method by which an attacker could harm you, and then you can assess the impact and likelihood of that harm occurring. Unless you can describe how the proposed action leads to any harm, there is no risk to assess.
Provided that your database did not employ custom, low-quality "security" and your production database is not restored from a leaked copy, I don't see how additional harm is possible.
To be clear, there is potential harm under normal circumstances, just not from the actions you describe.
The most likely threat is rainbow tables and/or cracking.
With possession of the database, he could attempt to recover passwords for your users. However, this requires the attacker to retain the original hashes. This is the real threat associated with stolen authentication data.
The correct response to this threat is two-fold: force a password reset for your entire userbase using your standard challenge mechanism, and warn your users to change their password on any other sites if they used the same password.
If you used salts when hashing, a rainbow table will be useless, and the attacker must crack each password individually. This is automatically true if you chose a modern password hashing algorithm, although it will only slow down a skilled attacker.
Modern (dictionary+rules) cracking efforts run on consumer-grade GPUs will recover 50%+ of passwords easily---unless you have insanely high complexity requirements and a high effort algorithm.