Many Flaws in Capacitor Live-Update Service Capgo (CVE-2026-56237 and More)

Top/Articles/Many Flaws in Capacitor Live-Update Service Capgo (CVE-2026-56237 and More) — Update to v12.128.2 Now

News Updated today

Makoto Horikawa

Backend Engineer / AWS / Django

2026.06.248 min0 views

Share X Hatena LINE LinkedIn RSS

Key takeaways

Capgo, a service that updates a mobile app's contents instantly without app-store review, has been found to contain many vulnerabilities from weak authentication. CVE-2026-56237 and others; the most severe is CVSS 9.1. Attackers could take over accounts and organizations and tamper with the updates pushed to apps. Versions 12.128.1 and earlier are affected; update to 12.128.2 or later.

Capgo, a service that lets mobile apps update their contents instantly without waiting for app-store review, has been found to contain many vulnerabilities (software flaws) stemming from weak authentication (identity checks) and permission handling. The most serious is CVE-2026-56237, with a severity of 9.1 out of 10 (Critical).

All of them affect versions 12.128.1 and earlier. They were investigated by the U.S. security firm VulnCheck and disclosed together in June 2026. The fixes are included in 12.128.2 and later. They include a flaw that lets an attacker mint API keys (the keys used to operate the service) without permission and others that allow taking over another user's account or organization. Because the updates delivered to apps could be tampered with, anyone running their own Capgo instance needs to update right away.

What kind of service is Capgo?

Capgo is a service that gives mobile apps built with Capacitor the ability to update their contents without going through app-store review. Capacitor is a development framework, published by Ionic, for building iPhone and Android apps using the same technologies as websites (HTML, CSS, JavaScript).

Normally you must wait for App Store or Google Play review each time you fix a bug, but with Capgo you can deliver UI-level fixes to users' devices in minutes. This "swap the contents without review" mechanism is known in the industry as a live update (OTA update). Convenient as it is, if the delivery mechanism is hijacked, an attacker could push arbitrary code to users' devices.

According to Capgo's official site, more than 3,500 companies use it, over 1,700 apps run it in production, and updates have been delivered to over 50 million devices. The component embedded in the app (the plugin) is published as open source (distributed via npm), and you can either use the "Capgo Cloud" that Capgo operates or run it on your own server (self-hosting). The vulnerabilities this time are concentrated in that server-side mechanism.

Who targets it, what they do, and what happens

Most of the weaknesses this time are lax checks on the Capgo server side about "who is allowed to do what." The most dangerous are the gaps that permit actions without confirming who the requester actually is.

The target is an attacker who wants to take over the account, or the operating key (API key), of a developer that distributes apps through Capgo. This includes someone who wants to slip malicious code into an app and spread it to users, or a competitor or insider who already holds some privileges on Capgo. With the most serious flaw, CVE-2026-56237, even an outside third party who is not logged in at all can forge an API key.

What the attacker does is mint API keys without permission, or impersonate another user's account or organization, to seize control of the app's update delivery. Because Capgo is a service for "swapping an app's contents after the fact," whoever controls delivery may reach the devices of the ordinary users on the other end.

If the damage becomes real, end users of the app could receive tampered updates or have their registered information stolen. For the company running the app, it can mean losing both control of its release pipeline and its customer data, going straight to a matter of trust. Vulnerabilities that begin to be used in real attacks can be added to the U.S. agency CISA's "list of vulnerabilities under active attack"; we maintain a Japanese-language overview in our CISA KEV Dashboard (Japanese edition).

What the main vulnerabilities are

What VulnCheck published this time is not a single flaw but a cluster of dozens of issues, centered on authentication and authorization. The GitHub Advisory Database also lists the Capgo-related entries together. Here we cover three with high severity and clear impact. All are fixed in 12.128.2.

CVE-2026-56237: API keys can be forged without logging in (CVSS 9.1, Critical)

This is the most serious flaw. According to VulnCheck's description, in the API-key generation mechanism the key information was exposed in front-end (client-side) traffic, and the server-side validation was also insufficient. As a result, an outside third party can mint their own API key without permission simply by tampering with request values. With the minted key, they could access features meant only for authorized people. The fact that it requires no login (unauthenticated) is what makes this flaw "Critical."

CVE-2026-56223: another user's account can be taken over (CVSS 8.7, High)

This flaw concerns company-wide login federation (single sign-on). According to the published information, an attacker in a position to abuse an external login provider can forge a "login assertion" containing the victim's email address, trigger an account merge, and gain full access to the victim's account, organization, and data. The cause is that the system tied accounts together based on email match alone, without sufficiently verifying the domain (affiliation) of the login provider that requested the link.

CVE-2026-56232: a restricted key shakes off its limits (CVSS 8.8, High)

This flaw lets an API key (a subkey) that was supposed to have narrow privileges bypass those limits. In VulnCheck's description, for a subkey whose scope was limited to "only this organization, only this app," specifying a certain header (extra information attached to a request) causes that restriction to be ignored, and the operation runs with the privileges of the unrestricted parent key instead. A limited key that should have been safe to hand out could thus be used for operations beyond what was intended.

Beyond these three, the disclosure includes a string of server-side authorization flaws: viewing other companies' usage with only the public key, confirming an API key's validity and owner, and tampering with billing records. These are not unrelated to the way an app pulls in externally sourced components, and managing the third-party components you bring into development is worth revisiting alongside the ideas in our OSS supply-chain scanner overview.

A quick check of whether you are affected

These vulnerabilities are in Capgo's server side. So the right response depends on "how you use" Capgo. We separate the case of using the cloud that Capgo operates from the case of running it on your own server.

How you use it	Impact this time	What to do
Capgo Cloud (official hosting)	Server side is fixed by Capgo	Update the plugin, and inspect for suspicious API keys/members
Self-hosted (your own server)	12.128.1 and earlier affected	Top priority: update to 12.128.2+
Not using it	Not applicable	No action needed

For Capgo Cloud users, the server-side fix is applied on Capgo's side, but it is reassuring to inspect issued API keys, organization members, and any unfamiliar apps or channels. If you self-host, you are responsible for updating to 12.128.2 or later. Some minor issues were additionally fixed in later versions, so going all the way to the latest is the surest option.

What to do now

The top priority is to update Capgo to 12.128.2 or later. If you self-host, check your server-side version and raise it immediately if it is old. Even if you use Capgo Cloud, it is wise to update the plugin embedded in your app to the latest version.

Also, review your issued API keys once and revoke any you are not using. Because this disclosure includes flaws that let keys be minted without permission and restricted keys exceed their limits, taking inventory of keys is effective. If you use company-wide login federation (single sign-on), check for any unfamiliar account merges or unfamiliar members added to your organization. If there is any sign that a malicious update was delivered, trace the delivery history (bundle history), roll back to a legitimate version, and investigate the cause.

Summary

The series of vulnerabilities found in Capgo exploit lax server-side authentication and authorization. The most serious, CVE-2026-56237, is a Critical (CVSS 9.1) flaw that lets API keys be forged without logging in. CVE-2026-56223 allows taking over another user's account, and CVE-2026-56232 allows a restricted key to exceed its privileges. All affect 12.128.1 and earlier and are fixed in 12.128.2 and later.

Because Capgo is, by nature, a service that "swaps an app's contents without review," the impact of having its delivery mechanism seized is large. If you self-host, first check your version and, if it is old, update now. Cloud users should also inspect their API keys and organization members. If new vulnerabilities concerning Capgo emerge, we will track them by adding to this article.