In a perfect world, whenever a serious issue or bug with a Drupal contributed module is identified, it would get tested and deployed to an approved official version. Unfortunately, that just isn't realistic.
There are many advantages to working with open-sourced, community developed software, but those advantages come with the reality that problems require time for volunteers to solve. The solutions will usually need to be developed by people doing the work and testing in their spare time. The system works, but it just means that sometimes there is a lag in between problem identification and official releases solving the problem.
While this lag time can be manageable, sometimes the problem is just too critical to wait, and so that means applying patches to the contributed module in order to get things working properly again.
There is a best-practices set of guidelines on how to apply patches to contributed Drupal modules, and it is advised that you abstain from attempting this process if you do not thoroughly understand those guidelines. Patching a Drupal module does not always go smoothly, primarily because a Drupal website is usually composed of many modules. It is essential that if you are applying a patch or patches that you do so in a safe "development" environment, as opposed to your live "production" website. That way if something does go wrong it won't make matters even worse.
The best steps for applying Drupal patches as outlined here are -
Check the module issue page, linked to from the contributed modules main page, for info about the problem and linked patches. Approved patches, those tested by the automated testing system in Drupal.org, will be linked for download. Be sure to read the discussion surrounding the issue and the patch to be sure that it addresses the problem you have.
Test Before Deploying!
Next, you'll need to download the patch to your local development environment to the location where the module resides. It is easier to apply the patch if the patch file is saved relative to the module location from which the patch was made. This is usually inside the specific module directory. It is also important to be sure that the patch you are using is based off the same version of the module you are trying to fix.
Finally, as demonstrated here (https://www.drupal.org/patch/apply) you'll use the appropriate version control commands to have the patch code applied to the code in your testing environment. The patch file itself is a form of "diff" which contains all the instructions which a version control system like "git" needs to make the changes to your code to match the end result specified by the patch. This way of applying patches is much easier and less error-prone than trying to make all of the code changes manually by hand.
If everything is deployed properly, and your testing reveals the problem is fixed, you'll want to save these code changes to your version control system and then finally deploy on up to your live website. It is important to realize that the patch you use now may alter or be different from a future official version update for the module in question. Consequently, performing any module updates such as with Drush, may inadvertently remove the fix you just applied. To manage that potentiality, be sure to save the patches you are using in a separate patches directory for your Drupal website and add documentation pointing out why and how those patches are applied.