CVE-2024-7594 - Clarification on SSH Secrets Engine Fields in Vault v1.13.6 and Upgrade Recommendation

Vault
1

Hi Team,

We are currently using HashiCorp Vault v1.13.6 and have recently reviewed a reported vulnerability that recommends upgrading to a newer version where the issue has been addressed.

While analyzing the SSH secrets engine configuration, we noticed that both the valid_principals and default_user fields are already available in the current version (v1.13.6). Given this, we are trying to assess whether an upgrade is strictly necessary at this point or if we are in a relatively safe zone with our current setup.

Could anyone please advise:

  • Is Vault v1.13.6 affected by the vulnerability despite having these fields?

  • Are there any other critical fixes or improvements in the latest version that would make the upgrade essential?

  • Has anyone else faced similar concerns or performed this upgrade recently?

Appreciate your guidance and insights!

Thanks,
Momina

2

My understanding (and I asked around internally to confirm) is that so long as you set those fields, you should not be affected. The issue is when they are not populated.

Having said that, 1.13 is reasonably old so would recommend starting an upgrade project.

3

Thanks for your suggestions.

4

Thanks for the suggestion and now we are planning to upgrade the vault from v1.13.6 to V1.17.6 where the vulnerability is mitigated. i just wanted to confirm whether we can directly upgrade from 1.13.x to 1.17.x?

5

I probably wouldn’t, but technically it should be possible. Whether or not this would work for you is highly dependent on your specific configuration (auth methods, secrets engines, etc) and any breaking changes in those configurations introduced between 1.13 and 1.17.

I would also highly recommend upgrading in a dev/test environment first (for any application not just Vault) and also validating your backup/restore processes work before proceeding.

When I have had to upgrade critical applications in the past, I would backup and restore to a test environment, test the upgrade process, and test client access. Not only does this help me identify gaps, but if I need to roll back production I know my backup and setup process works. I have also often performed a cut over for large upgrade jumps like this - bring up a new cluster, restore a backup, do the upgrade, and starting pointing clients to the new cluster. If there is something I missed, I can cut back to the old version of the cluster.

We are trying to be much more explicit in breaking change updates in our release notes, but possibility there is a gap from 1.13. You can see the current version here