I noticed that hairpin NAT on single interface bypasses firewall.

Let's assume following:

bottom router: top router:
In such config even though top router in theory shouldn't forward packets - it still does. While connection incoming from the outside won't be forwarded, 192.168.4.6 can still access 192.168.2.4 using 66.66.66.66 address. I'm not 100% sure but I think this issue occurs only if out-interface is the same as in-interface after NAT.

I find it security issue.
Change my mind.

You simplified the config too much, 192.168.4.6 won't be able to access 192.168.2.4 at all, via 66.66.66.66 or directly, because only way how packets can pass through bottom router is from ether2 or ether3 to ether1. So packet to 66.66.66.66 will get to top router, but even if it would send something back (it won't, because it has unconditional drop in forward, it won't route anything between any interfaces), bottom router wouldn't let it pass.

I assume it's related to your other topic (force push local address to gateway? (to avoid Hairpin NAT)), where I'd suggest to look for magic rule in forward filter, with action=accept and connection-nat-state=dstnat and understand what that does.

... but even if it would send something back (it won't, because it has unconditional drop in forward, it won't route anything between any interfaces), bottom router wouldn't let it pass.

The problem is - it would and it does. I didn't make this up from thin air. It's issue that occurs in my config. Packets forwarded by top router are not processed by forward chain in firewall at all. I added unconditional drop and packets still got forwarded. If dstnat occurs between 2 different ports then firewall works. However if they are looped back through the same interface forward chain in firewall is not processed. That's why I created this thread. Because it looks like anomaly to me. If it was dropped it'd be correct behavior and I wouldn't bring up this topic

True - firewall on my second router detected and dropped packets because I had there rules dropping such traffic (and I'm logging drops in firewall so I saw that packets got forwarded)

I use extremely fine grained whitelist firewall so I was quite confused that packets get forwarded even though they shouldn't be matched by any rule. But when I added drop all as first rule and it still looped packets back I realized something's wrong. Especially considering that packets coming from WAN were properly blocked, only ones looped on the same interface sneaked through firewall.

Tomorrow I'll try to recreate issue with CHRs lab so I'll be able to check whether it's related to my particular config or it's general behavior. However I already faced few "anomalies" in MikroTik NAT processing (eg. this: viewtopic.php?f=2&t=137463&p=677111#p677111) so I wouldn't be surprised

No way. It would have to be some new and completely crazy bug. Because it's all the same, no matter from where or to the packet goes.

Dstnat changes destination address (and/or port), it does that before routing happens, so it has no idea whether the packet will go out via other interface, the same interface or if it will go to router itself (it the new destination address would be router's own one).

And if the packet is routed, it's processed in forward chain, no matter which incoming and outgoing interfaces are involved. There's no special handling for dstnatted packets, forward doesn't know about dstnat, or more like doesn't care by default, unless you use connection-nat-state matcher.

Unless you reproduce it on router with exact config you posted, i.e. only that one drop rule in forward chain and nothing more, it must be some other rule allowing these packets to pass.

I'll try to check your other thread...

It is correct, there is no such bug, all NATted packets still have to be allowed by forward rules. I experienced that more often than I liked in a complex config.
So, there must be an error in the configuration. Show full configuration or debug it yourself.

Unless you reproduce it on router with exact config you posted, i.e. only that one drop rule in forward chain and nothing more, it must be some other rule allowing these packets to pass.

Hmm. They don't pass with this exact config in CHR. But it does occur with my config when I add drop all as first rule. It might be related to policy based routing I use. But I need further investigation. My config results in some weird interference that makes ROS bypass firewall. My blind guess is PBR and alternate routing tables because they tend to introduce lots of anomalies (like invalid out interface seen by firewall) but I don't have any clue beside that.

That's strange, because even with other routing tables it's still routing and drop rule as first one in forward chain is sure to stop everything (except fasttracked connections, but that's only established ones, not new).