Every v4 release carries the desktop app, the fleet CLI, and the PowerShell script together, so there is one stable line rather than a script channel and a desktop channel. Releases are unsigned by design (the evaluation is recorded in SIGNPATH.md) and are verified with checksums.txt and the GitHub release attestation.

LibreSpot changes the local Windows desktop client. It does not grant Spotify Premium, change account entitlements, or provide service-side catalog features.

• Offline downloads, lossless audio, Very High quality, mobile on-demand playback, and Jams remain Spotify account or service capabilities.
• Lyrics availability remains controlled by Spotify, your account, and your region. LibreSpot cannot provide unavailable lyrics.
• Existing Premium users can select Custom Install's Premium account (skip ad-blocking) option. That leaves ad-related patches off and does not alter the subscription.
• Maintenance > Full Reset restores the local Spotify installation to stock state. It does not change a Spotify account or subscription.

Local crash dumps are opt-in and armed for the next LibreSpot process only. Self-contained single-file builds use the adjacent .NET createdump.exe helper, which the local release publisher carries beside the desktop and CLI executables and covers with checksums.txt. Support export accepts a dump only when its header flags and stream kinds match the .NET Triage policy, and it rejects full-memory and private-memory streams before copying the binary. The .NET writer filters personal paths and passwords, but a Triage dump is still diagnostic memory that may contain sensitive process state. The flag and stream checks are policy gates, not proof that every byte is anonymous. LibreSpot never uploads a dump automatically.

Do not open a public issue for security vulnerabilities.

To report a vulnerability, use GitHub private vulnerability reporting.

Include:

• A description of the vulnerability and its impact
• Steps to reproduce or a proof of concept
• Your LibreSpot version ($global:VERSION in the script, or Help > About in the WPF shell)
• Your Windows version and Spotify version
• Whether the issue requires administrator privileges to exploit

• Acknowledgment within 72 hours
• Status update within 7 days
• Fix or mitigation timeline communicated within 14 days
• Credit in the release notes (unless you prefer anonymity)

The following are in scope:

• Arbitrary code execution via LibreSpot's download, patching, or script execution paths
• Privilege escalation beyond the requested UAC elevation
• Hash verification bypass (SHA256 checks on SpotX, Spicetify CLI, extensions, themes)
• Credential or token exposure in logs, crash dumps, or config files
• Unsafe file operations (symlink attacks, path traversal, TOCTOU races)
• Scheduled task manipulation (the ReapplyWatcher task)

Report these issues to the upstream owner instead:

• Vulnerabilities in Spotify itself (report to Spotify)
• Vulnerabilities in SpotX (report to SpotX-Official/SpotX)
• Vulnerabilities in Spicetify CLI (report to spicetify/cli)
• Social engineering attacks requiring the user to run arbitrary PowerShell
• Issues requiring physical access to the machine
• Denial of service against local Spotify installations (LibreSpot modifies local files by design)
• The UI-automation surface the shipped executables accept (--uia-smoke= and the other --uia- arguments, plus the LIBRESPOT_UIA_ROOT variable). It ships on purpose, because the release artifact is what gets measured for startup footprint and photographed for the README screenshots. Someone who can already run the executable can make it display a fabricated readiness or maintenance state, which is a presentation concern rather than an escalation. Every path the smoke view model builds for itself is derived from LIBRESPOT_UIA_ROOT, or from a fresh directory under the temp folder when that variable is unset, so a smoke run reads and writes no real configuration, logs, crashes, backups or Spicetify state. The backend is constructed in no-backend mode, so no smoke state can reach a real Spotify or Spicetify install, and the manifest stays asInvoker. The one exception is --uia-capture=<path>, which is not confined to the root because its whole purpose is to put a screenshot where the caller asked. It creates the parent directories if they are missing, writes a warm-up PNG beside the target and deletes it, then writes the PNG itself; if something else holds the warm-up file open, the delete is skipped and that file is left behind. All of it happens with the privileges the caller already has, and none of it reads anything. The surface, its limits, and the test that holds the containment are recorded under uiAutomationSurface in schemas/release-artifact-contract.json.

If you discover a vulnerability in SpotX, Spicetify CLI, or a community extension/theme that LibreSpot retrieves, please report it to the upstream project first. If the upstream is unresponsive after 14 days, you may report it here and we will disable or pin around the affected component.

The current SpotX pin is commit 550bc72c, which predates the upstream Defender change at afb4c3fc. The current metadata therefore records no Defender mutations and passes no opt-out flag. The policy boundary and required opt-out are stored beside the pin in PinnedReleases.ps1 and schemas/compatibility-baseline.json.

Every changed SpotX candidate must be reviewed with Build-Scripts.ps1 -SpotXSecurityPolicy in candidate mode. The check requires a post-boundary policy declaration, the exact -defender_exclusions_off switch in the candidate source and adapter metadata, and the same switch in the invocation arguments. A candidate that contains Defender preference or exclusion commands without that passed switch is rejected before execution. The runtime gate applies the same rule to interactive, backend, watcher, repair, and cached execution paths.

LibreSpot's pinned Spicetify v2.44.0 flow does not read the v3 support document. When a newer CLI major is detected, the feature-detected contract recognizes the upstream schema-v2 allowlist. An allowlisted Spotify version is accepted, a version with a same-minor lower modular classmap is degraded, and a version with no fallback is refused. Missing or malformed support data fails closed, so mutating paths stop and point to spicetify restore before the pinned 2.x CLI is reinstalled. The local fixture is schemas/spicetify-supported-versions-v2.json, sourced from the upstream schema.

CVE-2025-54100 is a remote-code-execution flaw (CVSS 7.8) in Windows PowerShell 5.1's handling of web content, fixed in the December 2025 Windows cumulative updates. Content fetched by Invoke-WebRequest can execute at parse time on an unpatched host, the same download primitive LibreSpot uses to retrieve SpotX, Spicetify CLI, extensions, and themes.

Mitigations in LibreSpot:

• SHA256 pinning, every download is verified against a pinned hash before use. This guarantees the integrity of the payload (a tampered or substituted file is rejected) but does not by itself remove the parse-time execution vector on an unpatched PowerShell 5.1 host.
• Patch-level preflight, the downloader runs a non-blocking check (Get-DownloaderCveExposure) the first time it fetches anything. On Windows PowerShell 5.1 (Desktop edition) it inspects the host's most recent Windows update and logs a WARN when the host predates the newest tracked fix, naming every advisory below and the ones still unfixed at that host's patch level. It never blocks the install, it tells you to update Windows.
• PowerShell 7+ is unaffected, PowerShell 7 (Core) is a separate product and none of the three advisories in this section apply to it, so the preflight skips it. It has its own floor, described below.

Required action for users: keep Windows fully updated. Hosts on the December 2025 cumulative update or later have this fix; the two 2026 advisories below need a later update still.

CVE-2026-26170 is an improper-input-validation flaw (CVSS 7.8, CWE-20) that lets an authorized attacker elevate privileges locally through Windows PowerShell. Microsoft published it on 2026-04-14 and ships the fix in that month's Windows cumulative updates. It affects the same in-box interpreter the LibreSpot script path runs on, across Windows 10, Windows 11, and Windows Server.

CVE-2026-40400 is a relative-path-traversal flaw (CVSS 8.0, CWE-23) that lets an authorized attacker execute code over a network through Windows PowerShell. Microsoft published it on 2026-07-14 with that month's cumulative updates. It is the newest fix among the three, so it is the date the preflight anchors on: a host whose most recent update predates 2026-07-14 gets the warning.

The three advisories share one mitigation story. SHA256 pinning protects payload integrity in every case and removes none of the interpreter-side vectors, so the patch level of the host is what closes them. LibreSpot warns and continues. It never installs Windows updates for you.

LibreSpot also checks the PowerShell 7 host before a download or external script launch. Versions 7.6.0 through 7.6.4 receive a non-blocking warning that names CVE-2026-50523 and related August 2026 servicing fixes, then points to PowerShell 7.6.5. PowerShell 7.6.5 and later are silent. The check does not change execution policy or install PowerShell.

Users should update from the PowerShell 7.6.5 release before running LibreSpot. The warning is advisory because LibreSpot cannot safely replace a user's PowerShell installation.

The Desktop and CLI releases are self-contained, so each binary carries the .NET runtime resolved during its build. Build-Scripts.ps1 -DependencyHealth therefore requires .NET 10.0.11 or newer for both Microsoft.NETCore.App and Microsoft.WindowsDesktop.App. The August 11, 2026 servicing release fixes ten CVEs, including two remote-code-execution issues. Rebuild release assets on a host with the patched runtime rather than relying on a later machine update.

The common fake-installer path starts with a video, social post, or chat message that asks you to paste PowerShell for “free Spotify Premium.” That command can run arbitrary code before LibreSpot is involved.

Use only release assets linked from the official LibreSpot repository. Do not trust Telegram links, rehosted files, or builds copied to another site. Download checksums.txt from the same release page and compare the asset before running it:

$actual = (Get-FileHash .\LibreSpot.ps1 -Algorithm SHA256).Hash.ToLowerInvariant()
$expected = (Get-Content .\checksums.txt |
  Where-Object { $_ -match '\sLibreSpot\.ps1$' } |
  ForEach-Object { ($_ -split '\s+')[0] }).ToLowerInvariant()
$actual -eq $expected

The result must be True. Delete the asset if it does not match. Never run a pasted command that asks you to disable Defender, add a Defender exclusion, or fetch LibreSpot from another host.

LibreSpot does not currently track build, release, or Scorecard GitHub Actions workflows. Release trust evidence comes from the local release build and post-upload audit: SHA256 entries in checksums.txt, the machine-readable librespot-release-manifest.json, CycloneDX SBOM output, pinned upstream download hashes, and local test/build logs. Each new release is published with GitHub release immutability enabled, which generates a Sigstore-verifiable release attestation. Verify it with gh release verify <tag> and verify a downloaded asset with gh release verify-asset <tag> <local-asset-path>. Source archives are not covered by the asset command.

Because the artifacts ship unsigned, each release starts with no Microsoft SmartScreen reputation. Reputation is per file, so it does not carry over from the previous version and every release warns again. As part of the post-upload audit, submit every shipped artifact to the Microsoft Defender analysis portal. A user can match an asset to checksums.txt or search its SHA256 on VirusTotal, but identity evidence does not establish that a detection is harmless.

Unsigned also means Smart App Control blocks every LibreSpot artifact, the two executables and the script alike, with no per-app allowance to grant. A device with it enabled cannot run LibreSpot at all, and that is the expected outcome rather than a defect to work around. Nothing in the project should ever suggest disabling it.

Because the artifacts are unsigned, provenance rests entirely on where a file came from. LibreSpot is published only at https://github.com/SysAdminDoc/LibreSpot/releases. Lookalike repositories with inflated star counts appear in the same searches, and they share a shape: a padded README, downloads hosted off GitHub, and a second "template" or "activation" file needed to make the tool work. A report about a LibreSpot build obtained anywhere else is a report about someone else's binary, and the first question to settle is whether gh release verify-asset accepts the file at all.

OpenSSF Scorecard findings are still treated as work, not noise. The accepted-risk baseline in schemas/scorecard-baseline.json records the project's single-maintainer limits and local gate expectations; if a manual Scorecard run finds a new low score, it should become a ROADMAP.md item with a remediation plan rather than a silently ignored warning.

Accepted single-maintainer limits: the following Scorecard checks score zero or low and are documented as expected for a single-maintainer project, they are not silently ignored:

These limits are revisited when their documented trigger conditions are met (e.g., a second maintainer joins, signing completes). The full accepted-risk registry is in schemas/scorecard-baseline.json.

LibreSpot does not ship Spotify binaries or an upstream SpotX or Spicetify distribution. It does ship its own MIT-licensed root hosts and the AGPL-3.0-only in-Spotify app, including the Prism theme and live engine. SpotX, Spicetify CLI, Marketplace, and the official theme archive are downloaded at install time from their official GitHub repositories using pinned URLs and SHA256 verification. The root project is MIT-licensed; the app component keeps the license in src/LibreSpot.App/LICENSE. LibreSpot uses no Spotify API Client IDs and makes no network requests except to GitHub for downloads and Spotify through the normal client.

If the SpotX repository (SpotX-Official/SpotX) is removed or DMCA'd:

• LibreSpot's pinned download URLs will fail. The installer will report a download error with the specific hash-verification failure and will not proceed with patching.
• LibreSpot will not silently fall back to an alternative source. Users will see a clear error explaining that the upstream SpotX project is unavailable.
• Existing Spotify installations that were already patched will continue to work until Spotify auto-updates override the patches.
• Users can restore stock Spotify at any time using Maintenance > Full Reset or manually by reinstalling Spotify from spotify.com/download.
• Spicetify theming and extensions will continue to work independently of SpotX.

If the Spicetify CLI repository (spicetify/cli) is removed:

• LibreSpot's Spicetify CLI download will fail. The installer will skip Spicetify setup and report the failure clearly.
• SpotX ad-blocking will continue to work independently of Spicetify.
• Users with existing Spicetify installations can run spicetify restore to remove theming, or use Maintenance > Remove Spicetify customizations in LibreSpot. SpotX remains in place after this action.
• The Spicetify Marketplace, themes archive, and community extensions are hosted in separate repositories, a Spicetify CLI takedown would not necessarily affect those, but LibreSpot would not be able to apply them without the CLI.

If LibreSpot itself becomes unavailable, users can restore an unmodified Spotify client manually:

1. Run spicetify restore in a terminal (if Spicetify CLI is still installed) to undo theme/extension injection.
2. Uninstall Spotify: Settings > Apps > Spotify or run %APPDATA%\Spotify\Spotify.exe /UNINSTALL /SILENT.
3. Delete residual data: remove %APPDATA%\Spotify, %LOCALAPPDATA%\Spotify, %APPDATA%\spicetify, and %LOCALAPPDATA%\spicetify.
4. Reinstall Spotify from spotify.com/download.
5. Remove the LibreSpot ReapplyWatcher scheduled task if registered: schtasks /Delete /TN "LibreSpot\ReapplyWatcher" /F.

Spotify has taken enforcement actions against tools that redistribute patched binaries or claim paid features: 520 GitHub repos were DMCA'd in August 2025, and ReVanced's Premium-access patch was specifically targeted. Desktop tools that focus on ad-blocking and UI customization (SpotX, Spicetify) have not been targeted and remain live. However, Spotify's January 2026 server-side dual-sync verification killed mobile mod APKs (xManager archived, ReVancedXposed archived), demonstrating that enforcement can escalate. See the README's Trust & risk disclosure section for current details. LibreSpot's session-stability canary (20-second post-launch monitor) will warn if desktop enforcement expands.

LibreSpot shells out to a few external programs. The boundary that keeps this safe is: arguments are either fixed literal flags or values that Normalize-LibreSpotConfig has already constrained to an allowlist or an integer. A crafted config.json cannot turn a setting into an extra command.

Rule for new arguments: any new SpotX/Spicetify argument that carries a user-controlled value must be normalized to an allowlist or integer in Normalize-LibreSpotConfig before it reaches the parameter builder, or it must use tokenized execution (ArgumentList) with explicit escaping. The regression tests Normalize_ConstrainsSpotXInterpolatedFieldsToAllowlistsOrIntegers and BuildSpotXParams_OnlyInterpolatesKnownSafeNormalizedFields (both PowerShell paths) fail if a new free-form interpolation is added without updating this contract.

LibreSpot runs its own generated scripts, SpotX, and the watcher task with -ExecutionPolicy Bypass. PowerShell execution policy is a safety feature, not a security boundary (Microsoft docs), it stops accidental script execution, it does not stop a determined user, and bypassing it does not weaken any enterprise control. In particular, -ExecutionPolicy Bypass does not defeat AppLocker or Windows Defender Application Control (WDAC), which enforce PowerShell ConstrainedLanguage mode regardless of execution policy.

On a host where application control is enforced, LibreSpot's scripts (or the SpotX child process) may be blocked. LibreSpot diagnoses this rather than presenting it as a generic failure: at run start it logs the PowerShell edition, version, language mode, and execution-policy scopes (Get-PowerShellSecurityContext), warns when the host is already in ConstrainedLanguage, and classifies app-control errors in spawned-process output (Test-IsLanguageModeOrAppControlError). The guidance is always to ask an administrator to allow LibreSpot/SpotX, never to weaken application control.