The 2.8 series release notes contain important changes in this release series.
SAML authentication bypass in GitHub Enterprise
A CRITICAL issue was identified that allows an attacker to bypass SAML authentication by creating a fake response. This could allow the attacker to sign in as any user, including administrators.
The affected supported versions are:
- 2.8.0 - 2.8.5
- 2.7.0 - 2.7.9
- 2.6.0 - 2.6.14
- 2.5.0 - 2.5.19
If you are using SAML as your authentication method, we strongly recommend upgrading your GitHub Enterprise appliance to the latest patch release in your series, GitHub Enterprise 2.8.6, 2.7.10, 2.6.15, or 2.5.20.
Additionally, all existing user sessions should be destroyed:
-
Put your GitHub Enterprise environment in Maintenance Mode.
-
SSH to your primary GitHub Enterprise appliance.
-
Destroy the existing SAML sessions.
$ echo SAML::Session.destroy_all | ghe-console -y
-
Upgrade to the latest patch release in your series, GitHub Enterprise 2.8.6, 2.7.10, 2.6.15, or 2.5.20.
This vulnerability was reported through the GitHub Security Bug Bounty program and we have no evidence that it has been exploited in the wild.
Please contact GitHub Enterprise Support if you have any questions.
Security Fixes
- CRITICAL: An attacker could bypass SAML authentication and log in as any other user.
- Packages have been updated to the latest security versions.
Bug Fixes
- Files uploaded to a repository through the web interface were saved in the wrong location if the target directory contained multi-byte characters.
- For teams synchronized to the same LDAP group, group members were inefficiently cached, leading to slower Team Synchronization job runs.
- When configured with more than one group, there was an extra comma in the list of restricted LDAP groups in the site admin user search page.
- The
babeld
, codeload
, and ruby
processes could crash.
Changes
- We now only save a single core file per process, so multiple crashes of the same process use less disk space.
Known Issues
- We incorrectly redirect to the dashboard if you accessed GitHub Enterprise using an alias while in private mode. This might happen if you set a fully qualified domain name but the subdomain resolves correctly.
- Images uploaded to issues save with an absolute URL, so they can be broken if the hostname changes.
- On a freshly set up GitHub Enterprise without any users, an attacker could create the first admin user.
- Custom firewall rules aren't maintained during an upgrade.
- Enqueued background jobs are sometimes not purged when a repository is deleted.
svn checkout
may timeout while the repository data cache is being built. In most cases, subsequent svn checkout
attempts will succeed.
- Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.
- GitHub Enterprise clustering can not be configured without https.
- Attempting to convert a user to an organization fails with an internal server error.
- Graphs in the Management Console monitoring page are incorrectly sorted. (updated 2017-01-18)
- The initial import of the VMware OVA image may fail when deployed via vCenter Server 6.0 or 6.5. The import will succeed when performed directly on an ESXi host. (updated 2017-02-23)
- Git LFS objects may take up to an hour to replicate in a High Availability configuration. (updated 2017-02-23)
- collectd metric paths can be truncated, which causes multiple write attempts to the same file for different metrics. (updated 2017-07-10)
- After changing the visibility of a repository, wiki search results have a conflicting number of displayed search results. Administrators can reindex the wiki through the site admin dashboard. (updated 2017-11-09)
Thanks!
The GitHub Team