Impact
This vulnerability could have allowed an attacker to gain write access to a GitHub repository (push to existing branches/tags or create new ones). This was due to our application mistakenly creating deploy keys with read and write access, instead of read-only access for GitHub. In order to exploit this vulnerability, a malicious user needs to be able to create a branch or open pull request on the repository, and trigger a build to the Read the Docs project.
Read the Docs Community (https://app.readthedocs.org) isn't affected by this vulnerability. For most projects on Read the Docs Business (https://app.readthedocs.com/) we were able to automatically migrate existing keys to read-only, for projects where we were unable to do this, owners should have received an email about the steps to follow. We have resolved the issue, ensuring new deploy keys are read-only, and implemented safeguards to prevent exploitation of any remaining projects with deploy keys with write access.
This issue was discovered by a member of our team, and we have seen no signs that this vulnerability was exploited in the wild.
Custom installations
This vulnerability was present in our private version of Read the Docs, custom installations aren't affected.
Patches
This vulnerability has been patched with our 14.1.0 release.
Why did this happen?
We use the GitHub API to create deploy keys. This API accepts a read_only parameter, which defaults to false (write access) if not specified. Our code did not explicitly set this parameter, resulting in deploy keys being created with write access. GitHub used to support write access only keys in the past.
References
Other fixes have been applied in our private code, we can't share those patches publicly.
For more information
You can read more information about this issue in our blog post.
If you have any questions or comments about this advisory, email us at [email protected] (PGP)
stsewd Finder
Impact
This vulnerability could have allowed an attacker to gain write access to a GitHub repository (push to existing branches/tags or create new ones). This was due to our application mistakenly creating deploy keys with read and write access, instead of read-only access for GitHub. In order to exploit this vulnerability, a malicious user needs to be able to create a branch or open pull request on the repository, and trigger a build to the Read the Docs project.
Read the Docs Community (https://app.readthedocs.org) isn't affected by this vulnerability. For most projects on Read the Docs Business (https://app.readthedocs.com/) we were able to automatically migrate existing keys to read-only, for projects where we were unable to do this, owners should have received an email about the steps to follow. We have resolved the issue, ensuring new deploy keys are read-only, and implemented safeguards to prevent exploitation of any remaining projects with deploy keys with write access.
This issue was discovered by a member of our team, and we have seen no signs that this vulnerability was exploited in the wild.
Custom installations
This vulnerability was present in our private version of Read the Docs, custom installations aren't affected.
Patches
This vulnerability has been patched with our 14.1.0 release.
Why did this happen?
We use the GitHub API to create deploy keys. This API accepts a
read_onlyparameter, which defaults tofalse(write access) if not specified. Our code did not explicitly set this parameter, resulting in deploy keys being created with write access. GitHub used to support write access only keys in the past.References
Other fixes have been applied in our private code, we can't share those patches publicly.
For more information
You can read more information about this issue in our blog post.
If you have any questions or comments about this advisory, email us at [email protected] (PGP)