5.yml

date: '2026-04-21'
sections:
  security_fixes:
    - |
      **HIGH**: An attacker could gain unauthorized access to private repositories by abusing scoped user-to-server (`ghu_`) tokens after their associated GitHub App installation was revoked or deleted. In certain cases, the authorization layer could incorrectly fall back to a global installation context instead of rejecting the request, allowing the token to access resources outside its intended installation or repository scope. This issue could be chained with weaknesses in token revocation timing and SSH push attribution to obtain a victim-scoped token and read private repository contents without victim interaction. GitHub has requested CVE ID [CVE-2026-5845](https://www.cve.org/cverecord?id=CVE-2026-5845) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/).
    - |
      **HIGH**: An attacker could extract sensitive environment variables from a GitHub Enterprise Server instance through a timing side-channel attack against the notebook rendering service. When private mode was disabled, the notebook viewer followed HTTP redirects without revalidating the destination host, enabling an unauthenticated Server-Side Request Forgery (SSRF) to internal services. By measuring response time differences, an attacker could infer secret values character by character. GitHub has requested CVE ID [CVE-2026-5921](https://www.cve.org/cverecord?id=CVE-2026-5921) for this vulnerability, which was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program.
    - |
      **HIGH**: A Management Console administrator could inject shell metacharacters into configuration fields via the Management Console configuration API, leading to arbitrary command execution on the appliance as the admin OS user. GitHub has requested CVE ID [CVE-2026-4821](https://www.cve.org/cverecord?id=CVE-2026-4821) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/).
    - |
      **HIGH**: An attacker with knowledge of a target application's registered OAuth callback URL could gain unauthorized access to user accounts by exploiting incorrect regular expression matching in callback URL validation. GitHub has requested CVE ID [CVE-2026-4296](https://www.cve.org/cverecord?id=CVE-2026-4296) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/).
    - |
      **MEDIUM**: An attacker with permission to manage secret scanning push protection settings in one repository could add or remove delegated bypass reviewers in a different repository by exploiting an incorrect authorization check in the `/settings/security_analysis/bypass_reviewers` endpoints. Authorization was checked against the repository in the URL route, but the action was applied to a different repository specified in the request body. The impact is limited to assigning existing trusted users as bypass reviewers. GitHub has requested CVE ID [CVE-2026-3307](https://www.cve.org/cverecord?id=CVE-2026-3307) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/).
    - |
      **MEDIUM**: An authenticated attacker could determine the names of private repositories by their numeric ID through the mobile upload policy API endpoint, which returned repository names in validation error messages without verifying the caller's access. GitHub has requested [CVE ID CVE-2026-5512](https://www.cve.org/cverecord?id=CVE-2026-5512) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/).
  bugs:
    - |
      Dependabot security update jobs failed silently when dependency groups with `applies-to: security-updates` were configured.
    - |
      After administrators installed or removed a custom certificate authority (CA) certificate with `ghe-ssl-ca-certificate-install`, Dependabot services continued using the previous CA store and could fail to connect to external registries that required the updated CA.
    - |
      On an instance with GitHub Actions enabled, diagnostic log files for storage connectivity checks did not persist to disk when site administrators clicked **Test storage settings** in the Management Console or ran `ghe-config-apply` to apply configuration changes. This made storage connection failures difficult to troubleshoot because logs were unavailable in support bundles.
    - |
      During initial setup of a new instance, site administrators saw an "Oops! A configuration run is already in progress" error message in the Management Console even though `ghe-config-apply` had not been run.
    - |
      On instances using the new OpenTelemetry-based metrics stack, upgrading the instance re-enabled the legacy collectd-based metrics stack.
    - |
      Cluster administrators experienced `ghe-config-apply` failures when all replica nodes were marked offline and unreachable. Previously, `ghe-cluster-config-update` attempted to sync configuration files to an empty host list, causing the sync step to fail.
    - |
      Administrators experienced `ghe-support-bundle` appearing to hang on instances configured for high availability when one or more replica nodes were offline or unreachable during connectivity checks.
    - |
      When Consul replication failed to start, a misleading error message `exit: check_consul_replication: numeric argument required` was emitted to `ghe-config.log`.
    - |
      Consul replication would sometimes fail to start and would repeatedly display an error message `WARNING: Consul KV Replication Error` before terminating.
    - |
      On instances with Dependabot enabled, hotpatch upgrades could lock the Nomad jobs queue.
    - |
      When site administrators set the `observability.otelcol.gogc-enabled` parameter to a boolean value, the `config-apply` failed.
    - |
      On instances with GitHub Actions enabled, workflows using `actions/github-script@v7` failed with an Internal Server Error during action resolution. In the previous GHES version, the bundled actions/github-script repository referenced a Git object that no longer existed, causing all workflows using `actions/github-script@v7` to fail. <!-- markdownlint-disable-line GHD013 -->
    - |
      API consumers could not access secret scanning scan history for archived repositories, even when the organization had a GitHub Advanced Security license.
    - |
      When applying a hotpatch or running a configuration with `ghe-config-apply`, the configuration run could fail with `ERROR: Restoring CodeQL Action release tags` if internal Git services were not yet fully available. The error message `SpokesAPI::TwirpServerError: unavailable` appeared in logs.
    - |
      Organization creation failed with a 500 error because the system incorrectly attempted to verify CAPTCHA responses when no CAPTCHA challenge was shown to users.
    - |
      On instances connected to GitHub Enterprise Cloud with data residency, the "GitHub.com actions" setting appeared in the GitHub Connect configuration despite this feature not being available for data residency deployments.
    - |
      On instances with GitHub Actions enabled, errors appeared in logs related to missing Elasticsearch field mappings for workflow runs. The workflow run data included an `archived` field that was not defined in the Elasticsearch index mapping.
    - |
      The site admin bar displayed debugging information used by GitHub.
    - |
      Suspended users were listed in an organization's list of members.
    - |
      Migrations to GitHub Enterprise Server failed when the importer service tried to import a pull request review comment that referenced a garbage-collected commit. Now, these comments are skipped gracefully.
    - |
      An error was raised when attempting to delete an organization.
    - |
      On instances where the enterprise had set a {% data variables.product.pat_generic %} (PAT) expiration lifetime policy, the policy was not enforced for users who were not affiliated with any organization. Unaffiliated users could use classic PATs beyond the configured expiration limit. The enterprise-wide PAT lifetime policy is now enforced for all users regardless of organization affiliation.
    - |
      The site admin "All organizations" report included soft-deleted organizations.
    - |
      Users saw a “Preview” label for secret scanning’s Generic Secrets and Low Confidence Patterns, even though both features were generally available.
    - |
      On instances that blocked outbound internet access, code scanning repeatedly failed due to unnecessary outbound requests for functionality that is not available on GitHub Enterprise Server.
    - |
      On an instance with busy databases, online schema migrations using gh-ost failed because the cut-over lock timeout defaulted to 3 seconds, which was insufficient to acquire an exclusive table lock under continuous traffic.
  changes:
    - |
      To improve SSH security, the instance no longer advertises the ssh-rsa signature algorithm (which uses SHA-1) for server host keys on ports 22 and 122. RSA keys continue to work using the more secure rsa-sha2-256 and rsa-sha2-512 signature algorithms. Administrators using very old SSH clients that only support SHA-1 signatures may need to upgrade their clients. For more information about SSH algorithms, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-ssh-connections-to-your-instance).
    - |
      Administrators can now set `mysql.innodb-online-alter-log-max-size` with `ghe-config` so the value persists when a configuration is applied or upgraded.
    - |
      Administrators can configure the maximum number of concurrent HTTP/2 streams per connection for HAProxy. To set this value, use `ghe-config core.haproxy-h2-max-concurrent-streams VALUE` and run `ghe-config-apply`. Previously, this value was hardcoded to 100.
    - |
      Grafana dashboards on the "Monitor" tab of the Management Console are better labeled and organized.
      * Dashboards include a "[collectd]" or "[OpenTelemetry]" prefix based on their monitoring stack.
      * The "External MySQL" dashboard is hidden unless External MySQL is enabled.
      * OpenTelemetry dashboards have the "opentelemetry" tag, not the "prometheus" tag.
    - |
      To limit misleading error messages when the `mysql_exporter` and `sql_exporter` exporters try to connect to the database, both exporters use an IPv4 address.
    - |
      To improve page load performance, user profile pages display a maximum of 24 organizations. When viewing your own profile, a "View all" link provides access to the full list in organization settings. When viewing another user's profile, a count displays any additional organizations beyond the first 24.
  known_issues:
    - |
      On instances configured for high availability, you will not be able to change GitHub Actions settings through the Management Console. Other settings are not affected. [Updated: 2026-04-22]
    - |
      First time setups of GitHub Actions with OpenID Connect (OIDC) fail with an error on the `Update Servicing Resources` step. This problem does not affect instances where GitHub Actions is already enabled.

      As a workaround, you can enable Actions without OIDC, then enable OIDC **immediately** once the process completes. You should do this immediately because enabling OIDC will remove all access to existing Actions logs and artifacts.
    - |
      During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading.
    - |
      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 [Troubleshooting access to the Management Console](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account).
    - |
      {% data reusables.release-notes.large-adoc-files-issue %}
    - |
      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](/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.
    - |
      Running a config apply as part of the steps for [Replacing a node in an emergency](/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, shutdown the node and repeat the steps.
    - |
      {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
    - |
      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 enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
    - |
      When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed.
    - |
      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 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.
    - |
      The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance.
    - |
      Upgrading or hotpatching to 3.19.1 may fail on nodes that have been continuously upgraded from versions older than 2021 (i.e. 2.17). If this issue occurs, you will see log entries prefixed with `invalid secret` in ghe-config.log. If you are running nodes from these older versions, it is recommended not to upgrade to 3.19.1.
    - |
      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.