OP_CODESEPARATOR is used in the Bitcoin script language to mark the beginning of signature-checked data. However, the given operator never found its real practical use case. So, is the given operator disabled in Bitcoin or can it still be used? If it is disabled, has any form of attack been detected that can be implemented using the given operator? Signing is a critical part, so I'm wondering if there might be some weakness in the system when using this operator, or is it disabled (if it is disabled) just because no one uses it?
So, is the given operator disabled in Bitcoin
can it still be used?
Yes. It is still supported in bare scripts (but non-standard there), in P2SH redeemscripts, and care was taken to keep supporting it in segwit and taproot script even (though the functionality changed somewhat in the latter). While it's unclear why the opcode existed in the first place (the best theory I've seen is to support delegation, though that broke when the scriptSig and scriptPubKey execution split was introduced), it's also not harmful to have it, and in practice it allows creating a script that needs signatures that can only be used in some of its execution branches but not all.
Signing is a critical part, so I'm wondering if there might be some weakness in the system when using this operator
The existence of OP_CODESEPARATOR in pre-segwit scripts does worsen the quadratic hashing problem those scripts exhibit, by permitting many more distinct signatures over the same data that need separate hashing. It has been proposed to remove that feature (only for pre-segwit) for that reason, though that idea seems abandoned at this point.
Note that that is a DoS concern for validation, and doesn't affect the security of individual signers. Wallets can always actively choose to use patently unsafe constructions (e.g. give out an address corresponding to an
OP_TRUE). Generally the goal of script design isn't to rule out unsafe behavior, only to avoid footguns or incentivizing unsafe or non-private behavior. OP_CODESEPARATOR doesn't seem to cause these (probably because its use is too niche anyway), so while it's unlikely that such a feature would be added today, there is little reason to go through the tremendous effort of developing and building support for a consensus change to remove it just because its use is unclear.