Broadcom LSI Storage Authority (LSA) - on-disk credential/key storage on Linux and Windows: The keys LSA uses

Impact

The keys LSA uses to encrypt its stored secrets sit in files any local user can read. On a bare-metal node that means anyone who lands non-root code on the host - a container escape, a compromised monitoring agent, a tenant with shell on a shared management jumpbox - recovers the credentials LSA uses to talk to the RAID controller and, in Gateway deployments, to other nodes. That turns a low-privilege foothold into control of the storage controller on the fleet, which is the layer that decides whether the next tenant sees the previous tenant's blocks.

Who can reach it

Any unprivileged local account on a host running the LSA agent (Linux or Windows). No network exposure required, no controller access required first.

What to do

Upgrade LSA to the fixed 7.017.011.000 build. If your OEM has not shipped it, tighten the file permissions on the LSA install directory and its key material by hand and re-apply after every OEM tooling update, since OEM installers reset them. Rotate any controller/gateway credentials that were stored under the old keys - patching alone does not invalidate what has already leaked. No reboot, no array impact.

References