CVE-2026-73585: Sblim-cmpi-base: insecure temporary file creation in sblim-cmpi-base provider registration scripts allows local symlink attack

Published Apr 26, 2026
·
Updated

A flaw was found in sblim-cmpi-base. Insecure temporary file creation in the provider registration scripts allows a local unprivileged user to perform a symlink attack. By creating a symlink in a world-writable directory, an attacker can redirect privileged writes to an arbitrary file during script execution in a privileged context. This can lead to the overwrite of root-owned files, potentially disrupting system services or operation. Exploitation is conditional on the script running with elevated privileges and may be mitigated by sticky-directory symlink protections.

Other sources

AIONLYREPORT package: sblim-cmpi-base-1.6.4-30.el10 ------ Summary: Insecure temporary file creation in world-writable directories allows symlink overwrite: predictable temporary filenames in provider registration scripts let a local attacker redirect privileged writes into an attacker-chosen file during registration. Requirements to exploit: A local unprivileged user must be able to create a symlink in /var/tmp or /tmp, and provider-register.sh must be run in a privileged context such as RPM %pre, %post, or %preun, or invoked manually as root with a vulnerable registration mode. Exploitability is reduced or blocked on systems enforcing sticky-directory symlink protections such as fs.protectedsymlinks=1. Component affected: sblim-cmpi-base provider registration scripts provider-register.sh and provider-register.sh.pegasus-interop; strongest observed path in sfcbinstall()/sfcbtransform(), with similar temporary-file handling in pegasusinstall() and openwbeminstall()/openwbemuninstall(). Version affected: sblim-cmpi-base-1.6.4-30.el10 when the vulnerable registration script paths are executed with elevated privileges on systems where sticky-directory symlink protections do not prevent the link traversal. Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H - 6.4 (MEDIUM) AV:L - Exploitation requires local access to the host. AC:H - The attacker must hit a privileged registration flow, and exploitation may be blocked on modern systems by sticky-directory symlink protections or require PID prediction in some code paths. PR:L - An unprivileged local account is needed to create the symlink in a world-writable directory. UI:N - No separate victim interaction is required once the privileged script runs. S:U - The vulnerable write and the resulting impact stay within the same host security scope. C:N - The demonstrated behavior is file overwrite rather than information disclosure. I:H - A successful attack can modify root-owned files in a privileged execution path. A:H - Overwriting critical files can disrupt services or system operation. Impact: Moderate. On systems without effective sticky-directory symlink protections, the flaw can let a local user overwrite root-owned files during privileged registration flows. However, exploitation requires local access, a privileged execution event, and conditions that are not universal. Under Red Hat's guidance, this fits Moderate impact: a flaw that could have had Important impact but is less easily exploited based on the technical evaluation and/or affects certain configurations. Embargo: no Reason: This is a local, configuration-dependent issue with straightforward mitigation (mktemp and safer temporary-file handling), and the available evidence does not show a remote or default-path compromise scenario. Acknowledgement: Aisle Research Vulnerability Details: The provider registration scripts create temporary output files in /var/tmp or /tmp using predictable names and then write through shell redirections that follow symlinks. The clearest path is the sfcb mode, where baseregname is derived from the registration filename and used directly in the temporary path: sh for TEMPDIR in /var/tmp /tmp do if test -w $TEMPDIR then REGFILENAME=$TEMPDIR/$baseregname.reg break fi done trap "rm -f $REGFILENAME" EXIT if sfcbtransform $REGFILENAME $myregs sh cat >> $OUTFILE <<EOFC A registration input such as LinuxBase.registration therefore leads to a predictable path such as /var/tmp/LinuxBase.reg. The package spec files invoke provider-register.sh during %pre, %post, and %preun, so vulnerable registration modes can run in a privileged package-management context. In a controlled proof of concept, pre-creating /var/tmp/LinuxBase.reg as a symlink caused registration data to be written into the symlink target before the downstream staging step failed. The pegasus and openwbem modes use the same insecure temporary-directory pattern with PID-based names ($$.mof); in openwbem, the script removes the output path before rewriting it, so that path may require tighter timing than the pre-created-symlink sfcb case. This pattern is consistent with CWE-377 and CWE-59. Steps to reproduce: 1. On a system where provider-register.sh can run as root, ensure sticky-directory symlink protections do not block the test case; otherwise the issue may not reproduce. 2. As an unprivileged local user, create /var/tmp/LinuxBase.reg as a symlink to a disposable root-owned file. 3. Trigger the sfcb registration path in a privileged context, for example provider-register.sh -t sfcb -r <registration> -m <mof> as root, or through the equivalent package lifecycle action. 4. Observe that registration content is written to the symlink target before the staging step exits. Mitigation: Until a code fix is shipped, keep sticky-directory symlink protections enabled (fs.protectedsymlinks=1 or equivalent), avoid running the provider registration script from shared multi-user systems where untrusted users can plant entries in /tmp or /var/tmp, and prefer a private root-owned temporary directory if the script must be run manually. Proposed Fix: Replace predictable temporary filenames with securely created files from mktemp, keep restrictive permissions, and quote the generated path consistently. The following minimal patch addresses the primary pegasus and sfcb cases; the same pattern should also be applied to openwbeminstall(), openwbemuninstall(), and provider-register.sh.pegasus-interop. diff — a/provider-register.sh +++ b/provider-register.sh @@ for TEMPDIR in /var/tmp /tmp

do

if test -w $TEMPDIR

then

REGFILENAME=$TEMPDIR/$$.mof

break

fi

done + umask 077 + REGFILENAME="$(mktemp "${TMPDIR:-/tmp}/provider-register.XXXXXX.mof")" || return 1 @@

trap "rm -f $REGFILENAME" EXIT + trap 'rm -f – "$REGFILENAME"' EXIT @@

if pegasustransform $REGFILENAME $myregs + if pegasustransform "$REGFILENAME" $myregs @@

for TEMPDIR in /var/tmp /tmp

do

if test -w $TEMPDIR

then

REGFILENAME=$TEMPDIR/$baseregname.reg

break

fi

done + umask 077 + REGFILENAME="$(mktemp "${TMPDIR:-/tmp}/provider-register.XXXXXX.reg")" || return 1 @@

if sfcbtransform $REGFILENAME $myregs + if sfcbtransform "$REGFILENAME" $myregs

------ This report was generated using AI technology. Always review AI-generated content prior to use

Red Hat

Affected Software

1 affected component
sblim-cmpi-base=1.6.4-30.el10

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade sblim-cmpi-base to a version that resolves this vulnerability.

    Fixed in sblim-cmpi-base-1.6.4-30.el10
  2. Configuration

    Avoid predictable/insecure temporary filenames in provider-register.sh registration modes (pegasus, sfcb, openwbem). Replace predictable temp path patterns such as using baseregname-derived names (e.g., _TEMPDIR/$baseregname.reg) or PID-based names (e.g., $_TEMPDIR/$$.mof) with securely created temporary files (as the script already attempts via mktemp) and ensure restrictive permissions (e.g., keep umask 077 and quote the generated _REGFILENAME). Apply the same safer temporary-file handling pattern to provider-register.sh.pegasus-interop.

    provider-register.sh (sblim-cmpi-base provider registration scripts) temporary file creation = use securely created mktemp with restrictive permissions (and avoid PID/predictable temp paths)
  3. Compensating control

    Mitigate until a code fix is shipped by enabling sticky-directory symlink protections so symlink overwrite is blocked. Systems noted include: ensure fs.protected_symlinks=1 (or equivalent) and, on systems without effective sticky-directory symlink protections, do not run the affected provider registration scripts in /var/tmp or /tmp with vulnerable modes.

  4. Compensating control

    Run the provider registration script only with effective protections and avoid environments where untrusted users can plant symlinks/entries in shared multi-user temporary directories such as /tmp or /var/tmp. If the script must be run manually, use a private root-owned temporary directory.

  5. Operational

    If exploitation is suspected/possible during privileged registration flows (%pre, %post, or %preun) where writable symlink targets in /var/tmp or /tmp may have been overwritten, review system integrity and restore any potentially overwritten root-owned files before proceeding.

Event History

Apr 26, 2026
Data Sourced
via Red Hat·06:37 PM
DescriptionSeverityAffected Software
Aug 13, 2026
CVE Published
via MITRE·12:44 PM
Data Sourced
via MITRE·12:44 PM
DescriptionSeverityWeakness
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203