Enterprise Server 3.17 release notes

HIGH: An attacker could execute arbitrary code, potentially leading to privilege escalation and system compromise, by exploiting the pre-receive hook functionality to bind to dynamically allocated ports that become temporarily available (for example, during a hot patch upgrade). This vulnerability is only exploitable under specific operational conditions, such as during the hot patching process, and requires either site administrator permissions or a user with privileges to modify repositories containing pre-receive hooks. The initial fix for this issue was found to be incomplete, leaving the vulnerability exploitable in some cases. GitHub has requested CVE ID: CVE-2025-3509 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

The Management Console maintenance page would not load correctly if the underlying API call fails to load the connection services data.

On an instance with GitHub Actions configured to connect to Azure OIDC storage through a proxy, Actions logs and artifacts would not be properly stored.

Site administrators and auditors reviewing audit logs saw the mc_actor field was empty when a user signed out, because audit logging occurred after the user was removed from session state.

On instances with a large number of code scanning users, running ghe-config-apply previously resulted in slow performance.

During hotpatching, site administrators could encounter issues with the kernel partition table not updating correctly when running ghe-partition-setup. These users had to manually intervene in order to complete the upgrade process.

Users of GitHub Actions could not view or manage Actions artifacts and logs if the global AWS STS endpoint was unavailable, because Actions did not use the configured regional STS endpoint.

Fixed an edge case for certain Security Configurations that would not automatically work when transitioning to unbundled GitHub Advanced Security SKUs.

When users clicked and held on search suggestions in the search bar, they were not taken to the correct location.

Organization owners had no audit log events to track organization announcements displayed on banners in the UI.

If an Enterprise Managed User (EMU) pushed to their personal repository with both secret scanning and push protection enabled, the custom patterns defined at enterprise level were not being applied during the push protection scan.

On instances with dangling commit graph lock files, recompute checksum operations were unexpectedly triggered.

After an appliance reboot, code scanning did not always trigger or process analyses.

Site administrators who test the Prometheus endpoint can now use 127.0.0.1 as a trusted IP address. Previously, only specific IPs were allowed for testing.

To ensure critical integrations and automated systems have uninterrupted access, the /repositories/:repository_id/collaborators endpoints now honor the higher rate limits for exempt users set with ghe-config app.github.rate-limiting-exempt-users "<USER>".

Site administrators can now set rate limits for the WebSockets controller used for live updates, with ghe-config app.github.web-sockets-rate-limit. For more information, see Controlling the rate for the live update service.

Site administrators who manage dependencies with the base-pinned image should no longer rely on the vulcanizer CLI, as it is in the process of being retired and replaced with vulcancli. Transition to vulcancli to ensure continued support and compatibility.

Custom firewall rules are removed during the upgrade process.

During the validation phase of a configuration run, a No such object error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.

If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see "Problembehandlung beim Zugriff auf die Verwaltungskonsole."

In some situations, large .adoc files stored in a repository do not render properly in the web UI. The raw contents are still available to view as plaintext.

Admin stats REST API endpoints may timeout on appliances with many users or repositories. Retrying the request until data is returned is advised.

When following the steps for Replacing the primary MySQL node, step 14 (running ghe-cluster-config-apply) might fail with errors. If this occurs, re-running ghe-cluster-config-apply is expected to succeed.

Running a config apply as part of the steps for Replacing a node in an emergency may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.

When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running /usr/local/share/enterprise/ghe-es-search-repair.

When initializing a new GHES cluster, nodes with the consul-server role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.

Admins setting up cluster high availability (HA) may encounter a spokes error when running ghe-cluster-repl-status if a new organization and repositories are created before using the ghe-cluster-repl-bootstrap command. To avoid this issue, complete the cluster HA setup with ghe-cluster-repl-bootstrap before creating new organizations and repositories.

In a cluster, the host running restore requires to access the storage nodes via their private IP addresses.

On an instance hosted on Azure, comments made on an issue via email are not added to the issue.

After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running /usr/local/share/enterprise/ghe-es-search-repair on the appliance.

After a geo-replica is promoted to be a primary by running ghe-repl-promote, the actions workflow of a repository does not have any suggested workflows.

When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a 401 Unauthorized error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages.

Uploading a new license with unbundled GitHub Advanced Security may not fully unbundle all the Security Configurations on the instance in certain cases. Any active Security Configurations will continue to function, but when attempting to apply the configurations to new repositories you may see errors like "Advanced Security is not purchased" or Validation failed: Secret scanning non provider patterns. Non-provider patterns must be disabled when secret scanning is disabled. Contact GitHub Support for assistance clearing this state in version 3.17.1. This issue will be resolved in version 3.17.2.

Instance administration

• During the upgrade to 3.17, the database transitions will be run concurrently. You may notice the upgrade taking less time.

• GitHub Enterprise Server Backup Service is a managed backup solution built directly into the appliance. It provides simplified alternative to the backup-utils. The backup service is in public preview. See Informationen zum Sicherungsdienst für GitHub Enterprise Server.

Secret Protection and Code Security

• Users can secure code in their organizations and enterprises in an easier, more affordable, and scalable way to secure their code with the new standalone GitHub Advanced Security (GHAS) products: Secret Protection and Code Security. See Introducing GitHub Secret Protection and GitHub Code Security and GitHub Secret Protection and GitHub Code Security for GitHub Enterprise on the GitHub Blog.

  • Secret Protection is a security feature designed to detect and prevent the exposure of sensitive information, such as API keys, tokens, and passwords, in your code repositories. It includes tools like secret scanning, which identifies hardcoded secrets in your repositories, and push protection, which prevents developers from committing secrets to repositories in the first place. See Choosing GitHub Secret Protection
  • Code security is a security feature designed to help users identify, manage, and remediate vulnerabilities in their codebases, ensuring secure and compliant software development. It includes tools like code scanning, premium Dependabot features, and dependency review. See GitHub Code Security. Users on a GHAS subscription plans can transition at renewal time to a standalone subscription or a metered plan. Users on a Pay-as-You-Go plan can transition any time. See Billing models for Advanced Security products.

Secret Protection

• Organization owners can establish an approval process to control sensitive actions, such as restricting dismissal privileges of secret scanning alerts to designated individuals. This mitigates the risk of unauthorized changes and provides a documented record of bypass usage. See Delegated alert dismissal for code scanning and secret scanning now available in public preview on the GitHub Blog, and Einrichten eines Governanceframeworks für dein Unternehmen.

• Users can now access secret scanning scan events via the audit log and webhooks. Providing scan status visibility and reporting aims to enable users to independently diagnose unexpected scan behavior, as well as meet the auditing and compliance requirements of large enterprises by demonstrating scan activity. See Audit log and webhook events for secret scan completions on the GitHub Blog.

• The detection of Base64-encoded GitHub tokens is now generally available, which means that users have better visibility into any leaked PATs. See Secret scanning detects Base64-encoded GitHub tokens on the GitHub Blog.

• The "Experimental" tab name for alerts, which caused confusion by leading certain users to underestimate the importance of its alerts, has been renamed "Generic". This tab includes alerts for non-provider patterns, which are not necessarily low confidence alerts. See Renaming secret scanning experimental alerts to generic alerts.

• Enterprises can manage push protection bypass requests for secret scanning via the REST API, enabling integration with existing workflows for reviewing and triaging. Reviewers can retrieve and act on bypass requests at the organization or repository level using new endpoints. This functionality supports delegated bypass controls, allowing only authorized users to bypass push protection, while others must submit requests for approval. See the GitHub Blog post.

Code Security

• Organization owners can establish an approval process to control sensitive actions, such as restricting dismissal privileges of code scanning alerts to designated individuals This mitigates the risk of unauthorized changes and provides a documented record of bypass usage. See Delegated alert dismissal for code scanning and secret scanning now available in public preview on the GitHub Blog, and Einrichten eines Governanceframeworks für dein Unternehmen.

• Users can access and search audit logs for code scanning-related events. These logs capture events impacting enterprises or organizations, including code scanning activities such as alert creation, resolution, reopening, or appearance in a new branch. See Code scanning now creates alert-related events in audit log on the GitHub Blog.

• This release comes installed with version 2.20.7 of the CodeQL CLI, used in the CodeQL action for code scanning. Significant updates since the default version installed on GitHub Enterprise Server 3.16 include:

  • All experimental queries for C#, Java, and Kotlin have been promoted to the default query suite in the CodeQL community packs.
  • Full support for C# 13 and .NET 9, including coverage improvements to enhance alert detection and reduce false negatives.
  • Go 1.24 support, enabling analysis of the latest Go language features.
  • Java 24 support, with improvements to query accuracy for XSS and CSRF vulnerabilities.
  • JavaScript and TypeScript enhancements, including:
    • Optional response threat model to treat HTTP responses as tainted sources.
    • Improved precision for data flow through arrays and call resolution.
  • C/C++ improvements, including better accuracy for cpp/static-buffer-overflow.

Dependabot

• Users can automatically keep their bun, Docker Compose, and uv dependencies up to date with Dependabot version updates. See Supported ecosystems and repositories.

• Users can use EPSS scores to help prioritize dependency vulnerabilities based on exploit likelihood. Using EPSS scores allows users to address vulnerabilities that are more likely to be exploited, reducing the risk of actual attacks. See Dependabot helps users focus on the most important alerts by including EPSS scores that indicate likelihood of exploitation, now generally available.

• Developers using pnpm workspaces can ensure more reliable dependency updates with full Dependabot support for pnpm workspace catalogs. Dependabot prevents lockfile inconsistencies, avoids broken dependency trees, and improves update reliability in monorepos. See the GitHub blog post.

Identity and access management

• Automated user provisioning with the System for Cross-domain Identity Management (SCIM) standard is generally available. SCIM is a leading standard for user lifecycle management in SaaS applications. GitHub Enterprise Server instances using SAML authentication can enable SCIM to provision and manage user accounts from an identity provider (IdP). GitHub supports common integrations such as Entra ID and Okta, or you can use a custom SAML IdP and SCIM implementation to meet your organization's needs. You can configure SCIM using a supported IdP application or the SCIM REST API. See Konfigurieren von Benutzerbereitstellung mit SCIM auf GitHub Enterprise Server.

Authentication

• Fine-grained personal access tokens (PATs) and PAT lifetime policies are now generally available. These tokens offer improved security with per-organization access, token approval workflows, and better auditability through token ID tracking in audit logs. With lifetime policies you can also force the rotation of tokens on a configurable basis, helping drive down the use of long-lived PATs in your environment. See Fine-grained PATs are now generally available on the GitHub Blog.

Migrations

• Administrators can use the GHES Management Console to configure repository exports with local storage, reducing reliance on external blob storage and simplifying the migration process. Exports are stored on the GHES disk, and customers can choose how to provide the archive to GitHub Enterprise Importer, including using GitHub-owned blob storage.

Audit logs

• Audit log streaming of API requests targeting your enterprise's private assets is generally available.

Repositories

• Push rulesets are generally available. Users can block pushes to private and internal repositories, and their forks, based on file type, path, or size. Unlike pre-receive hooks, push rules are built-in, configurable via the UI or API, and support audit logs, evaluate mode, and bypass lists. See Informationen zu Regelsätzen.

• Enterprise administrators can manage rules more efficiently with the general availability of ruleset history, import, and export. Ruleset history allows tracking and rolling back changes, while import and export simplify sharing and reusing rulesets, including GitHub's ruleset-recipes. See github/ruleset-recipes.

• Repository administrators can easily convert a fork into a standalone repository by leaving the fork network, which stops automatic syncing with the upstream repository. This is useful for taking a project in a new direction or maintaining separate versions.

• Users can more easily explore contributors and code frequency insights with improved navigation, interactive chart legends for hiding data series, and options to view or download the data as a CSV or PNG. See Repositories - Updated insight views (General Availability) on the GitHub Blog.

Pull requests

• The refreshed pull request commits page is generally available. The updated page improves performance, aligns with GitHub's design system, and offers better accessibility.

Gist

• Users can moderate comments on gists by turning them off or deleting unwanted entries. See Moderieren von Gist-Kommentaren.

Commits

• Verified commits are attached to persistent verification records, allowing users to identify the first actor to introduce a commit to a repository. Users can rotate, expire, or revoke their signing key without impacting existing verifications.

  Verification records consume approximately 80 bytes on disk per signed commit. To limit data growth on large instances, site administrators can run ghe-config app.persist-commit-signature-verification.enabled false to disable persistent records.

GitHub Mobile

• GitHub Mobile users can quickly view their recent projects by clicking the Projects view from the Home screen.

• GitHub Mobile supports additional functionality when connected to instances running GitHub Enterprise Server 3.17:

  • Compare branches: View and compare changes between branches directly from your mobile device.
  • Fork repositories: Fork public repositories in the mobile app.
  • Projects: Access and interact with GitHub Projects on the go.

Integrations and extensions

• GitHub App developers can improve security with a 25-key limit per app, encouraging safer key management practices. Apps exceeding the limit must delete excess keys before adding new ones. Additionally, scoped tokens can access more repositories. See Verwalten privater Schlüssel für GitHub-Apps.

• Enterprise owners can centrally manage and share GitHub Apps across all organizations in their enterprise by creating enterprise-owned GitHub Apps. This eliminates the need to duplicate apps or make them public, reducing management overhead and improving security. Private and internal apps can be transferred to the enterprise level, with permission updates automatically applied across all organizations. Only internal visibility is supported, meaning only users and organizations within the enterprise can install and authorize these Apps. See Erstellen von GitHub-Apps für Ihr Unternehmen.

Fetches from repository caches returned a "Repository not found" error when the cache is out of sync. [Updated: 2025-06-19]

SAML response processing includes additional validation and schema checks. We recommend testing your SAML configuration on an upgraded staging appliance before upgrading your production appliance. See the SAML configuration guide for details on the required pieces of data, Referenz zur SAML-Konfiguration.

Users see a horizontal navigation bar at the top of their enterprise account. This update is designed to improve the user experience by providing a consistent, intuitive navigation structure that mirrors the rest of the GitHub experience.

Custom firewall rules are removed during the upgrade process.

During the validation phase of a configuration run, a No such object error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.

If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. See Problembehandlung beim Zugriff auf die Verwaltungskonsole.

In some situations, large .adoc files stored in a repository do not render properly in the web UI. The raw contents are still available to view as plaintext.

Admin stats REST API endpoints may timeout on appliances with many users or repositories. Retrying the request until data is returned is advised.

When following the steps for Replacing the primary MySQL node, step 14 (running ghe-cluster-config-apply) might fail with errors. If this occurs, re-running ghe-cluster-config-apply is expected to succeed.

Running a config apply as part of the steps for Replacing a node in an emergency may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.

When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a nightly scheduled job. It can also be forced by running /usr/local/share/enterprise/ghe-es-search-repair.

When initializing a new GHES cluster, nodes with the consul-server role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.

Admins setting up cluster high availability (HA) may encounter a spokes error when running ghe-cluster-repl-status if a new organization and repositories are created before using the ghe-cluster-repl-bootstrap command. To avoid this issue, complete the cluster HA setup with ghe-cluster-repl-bootstrap before creating new organizations and repositories.

In a cluster, the host running restore requires access the storage nodes via their private IPs.

On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue.

After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running /usr/local/share/enterprise/ghe-es-search-repair on the appliance.

After a geo-replica is promoted to primary by running ghe-repl-promote, the actions workflow of a repository does not have any suggested workflows.

When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a 401 Unauthorized error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages.

Uploading a new license with unbundled GitHub Advanced Security may not fully unbundle all the Security Configurations on the instance in certain cases. Any active Security Configurations will continue to function, but when attempting to apply the configurations to new repositories you may see errors like "Advanced Security is not purchased" or Validation failed: Secret scanning non provider patterns Non-provider patterns must be disabled when secret scanning is disabled. Contact GitHub Support for assistance clearing this state in version 3.17.0. This issue will be resolved in version 3.17.2.

In GitHub Enterprise Server 3.20, GitHub will retire the security manager API in favor of the organization roles API. See the GitHub Blog.

Microsoft Exchange Online is retiring SMTP basic authentication in September 2025. If your GitHub Enterprise Server instance uses this method to send email, delivery may fail after the retirement date. Microsoft recommends switching to a supported alternative. As another option, you may consider using an SMTP OAuth proxy such as email-oauth2-proxy, though this is not officially supported. For details and configuration guidance, see the Microsoft announcement and the proxy’s documentation.

Real-time job status updates for GitHub Actions workflow notifications in Slack and Microsoft Teams are no longer available. Users still receive notifications when a workflow starts and completes, but intermediate job progress updates have been removed to improve system efficiency.

In GitHub Enterprise Server 3.17, tag protection rules will be migrated to a ruleset, and the tag protection rule feature will no longer be available.

Dependabot is no longer supporting Python 3.8, which has reached its end-of-life. If you continue to use Python 3.8, Dependabot will not be able to create pull requests to update dependencies. If this affects you, we recommend updating to a supported release of Python. As of February 2025, Python 3.13 is the newest supported release.

Dependabot is no longer supporting NPM version 6, which has reached its end-of-life. If you continue to use NPM version 6, Dependabot will be unable to create pull requests to update dependencies. If this affects you, we recommend updating to a supported release of NPM. As of December 2024, NPM 9 is the newest supported release.