@avlidienbrunn discovered that forms submitted using XHR are not subject to the
form-action Content Security Policy (CSP) directive and might be used to exfiltrate information to any host found in our
connect-src source list. While most forms on GitHub.com are submitted traditionally, and restricted by our
form-action source list, we do register a number of
onsubmit event handlers that result in forms being submitted using XHR. As a result, an attacker can target any form we submit using XHR and potentially exfiltrate some of the form’s contents, such as its CSRF token, to any host found on our
connect-src source list.
The overall risk presented by this CSP bypass is low given that:
connect-srcsource list, the providers on that list may ignore the unexpected form values, making it potentially impossible for an attacker to recover them.
We have not addressed this issue given the low severity and our current reliance on several third-party hosts in our
connect-src source list. We will continue to investigate what new browser protections may become available in the future to help mitigate this issue.
@avlidienbrunn discovered a flaw in our validation of URLs used for redirection when processing an OAuth authorization request. Unlike other browsers, Internet Explorer and Edge URL decode certain characters found in the host component of a HTTP 302 response
Location header. An attacker could have exploited this flaw against Internet Explorer and Edge users to redirect users from GitHub.com to another site and gain access to an OAuth application as another user. We addressed this by restricting the characters that can exist within the host component of the
redirect_uri request parameter.
@avlidienbrunn reported an issue where certain GitHub.com endpoints could serve a response that would be interpreted by Adobe Reader as a PDF file when embedded on an attacker’s domain. Because Adobe products do not respect the same-origin policy or the
X-Content-Type-Options header, the PDF calculator APIs implemented by Adobe Reader could be used to make authenticated HTTP requests to GitHub.com. This could be exploited to disclose the authenticated user’s data to the attacker’s domain.
This vulnerability is mitigated by the fact that a user needs to make significant configuration changes to use Adobe Reader in modern browsers for inline rendering of PDFs. Other PDF renderers are not affected by this vulnerability.
While the underlying vulnerability lies with Adobe Reader, we mitigated the issue by stripping bytes matching PDF file headers from affected endpoints. We are also continuing our effort to move user-provided content to the sessionless
We strongly discourage using Adobe Reader. Google Chrome, FireFox, and Safari have built-in PDF renderers that are not vulnerable to this style of attack.
The ability to use PDF for this style of attack was originally identified by Alex Inführ in this blogpost.
@avlidienbrunn discovered a flaw in our parsing of URLs used for redirection when processing an OAuth authorization request. An attacker could have exploited this flaw on a limited number of OAuth applications to redirect users from GitHub.com to another site and gain access to an OAuth application as another user.
An OAuth application was only vulnerable to this flaw if it is hosted on a third-party provider that allows customers to map arbitrary domains names to their hosting service. For example, let us say that an OAuth application is configured on
https://YourOauthApp.com and it has a CNAME record that maps this domain to a hosting provider. If the hosting provider supports it, an attacker could register
https://YourOauthApp.com.. on the same provider and it would have been considered a valid OAuth redirection URL by GitHub. We have addressed this issue by improving our redirect URL checking.
@avlidienbrunn reported an issue where user-supplied HTML elements with
document.querySelector to return the image element rather than the
We addressed this issue by prefixing all user-supplied
name attributes in markup with