Security notice for EAS Submit

This is a security notice about a remote code execution vulnerability in EAS Submit that was reported to us and has been fixed. The vulnerability was reported by Xavier Bruni from Deribit and his clear explanation helped us mitigate it quickly. Additionally, we found no evidence the vulnerability had been exploited before Xavier's report and appreciate his responsible disclosure.

EAS Submit uses a program called Fastlane, which did not escape some of its inputs before invoking shell commands to upload iOS apps to the store. Specifically, fields of the API key such as the key ID and issuer ID were not escaped; setting one of these fields to a value like | echo 1 | would print "1".

Additionally, EAS Submit used a shared VM for submission jobs. This means if a submission job were to execute arbitrary shell commands, it could access data from another submission job. This is obviously very serious and warranted an immediate fix.

We received the report on January 24 and upon confirming the vulnerability, we disabled the iOS submission service and announced its downtime. Within the next half hour we deployed a hotfix, confirmed that the vulnerability was no longer reproduceable, and enabled the service again. The fix was to patch Fastlane and properly escape inputs with String#shellescape. At this point, the immediate vulnerability was fixed.

For defense in depth, we also added stricter validation of inputs like the key ID and issuer ID to disallow strings that could be misinterpreted as part of a shell command. However, we also saw a longer-term need to eliminate the risk of another shell-injection vulnerability appearing in a new version of Fastlane or any other program used by EAS Submit.

To structurally secure EAS Submit, we switched to running each submission job in its own ephemeral VM instead of using a shared VM. This change was deployed on February 22. In addition to having their own file system and memory, each VM's network is isolated so VMs cannot involuntarily communicate with each other. Altogether, this provides a high level of isolation between submissions and a durable security model.

Upon receiving the report, we searched our databases for any evidence of its being exploited and found none. We believe it is very unlikely the vulnerability was exploited. However, this doesn’t eliminate the possibility that in the past before our log retention period, an attacker could have exploited the vulnerability and removed their malicious inputs. The most sensitive information that could have been accessed in the event of an attack is your ASC API key.

You can revoke your existing ASC API key and create a new one on the App Store Connect website (Users and Access → Integrations → App Store Connect API → Team Keys). Then, manage your EAS account's keys on the Credentials page to remove your existing key from EAS and upload a new one.

Let us know how we can help by reaching out to us on Discord or through the website.