Differentiate between Implementation and Protocol
The protocol is the "theoretical" was two machines are supposed to communicate with each other. The Implementation is the actual code running on the machine, which implements a protocol. There is a difference between saying a protocol is insecure, and an implementation is insecure.
For example, Heartbleed was an issue with the implementation, not the protocol. It could easily be fixed by just adding a boundary check into the relevant code section. Wired Equivalent Privacy, better known as WEP, was a flawed protocol to begin with. No implementation could fix the inherent weaknesses in the design, and the only mitigation was to switch to a newer, more secure protocol.
Is TLS 1.2 a secure protocol?
Well...yes and no. It fixed some of the issues, from TLS 1.0 and TLS 1.1, but it still followed the design principle similar to Burger King, namely "Have It Your Way". TLS 1.2 supported a myriad of different cipher suites, which in terms of security range from "Best Practice" to "Oh my God what are you doing?!"
As such, if someone says "I am using TLS 1.2", you really can't know if they are secure or not. There are a lot of ciphers, which are supported by TLS 1.2, which experts now agree are insecure.
Is TLS 1.3 a secure protocol?
Generally, yes. Or more specifically, we have not found any weaknesses yet. The design philosophy shifted away from allowing all sorts of protocols, to only allowing a very tiny, known-to-be-secure set of ciphers. That means if you and your client support and use TLS 1.3, you are going to use a secure protocol - at least, given the knowledge we have 2021.
What does this all mean in practice?
It means that in order to have a reasonable amount of confidence in the security TLS provides, you need to look at the following things:
Which versions of TLS do you support?
TLS 1.3 is the most secure one, but also has limited support for clients. TLS 1.2 is considered secure, if and only if you use a secure set of ciphers. Which ciphers those are exactly depends on how many clients you wish to support. Mozilla's SSL Config Generator (which should really be called TLS Config Generator) offers an "Intermediate" profile, which is a good starting point.
Is your implementation up-to-date?
TLS implementations can have bugs, which lead to vulnerabilities. For example, the CCS Injection Vulnerability or Heartbleed vulnerability are all implementation vulnerabilities, which can only be fixed by staying with an up-to-date version of your TLS implementation.
Is your implementation configured correctly?
Certain attacks are possible when certain configuration options are set. For example, when Secure Renegotiation is enabled, this can lead to Denial-of-Service attacks. Luckily, this feature was removed in TLS 1.3. So please make sure that your configuration doesn't lead to vulnerabilities.
Do you use compromised keys?
If the keys to your certificate are compromised, malicious third parties are able to impersonate you perfectly and intercept traffic to your server. No amount of TLS security can prevent that.
Examples of weak ciphers
Since you specifically asked for examples of ciphers, which are supported by TLS 1.2, but are considered insecure, here are a few: