A regression is a bug that appears when a later change breaks something that used to work. It may be an old bug coming back, or a new problem introduced by a fix, an update or a refactor. The word describes the software moving backwards in behavior, even though the change was meant to improve it.
Regressions can occur in security releases as well as ordinary ones. A fix for a vulnerability changes code, and the change can affect behavior elsewhere. Maintainers often respond by publishing a follow-up release that corrects the problem, so it is worth reading release notes and checking for later versions after a security update is announced.
A known regression is not usually a reason to skip a security fix. The risk of staying on a vulnerable version should be weighed against the risk of a possible side effect, and that weighing depends on how the flaw can be reached in your environment and what the regression affects. A regression in one release also does not mean every user will experience it.
To handle updates safely, test them in a staging environment, deploy gradually where you can, and have a way to roll back. Read the project's release notes and issue tracker for reported regressions, move to a corrected release when one is published, and verify the running version and key behavior after each change.