That is a vulnerability in the front panel. The front panel is deciding based on the reply from the 'enter factory code' command that it is ok to send the 'reset user code' command. The front panel should not be making decisions like that. The front panel should not be sending commands at all.
I think you are misunderstanding what old mate is saying.
The vuln is in the back of the panel because it's accepting the reset code command.
The front panel isn't vulnerable because it's not a trusted component here anyway, the bypass actually just talks directly to the back panel.
You are however correct that the front panel probably shouldn't be sending an actual reset code command, but that is really a protocol level problem not specifically a front panel issue. It's possible to make that safe by having the back panel first transition into appropriate state upon being primed with existing code or valid factory code before accepting the reset command but an even better fix is to couple both the validation of the existing code + the desired new code into a single command that is validated in one shot.
It's a vulnerability in the inside panel that was covered up by requiring the front panel to do more than it should. If the front panel were just a dumb I/O device, the inside panel could not have this specific vulnerability.
No, you're misunderstanding. The front panel is validating that the factory code is entered correctly before it allows the lock code to be reset. If the front panel were just dumb I/O, the inside panel would have to validate the factory code before allowing the lock code to be reset.