In STM32G071 errata (ES0418), the following erratum appeared, dated 17-Oct-2022:

It is not clear, which STM32 are affected, but based on anecdotal observation of "mysterious failures" which match this description, reported on the forum, it at least affects also some of the STM32L4 - and, according to subsequent post in the same thread, STM32F412 is affected, too. A similar report by user arnold_w indicates, that 'F446 is likely be affected, too - and in this case, it affected PA0. ST does not always propagate such finding to all affected models' errata timely, so it may quite well be that all STM32 are affected.

What might be the worst-scenario consequences of this issue?

It appears, that if the VBAT brownout (i.e. VBAT voltage decreasing to the critical window and then rising again) occurs, the backup-domain¹ registers' content may end up in any random state. These registers are mainly registers of RTC (and TAMP in families where it's a separately described unit), but also the backup-domain control register, RCC_BDCR¹. It may well be that in certain STM32 a few spurious bits scattered across peripherals also belong to backup-domain, always check your STM32 RM.

In applications, which do use the backup-domain facilities (RTC, backup registers, LSE to clock asynchronous peripherals such as LPTIM or LPUART) the consequences of spurious change of these registers/bits is obvious. However, there are also consequences to applications which don't use the backup-domain facilities, or use only some functionalities of them while the spurious change sets other functionalities.

One such consequence may be unexpectedly higher power consumption, e.g. due to inadvertently enabled LSE; other may be unexpected interrupt or register clear through tamper input. But maybe the most dangerous consequence is, that some backup-domain registers bits enable to override the GPIO settings of certain pins, changing their intended functionality or even causing hardware conflict by unexpectedly turning them to output. Some of such pins are PC13 (the common RTC-output-tamper-etc. pin), PC14/PC15 (OSC32 pins for LSE), PA2 (LSCO pin), and they may be more - the Additional functions column of Pin definitions table in DS to given STM32 model may be helpful in identifying such pins.

There are three groups of applications, regarding VBAT connection/usage:

1. Backup domain (mainly RTC) is not used at all, VBAT connected to VDD either through internal bond in the low-pin-count devices, or externally as per datasheet guidance.
   The recommended workaround is to explicitly reset backup domain ( using RCC_BDCR.BDRST). This is probably the most common usage model, and perhaps the most dangerous for this particular issue, as users who don't use actively backup-domain (RTC) features are not likely to associate any problem with backup domain/RTC, nor to actively seek issues related to the backup domain/RTC. Thus, the problem violates the unwritten "if you don't use it, simply don't touch it, the default state is OK" rule.
   I expect ST will be adding such reset quietly to all CubeMX-generated code which did not have backup-domain facilities clicked, but users who don't program by clicking in CubeMX ought to be warned, too. Given above analysis the erratum is not appropriate enough for this, ST should consider adding conspicuous warnings directly to RM (probably to the Reset subchapter of RCC chapter).
2. Backup domain (mainly RTC) is used only while VDD is present, VBAT connected to VDD in the same way as above.
   The recommended workaround is again explicit backup-domain reset in the startup code, however with one exception: if Standby mode is utilized, the user may want to avoid the backup-domain reset. The erratum in ES0418 contains a long, winding and relatively complex description of the possible workaround (i.e. discrimination of power-on reset from reset-to-exit-standby).
3. Backup domain is actively used with battery (or capacitor/supercap) connected to VBAT.
   This case is not mentioned in the erratum, but this may be one of the most problematic cases, especially if the battery is not maintained actively or if a capacitor (often supercap) is used in place of battery on VBAT. In case of battery, using only batteries from reputable sources with well-known characteristics, regular measurement of VBAT voltage through the facility built into ADC, and/or counting usage time and estimating future lifetime may be part of the solution. In any other case, comprehensive registers checksumming, estimates based based on on- and off-time timing, and similar techniques can/should be employed.