The answer is that it affects Chilkat no differently than anything else. Here are two thoughts:

Generally, when Chilkat has sensitive data in memory, such as passwords, private keys, etc., they are kept encrypted using a random (internal) session key that is different for each internal object instance. When the particular thing is needed, such as the password, it is decrypted, used, and then the memory zeroed out. This is standard practice that existed long before Meltdown was ever discovered.

With the discovery of Meltdown, Chilkat recognized that methods exist where passwords are passed in strings, such as to authenticate with a mail server, SSH server, etc. Even if Chilkat stores the password encrypted in memory once it's received, there is still the issue of the password being clear-text in memory in making the call from application code to Chilkat. Thus Chilkat is introducing the SecureString class to mitigate that vulnerability. Here is an example: https://www.example-code.com/csharp/sftp_authenticate_secure.asp The SecureString class will be released in Chilkat v9.5.0.71 in the next few days. The idea of SecureString is that your app might keep passwords in a database, or in files, perhaps encrypted. They can be loaded into a SecureString from an encrypted source, and then passed to a newly added Chilkat method that accepts the SecureString.