Sparkle's AppInstaller post-stage-1 XPC listener accepts unvalidated connections, allowing spoofed appcast item data injectionGHSA-g3hp-f6mg-559v
MEDIUMGHSA-g3hp-f6mg-559v is a medium-severity (CVSS 4.2) Missing Authentication vulnerability in github.com/sparkle-project/Sparkle. No vendor fix is recorded yet; mitigation options are listed below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-g3hp-f6mg-559v.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-g3hp-f6mg-559v by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/sparkle-project/SparkleReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects SwiftURL packages — download data is not available via public APIs for these ecosystems.
Description
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 (
_willCompleteInstallationis set). - The app responsible for updating the bundle crashes or is forcefully quit before it has a chance to send
SPUSentUpdateAppcastItemDatato 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>-spkiMach service - no code-signing validation is enforced - and sends a spoofedSPUSentUpdateAppcastItemDatamessage containing an attacker-craftedSUAppcastItem. - A Sparkle-aware app that checks for updates on the bundle being updated launches before installation completes. The progress agent re-broadcasts the spoofed
SUAppcastItemon its<bundleId>-spksstatus 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦SwiftURL | github.com/sparkle-project/Sparkle | all versions | No fix |
Affected Products
sparklesparkle-projectDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/sparkle-project/Sparkle, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of github.com/sparkle-project/Sparkle has shipped for GHSA-g3hp-f6mg-559v yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-g3hp-f6mg-559v in your dependencies?
Find it across SwiftURL, including transitive dependencies.