CVE-2026-47122: 
Swift vulnerability analysis and mitigation

CVE-2026-47122 is a missing authentication vulnerability in the Sparkle software update framework for macOS that allows a local attacker to inject spoofed appcast item data into the update progress agent's status broadcast. The flaw affects all versions of Sparkle up to and including 2.9.1 (the 2.x branch). It was first published by maintainer zorgiepoo on May 19, 2026, and added to the GitHub Advisory Database on May 29, 2026. As of the time of publication, no patched version is available. The vulnerability carries a CVSS v3.1 base score of 4.2 (Medium) (GitHub Advisory, Sparkle Advisory).

The root cause is classified as CWE-306 (Missing Authentication for Critical Function) and CWE-441 (Unintended Proxy or Intermediary / Confused Deputy). In Autoupdate/AppInstaller.m, the shouldAcceptNewConnection: method only calls SUCodeSigningVerifier validateConnection: to authenticate connecting processes before stage 1 of installation completes. Once _performedStage1Installation is set to YES, the registered Mach service <bundleId>-spki accepts connections from any local process without enforcing team-ID or code-signing validation. An attacker must time their connection to occur after stage 1 completes but before final installation cleanup — a narrow window that requires the legitimate updating app to crash or be forcefully terminated before it can send SPUSentUpdateAppcastItemData. In the system-domain case (SPUUsesSystemDomainForBundlePath = true), the AppInstaller runs as root via SMJobSubmit to kSMDomainSystemLaunchd, making the vulnerable Mach service reachable by any local user process (GitHub Advisory, Sparkle Advisory).

A local, low-privileged attacker can inject a forged SUAppcastItem (with arbitrary name, version, and critical flag) into the Sparkle progress agent's status broadcast via the -spks service, causing other Sparkle-aware applications on the system to display attacker-controlled release notes as authoritative installation state. Critically, the integrity of the installed code is not compromised — the binary moved into place is the legitimate, signature-validated update from stage 1. The impact is therefore limited to UI spoofing of installation metadata, with low integrity and low availability impact and no confidentiality impact (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of publication. The EPSS score is approximately 0.014% (0.000140), indicating a very low probability of exploitation in the near term. The NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable, reflecting the tight race-condition timing window required. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Sparkle Advisory).

1. Reconnaissance: Identify macOS systems running applications that embed the Sparkle framework (version ≤ 2.9.1) and that use SPUUsesSystemDomainForBundlePath = true for broader Mach service accessibility.
2. Trigger update process: Wait for or induce a Sparkle-managed software update to begin on the target system, so that AppInstaller starts and begins stage 1 installation (unarchiving the update).
3. Crash or kill the updating app: Forcefully terminate the application responsible for the update (e.g., via kill -9) before it can send SPUSentUpdateAppcastItemData to the installer. This must occur after _willCompleteInstallation is set but before the legitimate app sends its appcast item data.
4. Connect to the unprotected Mach service: After _performedStage1Installation = YES is set, connect a local attacker-controlled process to the <bundleId>-spki Mach service. No code-signing or team-ID validation is enforced at this stage.
5. Inject spoofed payload: Send a crafted SPUSentUpdateAppcastItemData message containing a forged SUAppcastItem with attacker-controlled fields (e.g., arbitrary app name, version string, or critical update flag).
6. Observe UI spoofing: The Sparkle progress agent re-broadcasts the spoofed SUAppcastItem on its -spks status service. Any Sparkle-aware app that launches and checks for updates on the bundle being updated will display the attacker-controlled release notes as authoritative installation state (GitHub Advisory, Sparkle Advisory).

• Process: Unexpected local processes connecting to Mach services named <bundleId>-spki that are not the legitimate Sparkle updater or the application being updated; processes sending SPUSentUpdateAppcastItemData messages without a valid team-ID.
• Logs: macOS system logs (via log show or Console.app) showing Mach service connections to <bundleId>-spki from unsigned or unexpected processes during a Sparkle update window; entries indicating SUCodeSigningVerifier validateConnection: was not invoked for a new connection.
• Behavioral: Applications displaying update release notes with unexpected version numbers, names, or critical-update flags immediately following a Sparkle update cycle; the updating application (responsible for sending appcast data) terminating abnormally during an update (Sparkle Advisory).

As of the time of publication, no patched version of Sparkle is available for this vulnerability. The recommended remediation approach, per the advisory, is to enforce SUCodeSigningVerifier validateConnection: on all new connections to the -spki Mach service regardless of installation stage, or to disallow SPUSentUpdateAppcastItemData messages after the active connection invalidates. Application developers embedding Sparkle should monitor the sparkle-project/Sparkle repository for a patched release and update as soon as one becomes available. As a temporary measure, organizations can restrict local process execution on sensitive macOS systems to reduce the attack surface (GitHub Advisory, Sparkle Advisory).

The vulnerability was reported by security researcher fg0x0 and published by Sparkle maintainer zorgiepoo. No significant public commentary, media coverage, or social media discussion has been identified beyond the GitHub advisory itself. The moderate severity rating and limited real-world impact (UI spoofing only, no code execution) have likely contributed to the low public profile of this disclosure.