It could probably be worth adding a few other examples just to be extra-safe:

• CREATE USER T12345 PASSWORD "Password123"
• ALTER USER <user_name> PASSWORD "<new_password>"

I haven't done a very exhaustive search here, but there might be a few other cases to cover.

While I'm definitely not familiar with the parser and sanitization logic here, having explicit tests would probably make us sleep better.

I'll try a slightly different approach.
The problematic thing here is really that the password can appear unquoted or in double quotes although the db only supports single quotes for string literals. Our sanitizer can easily find quoted string literals but it is harder to find what follows the PASSWORD keyword. It is further complicated by the fact that oracle also allow unquoted passwords but uses IDENTIFIED BY instead of PASSWORD. Also mysql used PASSWORD keyword for something different https://dev.mysql.com/doc/refman/8.4/en/create-user.html and it shouldn't trigger sanitization.