|
| 1 | +date: '2026-08-05' |
| 2 | +sections: |
| 3 | + security_fixes: |
| 4 | + - | |
| 5 | + **HIGH**: A path traversal vulnerability allowed an unauthenticated attacker to delete the user storage directory on the GitHub Enterprise Server instance, including Git LFS objects, release assets, attachments, and avatars, via the unsanitized X-GitHub-Request-Id request header. Exploitation required network access to the instance and worked when private mode was enabled. GitHub has requested CVE ID [CVE-2026-17556](https://www.cve.org/cverecord?id=CVE-2026-17556) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). |
| 6 | + - | |
| 7 | + Some internal, auto-generated secrets were not redacted when users compiled a support bundle. |
| 8 | + bugs: |
| 9 | + - | |
| 10 | + `ghe-service-list` omitted unhealthy Nomad-backed services from its output on single-node and high-availability appliances. Stopped or failed services, such as `babeld` or `nginx`, appeared in neither the `active` nor `inactive` section. |
| 11 | + - | |
| 12 | + Administrators could not remove a node with `ghe-remove-node` when the provided hostname was a substring of another node hostname. |
| 13 | + - | |
| 14 | + When administrators generated a support bundle with `ghe-support-bundle` while OpenTelemetry was enabled, a VictoriaMetrics export failure could produce a corrupt bundle because a log message was sent to `stdout` instead of `stderr`. |
| 15 | + - | |
| 16 | + Organizations that had upgraded from GitHub Enterprise Server 3.15 to 3.17 and had previously added **Organization admin** to delegated bypass approvers experienced security configurations that displayed the **read** role in the bypass list dropdown. This display was misleading, and **read** users were not granted bypass approval permissions. |
| 17 | + - | |
| 18 | + On instances where a GitHub App listed the repositories for its installation through the REST API, response time and CPU usage on the appliance increased with the number of repositories the installation could access. For installations with access to many repositories, or on instances with large configuration sets, this could make these requests slow and contribute to sustained high CPU on the appliance. Repository configuration for these requests is loaded in a single batch instead of separately for each repository. |
| 19 | + - | |
| 20 | + On instances with large organizations, listing organization members (for example, via the `membersWithRole` GraphQL API connection) could be slow and consume excessive CPU because a permission check was evaluated for each member instead of once per organization. |
| 21 | + - | |
| 22 | + When a user deleted an organization that owned GitHub Apps, repositories owned by that organization were not deleted. |
| 23 | + - | |
| 24 | + Maintenance jobs did not correctly process very large repositories whose sizes exceeded the capacity of a 32-bit signed integer database column. |
| 25 | + changes: |
| 26 | + - | |
| 27 | + Improvements to authorization, migration APIs, and bug fixes supporting increased migration fidelity. |
| 28 | + - | |
| 29 | + To guard against rare image corruption caused by an unexpected restart or interruption during an upgrade, the integrity of Docker images is now verified after an upgrade completes. If a corrupted image is detected, a warning is logged so an administrator can recover it. |
| 30 | + - | |
| 31 | + The size limit for `ghe-migrator` exports (80GB uncompressed, 40GB compressed) has been removed. If disk space is a concern, site administrators can configure a limit of their choice with the `ENTERPRISE_MIGRATIONS_MAX_EXPORT_ARCHIVE_SIZE_GB` environment variable. |
| 32 | + - | |
| 33 | + Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. |
| 34 | + known_issues: |
| 35 | + - | |
| 36 | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. |
| 37 | + - | |
| 38 | + 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. |
| 39 | + - | |
| 40 | + 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 [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). |
| 41 | + - | |
| 42 | + On an instance with the HTTP `X-Forwarded-For` header configured for use behind a load balancer, all client IP addresses in the instance's audit log erroneously appear as 127.0.0.1. |
| 43 | + - | |
| 44 | + {% data reusables.release-notes.large-adoc-files-issue %} |
| 45 | + - | |
| 46 | + Admin stats REST API endpoints may time out on appliances with many users or repositories. Retrying the request until data is returned is advised. |
| 47 | + - | |
| 48 | + When following the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#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. |
| 49 | + - | |
| 50 | + Running a config apply as part of the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps. |
| 51 | + - | |
| 52 | + {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %} |
| 53 | + - | |
| 54 | + 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`. |
| 55 | + - | |
| 56 | + An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning. |
| 57 | + - | |
| 58 | + When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded. |
| 59 | + - | |
| 60 | + When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed. |
| 61 | + - | |
| 62 | + 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. |
| 63 | + - | |
| 64 | + In a cluster, the host running restore requires access to the storage nodes via their private IPs. |
| 65 | + - | |
| 66 | + On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue. |
| 67 | + - | |
| 68 | + 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. |
| 69 | + - | |
| 70 | + 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. |
| 71 | + - | |
| 72 | + Unexpected elements may appear in the UI on the repository overview page for locked repositories. |
| 73 | + - | |
| 74 | + 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. |
| 75 | + - | |
| 76 | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. |
| 77 | + - | |
| 78 | + Git versions are mismatched between containers on the instance. |
| 79 | + - | |
| 80 | + Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. |
![release-controller[bot]](https://avatars.githubusercontent.com/in/223695?v=4&size=40){kind=avatar}
0 commit comments