Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessExtract distributed private key from app
-
DeliveryDerive full signing keypair
-
ExploitEstablish MITM or compromise Capgo server
-
ExecutionCraft validly signed malicious update bundle
-
PersistDevice installs forged update
-
ImpactAttacker code runs on device
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Key management controls
|
| Exploitation Conditions | Exploitation requires the attacker to obtain the client-distributed private signing key (trivially recoverable because it ships inside every downloaded app) AND to occupy one of two positions on the update path: an active man-in-the-middle on the network channel between the device and the Capgo update server, or compromise/control of the Capgo server itself. The affected feature is specifically the end-to-end encrypted/signed update mechanism of @capgo/capacitor-updater versions before 12.128.2 - apps not using capgo's OTA update signing are not exposed. Limiting factors: the MITM-or-server-control prerequisite (reflected as AC:H) means this is not exploitable purely remotely against an untouched device; transport protections such as TLS certificate pinning further raise the bar for the MITM variant. No target-device authentication or user interaction is required once the position is achieved (PR:N/UI:N). |
| Impact | This is a genuine integrity/software-supply-chain risk rather than a mere high-CVSS paper cut, but exploitation is gated. The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N) shows network reach with no privileges or user interaction, yet AC:H reflects that the attacker must first achieve a meaningful position - an active man-in-the-middle on the update channel or compromise of the Capgo server. Impact is skewed toward integrity (VI:H) with only limited confidentiality and availability (VC:L/VA:L), consistent with the core outcome being malicious-code installation rather than data theft or outage. No EPSS score, KEV entry, POC, or SSVC decision data was supplied, so probabilistic and active-exploitation signals are absent; the practical risk is that private-key distribution is a permanent, latent weakness in every deployed vulnerable version until the app is rebuilt with the fixed plugin. Net: prioritize for any app shipping this plugin, but the AC:H prerequisite means opportunistic mass exploitation is less likely than targeted attacks against the update path. |
| Exploit ScenarioDerived | An attacker extracts the embedded private key from a shipped app (or intercepts it) and, from a man-in-the-middle position on a shared/hostile network, serves a forged update bundle that carries a valid signature derived from the leaked keypair. The victim device accepts the bundle as authentic and installs attacker-controlled code; alternatively, an attacker who compromises the Capgo server pushes the malicious bundle to all devices at once. No POC has been published, and the CVSS AC:H reflects the need to establish the MITM/server-control position first. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 10, 2026
Update-signing bypass in @capgo/capacitor-updater (capgo OTA plugin for Capacitor apps) before 12.128.2 undermines its end-to-end encryption by shipping the same private key to every device that downloads the app. Because the public verification key can be derived from that distributed private key, an attacker with a man-in-the-middle position or control of the Capgo delivery server can forge a validly signed update bundle and push attacker-controlled code to devices. Reported by VulnCheck with a CVSS 4.0 base score of 8.3; no public exploit identified at time of analysis and it is not listed in CISA KEV.
RemediationAI
Vendor-released patch: upgrade @capgo/capacitor-updater to 12.128.2 or later, then rebuild and re-release the mobile app so devices carry the corrected key-handling logic; note that because the private key was already distributed with vulnerable builds, you should also treat the old signing keypair as compromised and rotate to a freshly generated keypair rather than reusing existing keys. Follow the vendor guidance in GHSA-j2f4-4pfc-p8rx (https://github.com/Cap-go/capgo/security/advisories/GHSA-j2f4-4pfc-p8rx) and the VulnCheck writeup (https://www.vulncheck.com/advisories/capacitor-updater-end-to-end-encryption-bypass-via-private-key-distribution). Until app updates propagate, reduce the man-in-the-middle exposure by enforcing TLS certificate/public-key pinning on the update endpoint and serving updates only over hardened HTTPS (trade-off: pinning complicates future certificate rotation), and tighten access controls and monitoring on the Capgo delivery server to limit the server-compromise path (trade-off: operational overhead but no functional impact on end users). Disabling OTA updates entirely is the strongest stopgap but removes the ability to ship fixes out-of-band.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Capacitor Updater (capgo) is a live/over-the-air (OTA) update plugin for Ionic Capacitor mobile applications that lets developers ship JavaScript/web bundle updates without going through app-store review. To protect update authenticity it uses an end-to-end encryption/signing scheme intended to guarantee that only bundles produced by the original app maker are installed. The flaw is a key-management failure (CWE-320, Key Management Errors): rather than keeping the signing private key secret on the publisher side and distributing only the public key, the implementation distributes the private key to each downloading device. Since an asymmetric public key is mathematically derivable from its private key, possession of the client-side private material lets anyone reconstruct the full keypair and produce signatures that pass verification - collapsing the trust model to that of an unsigned channel. The single affected component is cpe:2.3:a:capacitor-updater:capacitor-updater, tagged as an Information Disclosure / Capacitor Updater issue.
Know when Capacitor Updater gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N
AC:H because the attacker must first achieve MITM or server compromise; PR:N/UI:N since no device-side privileges or interaction are needed; impact is integrity-dominant (I:H) with limited C/A from malicious-update installation.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
In @capgo/capacitor-updater (Cap-go/capgo) before 12.128.2, the end-to-end encryption scheme distributes the private key to each device that downloads the app. Because the public key can be derived from the private key, an attacker performing a man-in-the-middle attack or compromising the Capgo server can create a validly signed update bundle and cause devices to install an update not produced by the original app maker.
Executive ViewAI
The Capgo over-the-air update service for Capacitor mobile apps contains a cryptographic signing bypass allowing attackers with network access to push unauthorized code to all user devices. No public exploit identified at time of analysis. Organizations relying on Capgo for app distribution face widespread code execution risk across their entire deployed user base.
Implement network segmentation and traffic inspection for all Capgo update connections; enforce client-side TLS certificate pinning for update delivery; deploy runtime code integrity monitoring and anomaly detection on devices; establish expedited rollback procedures for compromised updates; restrict update frequency to reduce exposure window pending patch release.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-42879
GHSA-v24w-qp6p-4wjw
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB