Validation is never intended to be a one-time event. This is but one of the circumstances that could take you out of the validated state.
But to answer your question, the vendor should be able to provide the list of changes and bugs fixed. You should look at the changes and consider if they touch any of the areas for which you previously validated. Look at the problems fixed to determine if your previously-validated version may have been allowing errors to slip through. If you did something along the lines of an installation qualification, ensure all that's still valid (they may require, for example, updated versions of infrastructure software or may no longer support certain browsers / versions). Take a structured approach to all this and document the results.
It's also a good time to review your intended use. Have any of your use cases changed (are you using the software differently than originally intended, are there substantially more users now than previously expected, have you started using new features than originally planned, etc.)?
You may be able to justify a reduced-scope re-validation. In keeping with the risk-based philosophy, identify the higher-risk functions are and probably at least re-validate those areas, regardless.
Last "soap box" statement: you *should* have a master validation plan that helps you in these decisions! If not a master plan, you should have a specific validation plan for this software that drives the efforts.
