The vulnerability isn’t someone going through Tailscale and then through Cloudflare.
Lets imagine you have a reverse proxy elsewhere in your Tailnet. That reverse proxy is accessible from the internet. That reverse proxy is transparent and does not moderate which headers it forwards along to Caddy. This request path does not involve Cloudflare at all.
An attacker could craft a request e.g. curl --header "Cf-Connecting-Ip: <some-trusted-IP>" https://tailnetproxy.example.com. Your reverse proxy on the Tailnet would forward it to Caddy, including the crafted header. Caddy would trust the connecting proxy because you’ve configured it to trust the whole Tailnet, and it will therefore trust the attacker’s Cf-Connecting-Ip. The attacker could thereby fool your Caddy server into thinking the original client was any IP address, including IP addresses that may bypass security mechanisms or position the attacker advantageously, e.g. appearing as though within your LAN if that would give them access to things they shouldn’t have.
This is only a problem if you do in fact have a reverse proxy in front of Caddy somewhere in the Tailnet, and it is also accessible to threat actors (such as being available to the internet), and it does not scrub Cf-Connecting-Ip from requests, and you have some website on Caddy which would be more vulnerable to attacks from specific IP addresses, or perhaps some mechanism like fail2ban which could be abused to deny service to legitimate IPs.
It’s a limited attack path, but it exists and it’s worth noting, because when it does strike, it can really suck.