No. It is not secure to restore the data without taking steps to ensure that the data was not corrupted in ways that can lead to more security holes. It is also unlikely that upgrading from 9.4 to 9.6 is going to make any difference, and might actually complicate the restoration.
Many attacks involve the altering security information stored in the database. Even if you don't have such tables, it is just as common for attackers to embed code in what would normally be considered data and exploit security holes in the boundaries between code and data.
The correct way to proceed is to take a dump immediately prior to the attack and compare it with the last dump. This takes some skill, and you may have to assume a worst case scenario if you can't ascertain from audit and log files when the attack began.
Try to find ways to compare the before and after dumps, eliminating legitimate changes with each compare iteration. You will eventually find nothing, in which case you may have to take a risk of importing the data or restore to the last known good backup and live with the loss.
It would be better if you could use the compare and log and audit information to reverse engineer (best case) or determine the likely breadth of (less sure) the attack.
As unhappy as the truth is in this case. This IS like rocket science. You may need to ask more questions. Of course, much depends on how sure you need to be that you've cleaned all potential threats from the system, which depends on how critical the data and the user accounts are.