sdbootutil EUVD-2026-101945

Requires a local account of any privilege level on an affected SUSE Linux Enterprise Server 16.1, SLES for NVIDIA 16.1, openSUSE Leap 16.1, or Tumbleweed host (attack vector is local, not network). The specific prerequisite is that the sdbootutil script has been invoked such that it created the debug log /var/log/sdbootutil.log, and that this log actually contains secrets - the description notes the log is created 'on request', so exposure only occurs where debug logging has been run. The enabling defect is the world-readable file permission on that log. Limiting factors: no remote exploitation, the log must exist and hold sensitive data, and systems not using sdbootutil/systemd-boot are unaffected.

This is a genuine but modestly-scoped local information-disclosure issue (CWE-732, incorrect permission assignment), not a high-urgency remote threat. The SUSE-supplied CVSS 4.0 vector (AV:L/AC:L/PR:N/UI:N/VC:H) and the 6.9 (Medium) score agree: exploitation is confined to the local system but yields High confidentiality impact because the sdbootutil debug log can contain secrets. No EPSS score, KEV listing, or POC was provided, and there is no public exploit identified at time of analysis - so exploitation is plausible-and-trivial-if-conditions-are-met but not currently observed. The main signals are internally consistent; the one point worth verifying is privileges: SUSE encoded PR:N (any actor, since the file is world-readable), yet realistically an attacker still needs a local account on the host, which in CVSS 3.1 terms is better modeled as PR:L. A second implicit limiter not captured in the base vector is that the log only exists 'on request' and only exposes secrets if debug logging was actually run and wrote sensitive data - so real-world exposure is situational rather than guaranteed. Net: a legitimate patch-worthy hardening bug for multi-user SUSE hosts, but low priority relative to network-exploitable or actively-exploited CVEs.

On a multi-user SUSE/openSUSE host where an administrator has run sdbootutil with debug logging, any unprivileged local user simply reads the world-readable /var/log/sdbootutil.log and harvests whatever secrets it recorded (e.g. boot/credential material). No exploit code is required - standard file-read access is sufficient - and no public POC is needed given the trivial nature; no public exploit has been identified at time of analysis.