What is the CVSS score of CVE-2026-47122?

CVE-2026-47122 has a CVSS 3.1 base score of 4.2 (Medium). CVSS vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:L. EPSS exploitation probability: 0.0%.

Sparkle CVE-2026-47122

MEDIUM

Missing Authentication for Critical Function (CWE-306)

2026-05-29 https://github.com/sparkle-project/Sparkle

GHSA-g3hp-f6mg-559v

Authentication Bypass

4.2

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

4.2 MEDIUM

AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:L

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:L

Attack Vector

Local

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

None

Integrity

Low

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

May 29, 2026 - 20:17 vuln.today

Analysis Generated

May 29, 2026 - 20:17 vuln.today

DescriptionGitHub Advisory

Summary

AppInstaller post-stage-1 XPC listener accepts unvalidated connections, allowing spoofed appcast item data injection.

Details

Autoupdate/AppInstaller.m's shouldAcceptNewConnection: only enforces SUCodeSigningVerifier validateConnection: before stage 1 completes. After _performedStage1Installation = YES, new connections to the registered Mach service <bundleId>-spki are accepted from any local process without team-ID or code-signing checks.

The following chain of events enables an attacker to inject a spoofed SPUSentUpdateAppcastItemData payload:

Installer finishes unarchiving the update successfully (_willCompleteInstallation is set).
The app responsible for updating the bundle crashes or is forcefully quit before it has a chance to send SPUSentUpdateAppcastItemData to the installer. There is no user interaction between the prior step and this one, so the timing window is tight.
After stage 1 of the installer is performed (_performedStage1Installation = YES), but before final installation completes (since all services are cleaned up by then), an attacker process connects to the <bundleId>-spki Mach service - no code-signing validation is enforced - and sends a spoofed SPUSentUpdateAppcastItemData message containing an attacker-crafted SUAppcastItem.
A Sparkle-aware app that checks for updates on the bundle being updated launches before installation completes. The progress agent re-broadcasts the spoofed SUAppcastItem on its <bundleId>-spks status service, and the launching app displays attacker-controlled release notes (name, version, critical flag).

Note: Sparkle can be used to update other app bundles, so the "app doing the updating" and the "app being updated" are not necessarily the same bundle.

In the system-domain case (SPUUsesSystemDomainForBundlePath = true), the AppInstaller runs as root via SMJobSubmit to kSMDomainSystemLaunchd, and the Mach service is reachable by any local user process.

Affected versions: 2.x branch including 2.9.1.

Impact

A local user-level process can inject a forged SUAppcastItem (arbitrary name, version, critical flag) into the progress agent's status broadcast. Other Sparkle-aware clients on the system will display attacker-controlled release notes as authoritative installation state.

The integrity of the installed code is not affected - the bundle moved into place is the legitimate, signature-validated update from stage 1. The impact is limited to UI spoofing of installation metadata.

Remediation

Enforce SUCodeSigningVerifier validateConnection: on all new connections regardless of installation stage, or disallow SPUSentUpdateAppcastItemData after the active connection invalidates.

AnalysisAI

UI spoofing via XPC authentication bypass in Sparkle 2.x (through 2.9.1) allows a local low-privileged attacker to inject forged appcast metadata into the update progress broadcast, causing any Sparkle-aware application to display attacker-controlled release notes, version strings, and critical-update flags. The attack exploits a post-stage-1 regression in the AppInstaller's Mach service authentication: once _performedStage1Installation is set, code-signing validation is silently dropped for new connections to the <bundleId>-spki service. Critically, installed code integrity is not compromised - only the UI metadata displayed to users is affected. No public exploit or CISA KEV listing has been identified at time of analysis.

Technical ContextAI

Sparkle is a widely-used macOS software update framework (pkg:swift/github.com_sparkle-project_sparkle) that communicates between installer and host applications via XPC over named Mach services. The vulnerable component is Autoupdate/AppInstaller.m, specifically the shouldAcceptNewConnection: delegate method on the <bundleId>-spki Mach service. CWE-306 (Missing Authentication for Critical Function) precisely describes the root cause: authentication via SUCodeSigningVerifier validateConnection: is enforced conditionally only before stage 1 completes (_performedStage1Installation = NO), creating a post-stage-1 window where any local process can connect without team-ID or code-signing validation. In the system-domain configuration (SPUUsesSystemDomainForBundlePath = true), AppInstaller runs as root via SMJobSubmit to kSMDomainSystemLaunchd, making the Mach service reachable by any local user. The spoofed SPUSentUpdateAppcastItemData message is re-broadcast by the progress agent on the <bundleId>-spks status service, propagating attacker-controlled SUAppcastItem data (name, version, critical flag) to all subscribing Sparkle clients.

RemediationAI

No vendor-released patch has been identified at time of analysis - the GitHub advisory lists fixed version as None for Sparkle <= 2.9.1. Upstream recommends two code-level fixes: enforcing SUCodeSigningVerifier validateConnection: on all new connections to the <bundleId>-spki Mach service regardless of _performedStage1Installation state, or disallowing processing of SPUSentUpdateAppcastItemData messages after the original active connection invalidates. Until a patched release is available, application developers embedding Sparkle 2.x should consider avoiding SPUUsesSystemDomainForBundlePath = true where not strictly required, which limits the Mach service to user-session scope rather than system-wide accessibility and reduces the attacker surface to same-user processes. Operators cannot patch this at the OS level - remediation requires Sparkle framework maintainers to issue a fix and downstream app developers to adopt it. Monitor the advisory at https://github.com/sparkle-project/Sparkle/security/advisories/GHSA-g3hp-f6mg-559v for patch availability.