tl dr: it's normal for NAND flash and already dealt with, no need to worry about this.
.
.
More in depth answer:
Note how it says "correctED bitflips", and not "correctABLE bitflips".
The messages you are seeing there are normal for NAND flash. They mean that the ECC (error detection and correction) logic has detected issues and corrected the data on read using the parity bits.
A "bitflip" is a situation where a bit changes its state on its own, a 1 becomes a 0 or the reverse. It's not a bad block (permanent damage), it's just something that randomly happens in NAND because they are less reliable by design (to keep costs down), and work around this drawback by having ECC logic implemented to correct any bitflip (and this is still cheaper than making them more reliable at the hardware level).
So in a NAND flash device you have some space that is actually storing data, and some space that stores parity information, so the system can use ECC logic and correct bitflips. This is automatic.
The same thing happens inside SSDs, usb flash drives, SD cards and Smartphones (all use NAND flash), you just don't see this happening it because it's all handled by the storage controller, while in an embedded device where read/write speed isn't important (like a router) the flash memory is accessed raw, there is no such controller, so the system itself uses ECC when reading/writing it.
Note that with the ECC logic implemented (by either a storage controller or the system), the NAND flash is as reliable as you would expect a storage device to be. It's not "unreliable" or anything.
EDIT: bonus fact: the reason you are using "nanddump" tool instead of the more common "dd" tool to create a backup of the flash partition is that nanddump is aware of all the above and reads the NAND with ECC logic, and stores only the actual data (correcting bitflips) in the backup you are creating.
dd tool is not aware of NAND ECC logic, so it will read all the NAND partition, both data AND parity and will generate a backup that is exactly the same as actually on flash, but is completely useless and unreadable as it will contain both data and hardware-specific parity information which cannot be restored on a different device.
The dd tool (or something more advanced like pv ) can only be used on block devices. Hard drives, SSDs, SDcards and so on where any ECC is done by the storage controller, not by the system, so whatever it reads is pure data, no metadata or parity for ECC logic.