I believe this needs more info as there's quite a bit of uncertainty in the report, but overall it doesn't sound like a bug, more like a potential feature request.

If the clipboard is synchronized between multiple hosts, then it doesn't seem to be too surprising that copying on one host results in the clipboard change getting propagated even over multiple hops. So given an A <-> B <-> C setup, A <-> C synchronization isn't really a bug because technically it's either (A -> B, B -> C) or (C -> B, B -> A) synchronization pairs, both being allowed.

If the assumption is right, then I could see this being turned into a feature request of either:
- Splitting the clipboard sharing functionality to have separate send and receive options with both being enabled for the current behavior, but the directions could be separately toggled to break chains
- Adding explicit clipboard sending functionality for fine grained control, so there would be no automatic propagation at all when that would be used

Technically these options are not mutually exclusive, and they would even compliment each-other with some well needed extra security by a host potentially being configured to ignore received clipboard data even when it's manually pushed while still sending if/when desired.

I am surprised about your explanation "(A -> B, B -> C)".

If I trust person A, and person B trusts person C, I do not automatically trust person C. I think this is a security leak.

Think about sharing passwords.

I'm just somewhat guessing, especially trying to guess what could have been your issue, not agreeing with how it currently works, and that's also why I'm not really experienced with it because I don't really view it as secure either, I just see the logic how it makes sense that bidirectional sharing results in chained propagation, and users preferring convenience over security are likely okay with it.

Generally KDE Connect doesn't really seem to be too security focused (yet), pairing establishes an overly trusting configuration by default.

Still, what you likely experienced isn't really what I'd conclude as A and C trusting each-other, they can't do anything without B proxying, so the issue is with the lack of finer grained control/permissions instead of a security bug existing.
What could have happened:
- A notices clipboard change, sends new data to B
- B gets new data, writes to clipboard
- B notices clipboard change, sends new data to C
- C gets new data, writes to clipboard

Technically there could be an option to explicitly break chaining by making sure the clipboard changes coming from KDE Connect itself are not propagated, but I still believe that the earlier proposed solutions are the right way.
The issue isn't really any different than what would you have with other P2P solutions. For example if Syncthing is used to share a directory from A to B, and B would share it with C, then you'd still have the same issue, and the solutions there are pretty much similar to what I proposed:
- There's no "automatic" data sending in the sense that you can choose to use another directory first, and only copy the result to the shared one when you are ready to share. Clipboard is quite different, so an optional explicit send operation would be more sensible there as you can't choose to use an alternative clipboard if you don't want to send, you just want to copy around information locally.
- Directories can be set as "Send & Receive", "Send Only", or "Receive Only". You can't actually have a receive only directory shared with 2 completely unrelated senders due to the resulting conflicts, but in this case the clipboard is simpler, you could set up B to only receive from A and C without sending to them, so the other hosts would be able to send new data, but they would never receive any. Also, alternatively just like manual sending, manual receiving could be possible, it may as well be an optional automatic prompt popping up allowing new clipboard content to be accepted if the user wishes to do so.

Still, these are just proposals how could it be better, but many users might be okay with the current complete trust approach already even if it's not appealing for us.
Look at this "A <-> B <-> malware"-kind of example on a completely different platform: https://www.youtube.com/watch?v=xZBDmI9fdbs
Of course others also having the same problem doesn't make it right, just pointing out that it's not considered a bug, it's a permissiveness issue arising from the coarse grained control of just either propagating widely, or not using the functionality at all.