PBKDF2-HMAC-SHA256 is not a recommendable† key/password stretching algorithm, especially with only 215 rounds. Problem is, it's too fast and resource-light to optimally slow down a password search for a powerful adversary (using GPUs, FPGAs, or ASICs).
It would be significantly safer to use a modern key-stretching algorithm like Argon2 at its industry standard parameterization. And, if that's not possible (e.g. because one wants to use WinRAR as is), it's advisable to increase‡ the PBKDF2 iteration count: the difficulty of password search grows about linearly with that. It's thus about 29 > 500 times harder to crack a password with 224 rounds than it is with 215 rounds.
However, poor password stretching is only a problem for poor passwords. For a large random password (e.g. 25 characters chosen independently at random among 64), that's a non-issue, and PBKDF2-HMAC-SHA256 with 215 rounds or more is ample.
AES-256 CBC encryption is solid from the standpoint of ensuring confidentiality, and that's more likely not going to be a weak point.
If there's a weak point beyond the password and it's stretching, it's going to be a flaw (deliberate or accidental) in the implementation of WinRAR. Determining if there is one would be hard, and is off-topic.
† NIST is thus consistent when it is still endorsing PBKDF2-HMAC-SHA256, after actively lobbying for Dual EC DRBG (just as the NSA made DES keys 56-bit).
‡ The WinRAR 5 file format specification states there's a 1-byte KDF count specifying the base-2 logarithm of the number of PBKDF2 rounds (if the question is right, that would be 15=0x0F to 24=0x18). How to coerce WinRAR into increasing that is unclear to me (it's possible that the value depends on the version of Winrar, or/and licensing terms/country).
