Enterprise Server 3.8 release notes

HIGH: An attacker with an Administrator role in GitHub Enterprise Server could gain SSH root access via remote code execution. GitHub has requested CVE ID CVE-2024-2469 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker with an editor role in the Management Console could gain SSH access to the instance by command injection when configuring GeoJSON settings. GitHub has requested CVE ID CVE-2024-2443 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

In some cases, storage initialization on a new instance launch could cause EBS-backed data volumes to not be detected correctly.

On an instance with GitHub Actions enabled, GitHub Actions workflows that deployed GitHub Pages sites failed with the following error: Error: Deployment failed, try again later.

Organizations using projects (classic) returned an error log about a soon-to-be deprecated MySQL feature when viewing a project.

On an instance with a GitHub Advanced Security license, viewing a secret scanning alert as a user without the security manager role would return a 500 error if the alert was generated from a Git tag instead of a normal commit.

Some API endpoints for projects did not properly filter target repositories based on the users access.

During a configuration run prompted by the delayed restart of the notebooks service, a container validation warning appeared in system logs.

In some cases, manual repository maintenance using ghe-spokesctl would fail with the following error: panic: runtime error: invalid memory address or nil pointer dereference.

On an instance with a GitHub Advanced Security license, in some cases, when a user deleted a custom pattern for secret scanning, GitHub Enterprise Server failed to close or delete the patterns alerts.

To avoid leaking secrets, the logging of all parameters is disabled for events related to the Management Console in an instance's enterprise audit log.

People deploying a GitHub Enterprise Server instance in AWS can now deploy in an environment that uses Instance Metadata Service Version 2 (IMDSv2).

On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding.

The payload for the push webhook event is now limited to 2,048 commits. If there are more than 2,048 commits in a push, the webhook payload for that push will not contain any commits. If you need to fetch commit information, you can use the Commits endpoints of the REST API. For more information, see "События и полезные данные веб-перехватчика" and "Конечные точки REST API для фиксаций."

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 "Устранение неполадок с доступом к консоли управления."

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance.

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.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS."

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly.

The HAProxy version has been updated in this release. You may encounter elevated error rates when HAProxy is upgraded as part of a hotpatch upgrade to a GitHub Enterprise Server instance. These elevated error rates should resolve within 5 minutes of the hotpatch being applied.

Please note, when performing a hotpatch upgrade to GitHub Enterprise Server version 3.8.12 or higher you will encounter this known issue only if you are hotpatching from GitHub Enterprise Server version 3.8.11 or lower .

On an instance with GitHub Actions enabled, Actions workflows that deploy GitHub Pages sites may fail with the following error:

Error: Deployment failed, try again later.

To fix this issue, connect to any of the instance's nodes using SSH, then run the following commands.

if [ -d "$CHROOT_PATH/data/pages-untar" ] ; then
  rm -rf "$CHROOT_PATH/data/pages-untar"
fi
pages_untar_image_tag="$(cat "$CHROOT_PATH/data/docker-image-tags/pages_untar_image_tag")"
id="$(docker create "pages-untar:$pages_untar_image_tag")"
sudo docker cp "$id:/data/pages-untar" "$BASE_PATH/$CHROOT_PATH/data/pages-untar/"
docker rm "$id"

HIGH: On an instance with GitHub Connect enabled and non-default settings for GitHub Connect configured, an attacker could use an enterprise GitHub Actions download token to fetch private repository data. This token is only accessible to users on the GitHub Enterprise Server instance. To fix this vulnerability, the Actions download token will now be a permissionless token. GitHub has requested CVE ID CVE-2024-1908 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

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 "Устранение неполадок с доступом к консоли управления."

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance.

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.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS."

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly.

The HAProxy version has been updated in this release. You may encounter elevated error rates when HAProxy is upgraded as part of a hotpatch upgrade to a GitHub Enterprise Server instance. These elevated error rates should resolve within 5 minutes of the hotpatch being applied.

Please note, when performing a hotpatch upgrade to GitHub Enterprise Server version 3.8.12 or higher you will encounter this known issue only if you are hotpatching from GitHub Enterprise Server version 3.8.11 or lower .

On an instance with GitHub Actions enabled, Actions workflows that deploy GitHub Pages sites may fail with the following error:

Error: Deployment failed, try again later.

To fix this issue, connect to any of the instance's nodes using SSH, then run the following commands.

if [ -d "$CHROOT_PATH/data/pages-untar" ] ; then
  rm -rf "$CHROOT_PATH/data/pages-untar"
fi
pages_untar_image_tag="$(cat "$CHROOT_PATH/data/docker-image-tags/pages_untar_image_tag")"
id="$(docker create "pages-untar:$pages_untar_image_tag")"
sudo docker cp "$id:/data/pages-untar" "$BASE_PATH/$CHROOT_PATH/data/pages-untar/"
docker rm "$id"

HIGH: An attacker could gain unauthorized read permission to files by deploying arbitrary symbolic links to a GitHub Pages site with a specially crafted artifact tarball. GitHub has requested CVE ID CVE-2024-1082 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker with an editor role in the Management Console could gain admin SSH access to the appliance by command injection when configuring SAML settings. GitHub has requested CVE ID CVE-2024-1372 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker with an editor role in the Management Console could gain admin SSH access to the appliance by command injection when setting an HTTP proxy. GitHub has requested CVE ID CVE-2024-1359 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker with an editor role in the Management Console could gain admin SSH access to the appliance by command injection into nomad templates when configuring SMTP options. GitHub has requested CVE ID CVE-2024-1378 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker with an editor role in the Management Console could gain admin SSH access to the appliance by command injection in the actions-console docker container while setting a service URL. GitHub has requested CVE ID CVE-2024-1355 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker with an editor role in the Management Console could gain admin SSH access to the appliance by command injection in the syslog-ng configuration file. GitHub has requested CVE ID CVE-2024-1354 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker with an editor role in the Management Console could gain admin SSH access to the appliance by command injection when setting the username and password for collectd configurations. GitHub has requested CVE ID CVE-2024-1369 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker with an editor role in the Management Console could gain admin SSH access to the appliance by command injection into nomad templates when configuring audit log forwarding. GitHub has requested CVE ID CVE-2024-1374 for this vulnerability, which was reported via the GitHub Bug Bounty program.

MEDIUM: An attacker could make changes to a user account by taking advantage of a Cross-site Scripting vulnerability in the tag name pattern field in the tag protections UI. Exploitation of this vulnerability required user interaction with malicious javascript on a website along with further social engineering. GitHub has requested CVE ID CVE-2024-1084 for this vulnerability, which was reported via the GitHub Bug Bounty program.

LOW: An attacker could decrypt the user section of the enterprise user license list JSON file by using an exposed private key. This vulnerability was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest versions.

On startup, Elasticsearch logged an innocuous JMX MBeans registration error.

Hunk headers in C# files did not correctly display changed functions.

Users could not use integrations to mark a pull request as ready for review.

During Git data server maintenance, a process that was ran on unsupported GitHub Enterprise Server topologies created a significant amount of system logs but did not perform any repair work.

The default 30 second webhook delivery HTTP timeout can be configured.

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 "Устранение неполадок с доступом к консоли управления."

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance.

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.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS."

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly.

The HAProxy version has been updated in this release. You may encounter elevated error rates when HAProxy is upgraded as part of a hotpatch upgrade to a GitHub Enterprise Server instance. These elevated error rates should resolve within 5 minutes of the hotpatch being applied.

Please note, when performing a hotpatch upgrade to GitHub Enterprise Server version 3.8.12 or higher you will encounter this known issue only if you are hotpatching from GitHub Enterprise Server version 3.8.11 or lower .

On an instance with GitHub Actions enabled, Actions workflows that deploy GitHub Pages sites may fail with the following error:

Error: Deployment failed, try again later.

To fix this issue, connect to any of the instance's nodes using SSH, then run the following commands.

if [ -d "$CHROOT_PATH/data/pages-untar" ] ; then
  rm -rf "$CHROOT_PATH/data/pages-untar"
fi
pages_untar_image_tag="$(cat "$CHROOT_PATH/data/docker-image-tags/pages_untar_image_tag")"
id="$(docker create "pages-untar:$pages_untar_image_tag")"
sudo docker cp "$id:/data/pages-untar" "$BASE_PATH/$CHROOT_PATH/data/pages-untar/"
docker rm "$id"
``` [Updated: 2024-03-07]

When starting up an instance using NVME storage in a cloud other than AWS, the attached data disk was not properly detected.

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 "Устранение неполадок с доступом к консоли управления."

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance.

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.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS."

Restoring backups with ghe-restore on a GHES cluster will exit prematurely if redis has not restarted properly.

The HAProxy version has been updated in this release. You may encounter elevated error rates when HAProxy is upgraded as part of a hotpatch upgrade to a GitHub Enterprise Server instance. These elevated error rates should resolve within 5 minutes of the hotpatch being applied.

Please note, when performing a hotpatch upgrade to GitHub Enterprise Server version 3.8.12 or higher you will encounter this known issue only if you are hotpatching from GitHub Enterprise Server version 3.8.11 or lower .

On an instance with GitHub Actions enabled, Actions workflows that deploy GitHub Pages sites may fail with the following error:

Error: Deployment failed, try again later.

To fix this issue, connect to any of the instance's nodes using SSH, then run the following commands.

if [ -d "$CHROOT_PATH/data/pages-untar" ] ; then
  rm -rf "$CHROOT_PATH/data/pages-untar"
fi
pages_untar_image_tag="$(cat "$CHROOT_PATH/data/docker-image-tags/pages_untar_image_tag")"
id="$(docker create "pages-untar:$pages_untar_image_tag")"
sudo docker cp "$id:/data/pages-untar" "$BASE_PATH/$CHROOT_PATH/data/pages-untar/"
docker rm "$id"
``` [Updated: 2024-03-07]

HIGH: An attacker with access to a Management Console user account with the editor role could escalate privileges through a command injection vulnerability in the Management Console. GitHub has requested CVE ID CVE-2024-0507 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: An attacker could leverage an unsafe reflection vulnerability in GitHub Enterprise Server (GHES) that could lead to reflection injection. This vulnerability could lead to the execution of user-controlled methods and remote code execution. To exploit this bug, an actor would need to be logged into an account on the GHES instance with the organization owner role. GitHub has requested CVE ID CVE-2024-0200 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

During periods of high load, users would see intermittent interruptions to services when upstream services failed internal health checks.

When creating a new custom pattern for secret scanning, the "More options" section of the custom pattern form automatically collapsed when a user entered an invalid regex in the post processing expressions (before/after secret match or additional secret requirements).

On an instance with a GitHub Advanced Security license and secret scanning enabled, users could experience a 500 error when viewing a secret scanning alert page in cases where the alerted commits belonged to the user and one or more commits could not be found.

Members of an enterprise were incorrectly allowed access to the REST API endpoints for Enterprise licensing.

The branch protection setting to require PR approval of the most recent reviewable push is included in exports from ghe-migrator or the Organization Migrations API.

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 "Устранение неполадок с доступом к консоли управления."

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance.

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.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS."

Restoring backups with ghe-restore on a GHES cluster will exit prematurely if redis has not restarted properly.

The HAProxy version has been updated in this release. You may encounter elevated error rates when HAProxy is upgraded as part of a hotpatch upgrade to a GitHub Enterprise Server instance. These elevated error rates should resolve within 5 minutes of the hotpatch being applied.

Please note, when performing a hotpatch upgrade to GitHub Enterprise Server version 3.8.12 or higher you will encounter this known issue only if you are hotpatching from GitHub Enterprise Server version 3.8.11 or lower .

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2024-02-22]

These release notes previously indicated that GitHub Enterprise Server 3.8.13 contained a fix for an incorrect authorization vulnerability that affected issue comments, CVE-2023-51380. This fix was included in GitHub Enterprise Server 3.8.12.

HIGH: An attacker with access to a Management Console user account with the editor role could escalate privileges by making requests to the endpoint used for bootstrapping the instance, and then reset the root site administrator password. GitHub has requested CVE ID CVE-2023-46647 for this vulnerability, which was reported via the GitHub Bug Bounty program.

HIGH: A path traversal vulnerability was identified in GitHub Enterprise Server that allowed arbitrary file reading when building a GitHub Pages site. To exploit this vulnerability, an attacker would need permission to create and build a GitHub Pages site on the GitHub Enterprise Server instance. This vulnerability was reported via the GitHub Bug Bounty program and assigned CVE-2023-46645.

MEDIUM: An insertion of sensitive information into log file vulnerability was identified in the log files for a GitHub Enterprise Server backend service that could permit an adversary in the middle attack when combined with other phishing techniques. To exploit this, an attacker would need access to the log files for the GitHub Enterprise Server instance, a backup archive created with GitHub Enterprise Server Backup Utilities, or a service which received streamed logs. GitHub has requested CVE ID CVE-2023-6746 for this vulnerability.

MEDIUM: Due to an insufficient entropy vulnerability, an attacker could brute force a user invitation to the Management Console. To exploit this vulnerability, an attacker would have needed knowledge that a user invitation was pending. This vulnerability was reported via the GitHub Bug Bounty program and assigned CVE-2023-46648.

MEDIUM: An attacker could maintain admin access via a race condition when an organization was converted from a user. GitHub has requested CVE ID CVE-2023-46649 for this vulnerability, which was reported via the GitHub Bug Bounty program.

MEDIUM: Due to an improper access control, an attacker could view private repository names by enumerating check run IDs with the "Get a check run" API endpoint. This vulnerability did not allow unauthorized access to any repository content other than the name. GitHub has requested CVE ID CVE-2023-46646 for this vulnerability, which was reported via the GitHub Bug Bounty program.

MEDIUM: An attacker could maintain admin access to a transferred repository in a race condition by making a GraphQL mutation to alter repository permissions during the transfer. GitHub has requested CVE ID CVE-2023-6690 for this vulnerability, which reported via the GitHub Bug Bounty program.

MEDIUM: An insertion of sensitive information into log file in the Audit Log in GitHub Enterprise Server was identified that that could allow an attacker to gain access to the Management Console. To exploit this, an attacker would need access to the log files for the GitHub Enterprise Server instance, a backup archive created with GitHub Enterprise Server Backup Utilities, or a service which received streamed logs. GitHub has requested CVE ID CVE-2023-6802 for this vulnerability.

MEDIUM: A race condition in GitHub Enterprise Server allowed an outside collaborator to be added while a repository is being transferred. GitHub has requested CVE ID CVE-2023-6803 for this vulnerability, which was reported via the GitHub Bug Bounty program.

MEDIUM: Improper privilege management allowed arbitrary workflows to be committed and run using an improperly scoped personal access token. To exploit this, a workflow must have already existed in the target repo. GitHub has requested CVE ID CVE-2023-6804 for this vulnerability, which was reported via the GitHub Bug Bounty program.

MEDIUM: An incorrect authorization vulnerability was identified that allowed issue comments to be updated with an improperly scoped token. This vulnerability did not allow unauthorized access to any repository content as it also required contents.write and issues.read permissions. This vulnerability was reported via the GitHub Bug Bounty Program and has been assigned CVE-2023-51379.

MEDIUM: An incorrect authorization vulnerability was identified that allowed issue comments to be read with an improperly scoped token. This vulnerability was reported via the GitHub Bug Bounty Program and has been assigned CVE-2023-51380.

LOW: Pre-receive hooks have been further hardened against shell command injections.

LOW: To render interactive maps in an instance's web UI using Azure Maps, GitHub Enterprise Server has migrated from use of an unsecure Azure Maps API token to a more secure access token provided by role-based access control (RBAC) in Entra ID. After upgrading to this release, to re-enable interactive maps, an administrator must reconfigure authentication to Azure Maps in the Management Console. For more information, see "Настройка интерактивных карт."

To address scenarios that could lead to denial of service, HAProxy has been upgraded to version 2.8.4. [Updated 2024-01-03]

Packages have been updated to the latest security versions.

In rare cases, on an instance with GitHub Actions enabled, a failed check on a deleted repository could cause upgrades to a new version of GitHub Enterprise Server to fail.

When an administrator ran the ghe-support-bundle or ghe-cluster-support-bundle command, the -p flag did not produce bundles with log durations as specified. The duration period can now only be specified in days. Additionally, unnecessary files were sanitized by the commands.

On an instance in a cluster configuration, upgrades could fail due to a background job running during database migration.

On an instance in a high availability configuration, the ghe-repl-teardown command failed when provided with a UUID.

In some environments, stale .backup log files could accumulate in the system.

On an instance hosted on AWS, when configuring GitHub Packages, virtual-hosted-style AWS S3 URLs would default to path-style URLs if a region-code was included. For more information, see Virtual hosting of buckets in the AWS documentation.

Because the | character was not permitted, administrators could not add an SMTP username to authenticate with the Azure Communication Service.

On an instance with a GitHub Advanced Security license and secret scanning enabled, site administrators using the ghe-secret-scanning command would not see a relevant error message if their input was invalid.

On an instance with a GitHub Advanced Security license, users with the security manager role could not update custom links for push protection using the REST API.

On an instance with the dependency graph enabled, some security products were not automatically enabled for new public repositories.

Pull request review threads at the file level, rather than the individual line level, were not included in exports from ghe-migrator or the Organization Migrations API.

After importing a migration archive using ghe-migrator or REST API endpoints for organization migrations, in some cases, some review comments within pull requests were not associated with lines of code.

On an instance with a GitHub Advanced Security license and secret scanning enabled, secret scanning alert emails were sent to organization owners even if their email address did not comply with domain restrictions.

After a user started a repository transfer, if another user viewed the repository before the transfer finished, the repository overview rendered incorrectly.

A missing executable on the PATH caused the ghe-spokesctl ssh command to fail.

On an instance with GitHub Actions enabled, users occasionally got a 500 error when viewing a job with a pending deployment.

An administrator could enable GitHub Connect on an instance with a license that does not support GitHub Connect.

On an instance with GitHub Connect enabled, some system users were incorrectly counted as consuming a license following license sync.

A user in the process of being converted into an organization could be added as a collaborator on a repository. This resulted in the new organizations owners unexpectedly receiving access to the repository.

On an instance with a GitHub Advanced Security license and secret scanning enabled, dry runs sometimes incorrectly reported no results for custom patterns.

On an instance with a GitHub Advanced Security license and secret scanning enabled, webhooks for alert locations did not contain information about push protection bypasses.

On an instance with Dependabot updates enabled, Dependabot relies on the node installation provided by the actions runner instead of dynamically downloading.

When adding a node to an instance, performance is improved during initial database replication.

An administrator can run the new ghe-check-background-upgrade-jobs command to ensure all upgrade jobs that run in the background have finished. This allows the administrator to know when they can start the next upgrade to their GitHub Enterprise Server instance.

To avoid negative effects on disk utilization, babeld log files have a maximum size of 15 GB.

To improve reliability of release uploads in low-bandwidth environments, the time-to-live (TTL) value of the token for uploading release assets has increased from 1 hour to 3 hours.

When using ghe-migrator prepare to import an archive, a missing schema.json file results in an UnsupportedArchive error rather than an UnsupportedSchemaVersion error.

The audit log now tracks all failed password attempts individually. Previously, duplicate failed password attempts in sequence within the same day would be grouped into one failed password attempt, with a count field.

As a security measure, GitHub Pages does not build sites that contain symbolic links except when using custom GitHub Actions workflows. When the page builder encounters a symbolic link, the build will fail with an error indicating that the symbolic link should be dereferenced. Custom workflows for GitHub Pages are available in GitHub Enterprise Server 3.7 and later.

Custom firewall rules are removed during the upgrade process.

The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

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 "Устранение неполадок с доступом к консоли управления."

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance.

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.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS."

Restoring backups with ghe-restore on a GHES cluster will exit prematurely if redis has not restarted properly.

The HAProxy version has been updated in this release. You may encounter elevated error rates when HAProxy is upgraded as part of a hotpatch upgrade to a GitHub Enterprise Server instance. These elevated error rates should resolve within 5 minutes of the hotpatch being applied.

Please note, when performing a hotpatch upgrade to GitHub Enterprise Server version 3.8.12 or higher you will encounter this known issue only if you are hotpatching from GitHub Enterprise Server version 3.8.11 or lower . [Updated 2024-01-03]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2024-02-22]

Interactive maps in the web UI no longer allow authentication using an Azure Maps API key

• To allow users to render interactive maps in an instance's web UI by writing GeoJSON or TopoJSON syntax, GitHub Enterprise Server previously required a potentially unsecure API key for authentication with Azure Maps. If an administrator previously enabled interactive maps on an instance, the feature is disabled upon upgrade to this release.

  To re-enable interactive maps for your instance, you must configure an application on an Entra ID tenant that has access to Azure Maps using role-based access control (RBAC). For more information, see "Настройка интерактивных карт" and the security fixes for this release.

LOW: Due to an incorrect permission assignment for some configuration files, an attacker with access to a local operating system user account could read MySQL connection details including the MySQL password. [Updated: 2023-11-13]

Packages have been updated to the latest security versions.

When a site administrator ran ghe-btop via SSH, the command did not run and a /usr/bin/env: python3: No such file or directory error occurred.

Multiple lines in babeld logs could run together, making it unclear to administrators if the operations were related.

/var/log/lastlog was not copied over as a sparse file during ghe-upgrade, which could cause issues by using additional disk space.

On an instance in a cluster configuration, when managing maintenance mode using ghe-cluster-maintenance, an erroneous warning appeared that read "Warning: Maintenance mode set on primary, please make sure to set it on any active replica if needed".

ghe-repl-status did not identify Git replicas in certain incomplete states and incorrectly suggested that a failover could be performed safely. In some cases, this led to data loss during failover.

Repository exports using ghe-migrator or the REST API's operation for organization migrations could fail when a large number of commit comments or long commit comments were present.

On an instance with a GitHub Advanced Security license and secret scanning enabled, secret scanning suggested incorrect filters when viewing both open and closed alerts.

On an instance with multiple nodes, ghe-spokes status did not identify Git replicas in certain incomplete states, causing a false report that replication was in sync and leading to data loss or replication issues during failover.

On an instance with a GitHub Advanced Security license and secret scanning enabled, dry runs sometimes incorrectly reported no results for custom patterns.

Instructions in the "Migrations" section of the Management Console clarify that only standard AWS S3 endpoints are supported when configuring AWS S3 as a blob storage provider for migrations.

On an instance in a cluster configuration, administrators can identify the repository networks or gists that are common across a specified set of storage nodes using the spokesctl find-on-replicas command.

As a security measure, GitHub Pages does not build sites that contain symbolic links except when using custom GitHub Actions workflows. This change strengthens GitHub Pages's symbolic link detection.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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 "Устранение неполадок с доступом к консоли управления."

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary.

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2024-02-22]

HTTP Strict Transport Security (HSTS) is enabled within the Management Console.

To prevent commits from a detached repository from syncing to prior forks that are now in a separate repository network, GitHub Enterprise Server closes pull requests between repositories during detachment.

Packages have been updated to the latest security versions.

When displaying a list of subdomains in the Management Console, the list included the outdated render subdomain, and excluded the newer containers, docker, notebook, and viewscreen subdomains.

On an instance in a cluster configuration, the Cluster-Balance daemon would run against jobs not specified in the configuration.

On an instance with a GitHub Advanced Security license and secret scanning enabled, and when using Safari, changing additional match requirements for a custom pattern did not retrigger custom pattern evaluation against a user submitted test string.

When viewing git blame data, the reviewer menu was loaded even when the suggested reviewer calculation timed out.

When uploading migration archives to blob storage, the GitHub Enterprise Server instance's outbound web proxy server was not used.

Duplicated intermediate commit trailers won't appear in pull request squash messages.

On an enterprise with the policy setting that disallows repository admins from enabling/disabling secret scanning, transferring a repository to a new organization that automatically enabled secret scanning wouldn't result in the transferred repository being automatically enabled for secret scanning.

When migrating a repository from a GitHub Enterprise Server instance to another location, the ghe-migrator target_url command allows you to record the repository's new location. The new URL is displayed when you visit the main page of the repository in the web interface.

On an instance with subdomain isolation disabled, a notebook could not be loaded due to incorrect asset paths.

On an instance with subdomain isolation disabled, a notebook could not be loaded due to an extra / character in the URL path.

On an instance with a GitHub Advanced Security license and secret scanning enabled, in some cases, custom patterns would erroneously show no results for a dry run.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

Site administrators can see improved diagnostic information about repositories that have been deleted.

When providing data to GitHub Support, GitHub Enterprise Server displays a notice describing how support data is used before uploading the support files.

On an instance with multiple nodes, internal tooling to repair repositories now attempts to resolve problems within the entire repository network.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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 "Troubleshooting access to the Management Console." [Updated: 2023-02-23]

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

Packages have been updated to the latest security versions.

An authorization/sensitive information disclosure vulnerability was identified in GitHub Enterprise Server that allowed a fork to retain read access to an upstream repository after the fork's visibility was changed to private. This vulnerability was reported via the GitHub Bug Bounty Program and assigned CVE-2023-23763. [Updated: 2023-09-01]

When an administrator tried to validate blob storage connection settings for GitHub Enterprise Importer in the Management Console using the Test storage settings button, the operation failed.

syslog-ng configurations for containerized services caused errors for log forwarding services. The configurations have been removed.

When an instance exhausted available memory, in some cases, the system's out-of-memory killer (OOMK) killed the process for dockerd, causing Nomad to fail to recover after systemd restarted Docker.

When running the ghe-migrator, certain error messages contained an invalid link to import documentation.

On an instance with GitHub Actions enabled, due to mismatched values, users could not easily associate workflow job run IDs from the GitHub Enterprise Server APIs or webhooks with a job in the UI. Workflow job runs now use a new URL pattern of ...actions/runs/job/{job_id}, and job_id matches values from APIs and webhook payloads.

On an instance with a GitHub Advanced Security license and secret scanning enabled, in some cases, custom patterns would erroneously show no results for a dry run.

Administrators could not use the "Migrations" section in an instance's Management Console to configure blob storage for GitHub Enterprise Importer. [Updated: 2023-08-31]

Administrators with SSH access to an instance can view the version of GitHub Enterprise Server on the instance by using the -v flag with the ghe-version utility.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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 "Troubleshooting access to the Management Console." [Updated: 2023-02-23]

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-09-04]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

LOW: An incorrect comparison vulnerability was identified in GitHub Enterprise Server that allowed commit smuggling by displaying an incorrect diff in a reopened pull request. To exploit this vulnerability, an attacker would need write access to the repository. This vulnerability was reported via the GitHub Bug Bounty program and was assigned CVE-2023-23766. [Updated: 2023-09-22]

Packages have been updated to the latest security versions.

API results were incomplete, and ordering of results was incorrect if asc or desc appeared in lowercase within the API query.

The checks in the merge box for a pull request did not always match the the checks for the most recent commit in the pull request.

When a site administrator used GitHub Enterprise Importer on versions 3.7 and below to migrate repositories from GitHub Enterprise Server, the system backup size would increase after running many migrations due to storage files not being cleaned up.

A collaborator with the "Set the social preview" permission inherited from the "Read" role couldnt upload the social preview image of a repository.

When running the ghe-migrator, certain error messages contained an invalid link to import documentation.

In some cases, on an instance with GitHub Actions enabled, deployment of GitHub Pages site using a GitHub Actions workflow failed with a status of deployment_lost.

On an instance in a high availability configuration, existing nodes with out-of-sync repositories prevented new nodes from replicating those repositories.

GitHub Enterprise Server was queuing zip jobs unnecessarily.

The description of the ghe-cluster-balance command line utility clarifies that it can be used to balance jobs other than github-unicorn.

On GitHub Enterprise Server 3.8 and above, a blob storage provider must be configured in the Management Console in order to use the GitHub Enterprise Importer CLI, "startRepositoryMigration" GraphQL API, or "Start an organization migration" REST API. The "Migrations" section in the Management Console was mistakenly removed and has been added back.

Administrators can display all repositories in a network with spokesctl by using the repositories subcommand.

The secondary abuse rate limits of the GraphQL API are now configurable in the Management Console. [Updated: 2023-09-01]

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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 "Troubleshooting access to the Management Console." [Updated: 2023-02-23]

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

Administrators cannot set or update the instance's blob storage settings in the Management Console using the "Migrations" settings tab. No matter what values an administrator provides, the following error message will appear: Unable to connect to migrations provider. Please check the form and try again. [Updated: 2023-08-18]

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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 "Troubleshooting access to the Management Console." [Updated: 2023-02-23]

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

On an instance that is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles uploaded by a site administrator using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

After restoration of a backup created using GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use GitHub Enterprise Server Backup Utilities 3.8.1 and generate a new full backup using ghe-backup. For more information on using an existing backup, see "Известные проблемы с резервными копиями для вашего экземпляра." [Updated: 2023-07-31]

The "Migrations" section is missing from the Management Console, so it isn't possible to enable, disable, or reconfigure blob storage credentials for migrations. [Updated: 2023-08-18]

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

On an instance configured to use an outbound web proxy server, an administrator could not exclude private domains in this list from the proxy configuration. [Updated: 2023-11-27]

Adjusted the timeout threshold for shutting down MySQL to prevent premature termination when upgrading to GHES 3.9.

An attacker with access to the password hash of the root site administrator user for the instance's Management Console could make requests to the password API endpoint from outside of the instance.

Packages have been updated to the latest security versions.

LOW: An incorrect comparison vulnerability was identified in GitHub Enterprise Server that allowed commit smuggling by displaying an incorrect diff in a re-opened Pull Request. To exploit this vulnerability, an attacker would need write access to the repository. This vulnerability was reported via the GitHub Bug Bounty Program and was assigned CVE-2023-23765.

If MinIO was configured for external blob storage on an instance with GitHub Actions enabled and MinIO was configured for bucket replication, the instance's credential validation with MinIO would occasionally fail.

Customers who use Azure Blob store as the remote blob provider to back GitHub Packages would have validation errors if the EndpointSuffix part of their Connection string was anything other than core.windows.net. Now all valid EndpointSuffix are accepted.

When a user viewed a Jupyter notebook, GitHub Enterprise Server returned a 500 error code if the instance was configured with a self-signed TLS certificate.

After creation of a blob object from the web UI, pre-receive hook events were missing from the instance's audit log.

On an instance in a high availability configuration, on some platforms, replication could perform poorly over links with very high latency.

On an instance with custom firewall rules defined, a configuration run with ghe-config-apply could take longer than expected.

On an instance with an outbound web proxy server configured, the proxy interfered with internal operations that used nomad alloc exec.

On an instance in a cluster configuration, the ghe-cluster-balance behaved inconsistently when displaying status or managing jobs with more than one task group.

On an instance configured for LDAP authentication, if the LDAP server sent an empty string for the sshPublicKey attribute, LDAP user sync would fail.

When an administrator updated an instance's TLS certificate via the API as a query parameter instead of in the request body, the certificate and key appeared in unicorn.log.

Jobs that performed daily clean-up tasks failed to run, so old data was not removed from the MySQL database.

After creation of a new Management Console user, the Management Console did not display the button to copy the new users invitation.

ghe-service-list erroneously reported errors because the utility looked for systemd services that have been migrated to Nomad.

On an instance in a high availability configuration, when adding a new node, connection checks between existing nodes would fail.

On an instance with Dependabot enabled, in some situations, Dependabot alerts were not updated when a user pushed to a repository.

In rare circumstances, Git commits signed with SSH keys using the RSA algorithm would incorrectly indicate the signature was invalid.

After a migration using GitHub Enterprise Importer, some repository autolink references were created with an incorrect format.

In some cases on an instance without a GitHub Advanced Security license, Redis exceeded the maximum default memory allocation, causing 500 errors for the instance's users.

On an instance with many organizations, the enterprise security overview page returned a 500 error.

On an instance that was not configured to deliver email notifications using SMTP, background jobs to deliver email were enqueued unnecessarily.

Users were unable to configure a SSH certificate authority for an organization.

An erroneous "Blocked Copilot Repositories" link was visible in site admin pages for organizations.

Events related to repository notifications did not appear in the audit log.

On an instance with a GitHub Advanced Security license and secret scanning enabled, in some cases, a committer would not receive an email notification for a secret scanning alert where push protections were bypassed.

On an instance with a GitHub Advanced Security license, if a user filtered by a custom pattern on an organizations "Code & security analysis" page using an invalid query, the entire GitHub Advanced Security disappeared and an error reading "Sorry, something went wrong loading GitHub Advanced Security settings" appeared.

On an instance with a GitHub Advanced Security license and secret scanning enabled, output from Git for a push blocked by push protection always included an http:// link.

Querying the audit log for hashed_token returned no results.

The audit log reported the incorrect target repository for pre-receive hook failures.

Links to wiki pages in Markdown headers did not point to the correct path, resulting in a 404 Not Found error.

GitHub Actions will now properly execute after restoring a deleted repository.

On an instance with multiple nodes, when using the spokesctl command-line utility to manage repositories with replicas that failed to fully create, the utility would spuriously attempt to repair healthy replicas.

On an instance in a cluster configuration, the ghe-cluster-config-check command-line utility will return an affirmative message when no warnings or errors are detected. The affirmative message is "Configuration validation complete. No errors found."

During initialization of a cluster configuration, output from the ghe-cluster-config-init command-line utility is improved and simplified.

The Management Console displays a warning about unexpected consequences that may result from modification of the instance's hostname after initial configuration.

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

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 will 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." [Updated: 2023-02-23]

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

After restoration of a backup created using GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use GitHub Enterprise Server Backup Utilities 3.8.1 and generate a new full backup using ghe-backup. For more information on using an existing backup, see "Известные проблемы с резервными копиями для вашего экземпляра." [Updated: 2023-07-31]

The "Migrations" section is missing from the Management Console, so it isn't possible to enable, disable, or reconfigure blob storage credentials for migrations. [Updated: 2023-08-18]

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

MEDIUM: Scoped installation tokens for a GitHub App kept approved permissions after the permissions on the integration installation were downgraded or removed. This vulnerability was reported via the GitHub Bug Bounty program.

If a user's request to the instance's API included authentication credentials within a URL parameter, administrators could see the credentials in JSON within the instance's audit log.

Packages have been updated to the latest security versions.

If an administrator updated the instance's TLS certificate using the Management Console API's Set settings endpoint, sending the certificate and key data as a URL query parameter resulted in the data appearing unmasked in system logs.

Determining suggested reviewers on a pull request could time out or be very slow.

After an enterprise owner set a permanent rate limit for a users GitHub App at http(s)://HOSTNAME/stafftools/users/USERNAME/installations, the instance did not respect the rate limit.

On an instance with multiple nodes, when using the spokesctl command-line utility to manage repositories with replicas that failed to fully create, the utility would spuriously attempt to repair healthy replicas.

On an instance with a GitHub Advanced Security license and code scanning enabled, code scanning could not process some SARIF files produced by newer versions of CodeQL.

If a configuration runs fails due to Elasticsearch errors, ghe-config-apply displays a more actionable error message.

After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

After restoration of a backup created using GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use GitHub Enterprise Server Backup Utilities 3.8.1 and generate a new full backup using ghe-backup. For more information on using an existing backup, see "Известные проблемы с резервными копиями для вашего экземпляра." [Updated: 2023-07-31]

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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 will 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." [Updated: 2023-02-23]

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

When using an outbound web proxy server, the ghe-btop command may fail in some circumstances with the error "Error querying allocation: Unexpected response code: 401".

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

Organization owners cannot register a new SSH certificate authorities (CAs) due to an erroneous suggestion to start a trial. Organization SSH CAs configured before an upgrade to an affected version are still usable after the upgrade. Enterprise owners can can still register SSH CAs for all organizations.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

MEDIUM: Scoped installation tokens for a GitHub App kept approved permissions after the permissions on the integration installation were downgraded or removed. This vulnerability was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

On an instance in a cluster configuration, when upgrading the MySQL master node, the post-upgrade configuration run would take 600 seconds longer than required due to incorrect detection of unhealthy nodes.

On an instance with a GitHub Advanced Security license and secret scanning enabled, rotation of the key used to encrypt secrets discovered by secret scanning would fail.

In some situations on an instance with multiple nodes, Git replication failed to fully replicate repositories that had previously been deleted, which resulted in a warning in ghe-repl-status output.

If a user made a request to the Collaborators API's Add a repository collaborator endpoint specifying a permission of read or write, the instance returned a 500 error.

On an instance with the dependency graph enabled, the correct path appears for manifests that originate from build-time submission snapshots.

The spokesctl command-line utility accepts more input formats.

On an instance with a GitHub Advanced Security license and code scanning enabled, CodeQL analysis created a SARIF file that failed processing, which the API showed as pending due to an internal exception. [Updated: 2023-12-12]

People with administrative SSH access to an instance can configure the maximum memory usage in gigabytes for Redis using ghe-config redis.max-memory-gb VALUE.

After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

After restoration of a backup created using GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use GitHub Enterprise Server Backup Utilities 3.8.1 and generate a new full backup using ghe-backup. For more information on using an existing backup, see "Известные проблемы с резервными копиями для вашего экземпляра." [Updated: 2023-07-31]

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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 will 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." [Updated: 2023-02-23]

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

When using an outbound web proxy server, the ghe-btop command may fail in some circumstances with the error "Error querying allocation: Unexpected response code: 401".

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

MEDIUM: Updated Git to include fixes from 2.40.1. For more information, see Git security vulnerabilities announced on the GitHub Blog. [Updated: 2023-07-24]

Users were unable to upload GIF files as attachments within a comment in an issue or pull request.

A site administrator could not bypass a proxy for a top-level domain (TLD) from the instance's exception list or IANAs registered top-level domains (TLDs).

On some platforms, after someone with administrative SSH access ran ghe-diagnostics, the command's output included a cosmetic SG_IO error.

When a site administrator used GitHub Enterprise Importer to import data from GitHub Enterprise Cloud, migrations failed during the import of file-level comments. This failure no longer prevents the import from proceeding.

On an instance with a GitHub Advanced Security license, users with the security manager role for an organization could not view GitHub Advanced Security settings for the organization.

On an instance with a large number of organizations, enterprise owners who navigated to the "Security and analysis" settings page for the enterprise could return a 500 error.

From GitHub Enterprise Server 3.8 onwards, using the GitHub Enterprise Importer CLI, the startRepositoryMigration GraphQL API, or the “Start an organization migration” REST API requires a blob storage provider to be configured in the Management Console. When using Azure Blob Storage, storage containers were incorrectly configured to be publicly accessible. Azure Blob Storage containers will now be configured to be private, and we have introduced a check that explicitly fails exports if the storage container is public.

When a site administrator used GitHub Enterprise Importer, import of a repository failed if a project column in the repository contained 2,500 or more archived cards.

In some situations on an instance with multiple nodes, Git replication failed to fully replicate repositories that had previously been deleted, which resulted in a warning in ghe-repl-status output.

On an instance with Dependabot alerts enabled, alerts were erroneously hidden when different vulnerabilities were detected by multiple build-time submission detectors.

GitHub Enterprise Server published distribution metrics that cannot be processed by collectd. The metrics included pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids, and git.hooks.runtime.

In some cases, on an instance with GitHub Actions enabled, deployment of GitHub Pages site using a GitHub Actions workflow failed with a status of deployment_lost.

On an instance with a GitHub Advanced Security license that was also configured for a timezone greater than UTC, the list of secret scanning alerts displayed a "Loading secrets failed" error if a user sorted secrets by date in descending order.

On an instance with a GitHub Advanced Security license where secret scanning is enabled, excessive logging in /var/log could cause user-facing errors and degrade system performance if logs consumed all free space on the volume.

On an instance with the dependency graph enabled, background services can handle more traffic.

People with administrative SSH access who generate a support bundle using the ghe-support-bundle or ghe-cluster-support-bundle utilities can specify the period of time to gather data with -p or --period without using spaces or quotes. For example, in addition to '-p 5 days' or -p '4 days 10 hours', -p 5days or -p 4days10hours are valid.

After a site administrator exports a migration archive using GitHub Enterprise Importers gh-migrator utility, the link to the archive remains accessible for 48 hours instead of one hour.

After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

After restoration of a backup created using GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use GitHub Enterprise Server Backup Utilities 3.8.1 and generate a new full backup using ghe-backup. For more information on using an existing backup, see "Известные проблемы с резервными копиями для вашего экземпляра." [Updated: 2023-07-31]

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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.

During an upgrade to GitHub Enterprise Server 3.8.0 on a cluster, after you upgrade nodes other than the primary MySQL node and before you upgrade the primary MySQL node, the following error may appear multiple times after you run ghe-config-apply.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

You can safely ignore this message.

If the root site administrator is locked out of the Management Console after failed login attempts, the account will 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." [Updated: 2023-02-23]

On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

When using an outbound web proxy server, the ghe-btop command may fail in some circumstances with the error "Error querying allocation: Unexpected response code: 401".

If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

On an instance with audit log streaming enabled, the driftwood service does not start, preventing the normal operation of audit log streaming. [Updated: 2023-06-06]

On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render. [Updated: 2023-08-18]

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

MEDIUM: An attacker with write access to a repository could craft a pull request that would hide commits made in its source branch. This vulnerability was reported via the GitHub Bug Bounty Program and has been assigned CVE-2023-23764. [Updated: 2023-07-26]

On an instance with GitHub Actions enabled, nested calls to reusable workflows within a reusable workflow job with a matrix correctly evaluate contexts within expressions, like strategy: ${{ inputs.strategies }}.

Download requests for Git LFS objects did not complete until reporting the final download size, which affected the latency of these requests, particularly on an instance with nodes functioning as repository caches.

On an instance in a high availability configuration, a git push operation could fail if GitHub Enterprise Server was simultaneously creating the repository on a replica node.

When a site administrator ran ghe-btop via SSH, the command did not run and a /usr/bin/env: python3: No such file or directory error occurred.

Site administrators who prepared to enable GitHub Actions could not run the ghe-actions-precheck utility because the scripts file was not executable.

In some cases on an instance with a GitHub Advanced Security license, users could not load the security analysis page and saw a 500 error.

On an instance with GitHub Connect enabled, if "Users can search GitHub.com" was enabled, issues in private and internal repositories were not included in users search results for GitHub.com.

After restoration of a deleted organization, the organization did not appear in the instance's list of organizations.

After a site administrator exported a migration archive to AWS S3 using GitHub Enterprise Importer's gh-migrator utility, the URL for the archive was inaccessible.

If a site administrator exported a migration archive to a bucket in AWS S3s us-east-1 region using GitHub Enterprise Importer's gh-migrator utility, the archive was inaccessible.

Collectd logs could grow rapidly in size due to the inclusion of kredz.* metrics, which can't be parsed by StatsD and resulted in error messages.

If a site administrator provides an invalid configuration for blob storage for GitHub Actions or GitHub Packages on an instance, the preflight checks page displays details and troubleshooting information.

After a site administrator exports a migration archive using GitHub Enterprise Importer's gh-migrator utility, the link to the archive remains accessible for 48 hours instead of one hour.

On an instance with a GitHub Advanced Security license, users who author custom patterns for secret scanning can provide expressions that must or must not match that are up to 2,000 characters. This limit is an increase from 1,000 characters.

After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

After restoration of a backup created using GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use GitHub Enterprise Server Backup Utilities 3.8.1 and generate a new full backup using ghe-backup. For more information on using an existing backup, see "Известные проблемы с резервными копиями для вашего экземпляра." [Updated: 2023-07-31]

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

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.

During an upgrade to GitHub Enterprise Server 3.8.0 on a cluster, after you upgrade nodes other than the primary MySQL node and before you upgrade the primary MySQL node, the following error may appear multiple times after you run ghe-config-apply.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

You can safely ignore this message.

If the root site administrator is locked out of the Management Console after failed login attempts, the account will 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." [Updated: 2023-02-23]

On an instance with a GitHub Advanced Security license where secret scanning is enabled, excessive logging in /var/log may cause user-facing errors and degraded system performance if logs consume all free space on the volume. To prevent this issue from impacting users, monitor free space on your instance's root volume. For more information, see "Configuring secret scanning for your appliance" and "Monitoring your appliance." If you suspect that this issue is affecting your instance and you need help, contact GitHub Support. [Updated: 2023-05-03]

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

HIGH: Addressed an improper authentication vulnerability that allowed an unauthorized actor to modify other users' secret gists by authenticating through an SSH certificate authority. This vulnerability was reported via the GitHub Bug Bounty Program and has been assigned CVE-2023-23761. [Updated: 2023-04-07]

MEDIUM: Addressed an incorrect comparison vulnerability that allowed commit smuggling by displaying an incorrect diff. This vulnerability was reported via the GitHub Bug Bounty Program and has been assigned CVE-2023-23762. [Updated: 2023-04-07]

On an instance with GitHub Actions enabled, a workflow job for GitHub Actions would not start if a matching runner group was unavailable when the job was initially queued, even if a matching runner group became available after the job entered the queue.

On an instance with GitHub Actions enabled, GitHub Actions will now properly execute after restoration of a deleted repository.

On an instance with GitHub Actions enabled, nested calls to reusable workflows within a reusable workflow job with a matrix correctly evaluate contexts within expressions, like strategy: ${{ inputs.strategies }}.

In some cases, graphs on the Management Console's monitor dashboard failed to render.

After an administrator used the /setup/api/start REST API endpoint to upload a license, the configuration run failed with a Connection refused error during the migrations phase.

On an instance in a cluster configuration, when a site administrator set maintenance mode using ghe-maintenance -s, a Permission denied error appeared when the utility tried to access /data/user/common/cluster.conf.

On an instance in a high availability configuration, if an administrator tore down replication from a replica node using ghe-repl-teardown immediately after running ghe-repl-setup, but before ghe-repl-start, an error indicated that the script cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown now displays an informational alert and continues the teardown.

During configuration of high availability, if a site administrator interrupted the ghe-repl-start utility, the utility erroneously reported that replication was configured, and the instance would not perform expected clean-up operations.

Commands that site administrators ran via SSH on any of the instances nodes were not logged in /var/log/ssh-console-audit.log.

On instances configured to use the private beta of SCIM for GitHub Enterprise Server, users' authentication with SSH keys and personal access tokens failed due to an erroneous requirement for authorization.

After a user imported a repository with push protection enabled, the repository was not immediately visible in the security overview's "Security Coverage" view.

Responses from the /repositories REST API endpoint erroneously included deleted repositories.

When a site administrator used ghe-migrator to migrate data to GitHub Enterprise Server, in some cases, nested team relationships would not persist after teams were imported.

If a repository contained a CODEOWNERS file with check annotations, pull requests "Files changed" tab returned a 500 error and displayed "Oops, something went wrong" in the "Unchanged files with check annotations" section.

On an instance with GitHub Actions enabled, if a user manually triggered a workflow using the REST API but did not specify values for optional booleans, the API failed to validate the request and returned a 422 error.

When users searched for gists, the text in the search field was not visible in some cases because the texts color was identical to the color of the fields background.

In some cases on an instance with multiple nodes, GitHub Enterprise Server erroneously stopped writing to replica fileservers, causing repository data to fall out of sync.

On an instance with GitHub Connect enabled, if "Users can search GitHub.com" was enabled, users would not see issues in private and internal repositories in search results for GitHub.com.

An enterprise owner could not enable two-factor authentication (2FA) for an instance if any enterprise owners had not enabled 2FA for their user accounts. [Updated: 2023-04-17]

On an instance with GitHub Packages enabled, after users pushed to the Container registry, the instance erroneously responded with a 429 Too Many Requests error in cases when the instance could accommodate the request. The limits have been raised, and users should receive this message less often. [Updated: 2023-05-30]

When a site administrator configures an outbound web proxy server for GitHub Enterprise Server, the instance now validates top-level domains (TLDs) excluded from the proxy configuration. By default, you can exclude public TLDs that the IANA specifies. Site administrators can specify a list of unregistered TLDs to exclude using ghe-config. The . prefix is required for any public TLDs. For example, .example.com is valid, but example.com is invalid. For more information, see "Настройка сервера веб-прокси исходящего трафика."

To avoid intermittent issues with the success of Git operations on an instance with multiple nodes, GitHub Enterprise Server checks the status of the MySQL container before attempting a SQL query. The timeout duration has also been reduced.

The default path for output from ghe-saml-mapping-csv -d is /data/user/tmp instead of /tmp. For more information, see "Служебные программы командной строки."

On an instance with a GitHub Advanced Security license, users who author custom patterns for secret scanning can provide expressions that must or must not match that are up to 2,000 characters. This limit is an increase from 1,000 characters.

After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

After restoration of a backup created using GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use GitHub Enterprise Server Backup Utilities 3.8.1 and generate a new full backup using ghe-backup. For more information on using an existing backup, see "Известные проблемы с резервными копиями для вашего экземпляра." [Updated: 2023-07-31]

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

On a freshly set up GitHub Enterprise Server instance without any users, an attacker could create the first admin user.

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.

During an upgrade to GitHub Enterprise Server 3.8.0 on a cluster, after you upgrade nodes other than the primary MySQL node and before you upgrade the primary MySQL node, the following error may appear multiple times after you run ghe-config-apply.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

You can safely ignore this message.

If the root site administrator is locked out of the Management Console after failed login attempts, the account will 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." [Updated: 2023-02-23]

Use of the search API may cause subsequent requests to other interfaces to fail. When this issue occurs, impacted API or web UI users will receive HTTP 5xx responses and this NoMethodError exception will be logged:

NoMethodError (undefined method `starts_with?' for [:ok, "refs/heads/main"]:Array):

On an instance with a GitHub Advanced Security license where secret scanning is enabled, excessive logging in /var/log may cause user-facing errors and degraded system performance if logs consume all free space on the volume. To prevent this issue from impacting users, monitor free space on your instance's root volume. For more information, see "Configuring secret scanning for your appliance" and "Monitoring your appliance." If you suspect that this issue is affecting your instance and you need help, contact GitHub Support. [Updated: 2023-05-03]

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

Projects beta

• Projects, the flexible tool for planning and tracking work on GitHub Enterprise Server, is now available as a beta. A project is an adaptable spreadsheet that integrates issues and pull requests to help users plan and track work effectively. Users can create and customize multiple views, and each view can filter, sort, and group issues and pull requests. Users can also define custom fields to track the unique metadata for a team or project, allowing customization for any needs or processes. This feature is subject to change. For more information, see "Сведения о Projects (beta)."

Instance administration

• Site administrators can improve the security of an instance by creating dedicated user accounts for the Management Console. Only the root site administrator can create user accounts. To control access for the user accounts, assign either the editor or operator role. Operators can manage administrative SSH access for the instance. For more information, see "Managing access to the Management Console."

• To establish or comply with internal policies, site administrators can use the Management Console to configure an instance's policy for retention of data related to checks, including checks data generated by GitHub Actions and the Statuses API. Administrators can enable or disable retention, set a custom retention threshold, or set a custom hard-delete threshold. For more information, see "Configuring applications" [Updated: 2023-03-02]

• When generating support bundles using the ghe-support-bundle command-line utility, site administrators can specify the exact duration to use for collection of data in the bundle. For more information, see "Command-line utilities."

Identity and access management

• Users can review and revoke both browser and GitHub Mobile sessions for a GitHub Enterprise Server instance. For more information, see "Viewing and managing your sessions."

Policies

• Enterprise owners can configure whether repository administrators can enable or disable Dependabot alerts. On instances with a GitHub Advanced Security license, enterprise owners can also set policies to control whether repository administrators can enable GitHub Advanced Security features or secret scanning. For more information, see "Enforcing policies for code security and analysis for your enterprise."

Audit logs

• Enterprise and organization owners can support adherance to the principle of least privilege by granting access to audit log endpoints without providing full administrative privileges. To provide this access, personal access tokens and OAuth apps now support the read:audit_log scope. For more information, see "Using the audit log API for your enterprise."

• Enterprise owners can more easily detect and trace activity associated with authentication tokens by viewing token data in audit log events. For more information, see "Identifying audit log events performed by an access token."

• Enterprise owners can configure audit log streaming to a Datadog endpoint. For more information, see "Streaming the audit log for your enterprise."

GitHub Advanced Security

• Enterprise owners on an instance with a GitHub Advanced Security license can view changes to GitHub Advanced Security, secret scanning, and push protection enablement in the audit log. Organization owners can view changes to custom messages for push protection in the audit log. For more information, see the following documentation.

  • "business_secret_scanning category actions," "business_secret_scanning_push_protection category actions," and "business_secret_scanning_push_protection_custom_message category actions" in "Audit log events for your enterprise"
  • "Reviewing the audit log for your organization"

• Enterprise owners on an instance with a GitHub Advanced Security license can ensure compliance and simplify the rollout of secret scanning and push protection to all organizations on the instance using the REST API. This endpoint supplements the existing web UI, as well as the endpoints for repositories and organizations. For more information, see "Code security and analysis" in the REST API documentation.

• Enterprise and organization owners who use secret scanning on an instance with a GitHub Advanced Security license can use the REST API to specify a custom link to display when push protection blocks a push containing a secret. For more information, see "Code security and analysis" or "Organizations" in the REST API documentation.

• Users on an instance with a GitHub Advanced Security license who dismiss a secret scanning alert can help other users understand the reason for dismissal by providing an optional comment using the web UI or REST API. For more information, see the following documentation.

  • "Managing alerts from secret scanning"
  • "Secret scanning" in the REST API documentation

• Users on an instance with a GitHub Advanced Security license can filter results from the Code Scanning API based on alert severity at either the repository or organization levels. Use the severity parameter to return only code scanning alerts with a specific severity. For more information, see "Code Scanning" in the REST API documentation.

• Users on an instance with a GitHub Advanced Security license can analyze two additional languages for vulnerabilities and errors using CodeQL code scanning. Support for Ruby is generally available, and support for Kotlin is in beta and subject to change.

  • Ruby analysis can detect more than twice the number of common weaknesses (CWEs) it could detect during beta. A total of 30 rules can identify a range of vulnerabilities, including cross-site scripting (XSS), regular expression denial-of-service (ReDoS), SQL injection, and more. Additional library and framework coverage for Ruby-on-Rails ensures that web service developers get even more precise results. GitHub Enterprise Server supports all common Ruby versions, up to and including 3.1.
  • Kotlin support is an extension of existing Java support, and benefits from the existing CodeQL queries for Java, which apply to both mobile and server-side applications. GitHub has also improved and added a range of mobile-specific queries, covering issues such as handling of Intents, Webview validation problems, fragment injection, and more.

  For more information about code scanning, see "About code scanning with CodeQL."

• Users on an instance with a GitHub Advanced Security license who use CodeQL code scanning can customize the build configuration for Go analysis within the GitHub Actions workflow file. Existing CodeQL workflows for Go analysis require no changes, and will continue to be supported. For more information, see "Configuring the CodeQL workflow for compiled languages."

Dependabot

• To improve code security and simplify the process of updating vulnerable dependencies, more users can receive automatic pull requests with dependency updates.

  • GitHub Actions authors can automatically update dependencies within workflow files.
  • Dart or Flutter developers who use Pub can automatically update dependencies within their projects.

  For more information, see "About Dependabot security updates."

• Dart and JavaScript developers on an instance with the dependency graph enabled can receive Dependabot alerts for known vulnerabilities within a project's dependencies.

  • For Dart, the dependency graph detects pubspec.lock and pubspec.yaml files.
  • JavaScript developers who use Node.js and npm can receive alerts for known vulnerabilities within Yarn v2 and v3 manifests. This supplements the existing support for v1 manifests. The dependency graph detects package.json, and yarn.lock files.

  For more information, see the following articles.

  • "About the dependency graph"
  • "Browsing security advisories in the GitHub Advisory Database"
  • "About Dependabot alerts"

• Python developers who use supported package managers on an instance with the dependency graph enabled can receive Dependabot alerts for dependencies within pyproject.toml files that follow the PEP 621 standard. For more information, see "About Dependabot version updates."

• Python developers who receive Dependabot alerts can reduce the number of version updates when a current dependency requirement is already satisfied by a new version. To configure this behavior, use the increase-if-necessary versioning strategy. For more information, see "Configuration options for the dependabot.yml file."

• Enterprise owners can retrieve Dependabot alerts for the instance using the REST API. This endpoint is in beta and subject to change. For more information, see "Dependabot alerts" in the REST API documentation.

• Organization owners can retrieve Dependabot alerts for the organization using the REST API. This endpoint is in beta and subject to change. For more information, see "Dependabot alerts."

• Users can programmatically view and act on Dependabot alerts using the REST API. New endpoints to view, list, and update Dependabot alerts are available in beta. These endpoints are subject to change. For more information, see "Dependabot alerts" in the REST API documentation.

Code security

• To increase visibility into security posture and improve risk analysis, users can access coverage and risk views within the security overview. The coverage view shows enablement across repositories, while the risk view surfaces alerts across repositories. Organization owners, security managers, and repository administrators on an instance with a GitHub Advanced Security license can enable security features from the security overview's coverage view. The views replace the "Overview" page, and are in public beta and subject to change. For more information, see "About the security overview."

• Contributors can define a repository's security policy by creating a SECURITY.md file. To increase the policy's visibility, GitHub Enterprise Server will link to the policy from the repository's Code tab. For more information, see "Adding a security policy to your repository."

• The Dependency review API is generally available, and the associated GitHub Action now allows users to reference a local or external configuration file. For more information, see the following documentation.

  • "Dependency review" in the REST API documentation
  • "Configuring dependency review"

• The GraphQL API provides access to a repository's dependency graph. This feature is in preview and subject to change. For more information, see "Objects" in the GraphQL API documentation.

GitHub Actions

• During configuration of storage for GitHub Actions, site administrators can avoid risks associated with the input of sensitive secrets and access keys by using OIDC to connect to object storage providers. GitHub Actions on GitHub Enterprise Server supports OIDC for connections to AWS, Azure, and Google Cloud Platform. This feature is in beta and subject to change. For more information, see "Enabling GitHub Actions for GitHub Enterprise Server."

• To prevent untrusted logging of data from the set-state and set-output workflow commands, action authors can use environment files for the management of state and output.

  • To use this feature, the runner application must be version 2.297.0 or later. Versions 2.298.2 and later will warn users who use the save-state or set-output commands. These commands will be fully disabled in a future release.
  • To use the updated saveState and setOutput functions, workflows using the GitHub Actions Toolkit must call @actions/core v1.10.0 or later.

  For more information, see "Workflow commands for GitHub Actions."

• The ability to share actions and reusable workflows from private repositories is generally available. Users can share workflows in a private repository with other private repositories owned by the same organization or user account, or with all private repositories on the instance. For more information, see the following documentation.

  • "Managing GitHub Actions settings for a repository"
  • "GitHub Actions Permissions" in the REST API documentation

• Users can improve workflow readability and avoid the need to store non-sensitive configuration data as encrypted secrets by defining configuration variables, which allow reuse across workflows in a repository or organization. This feature is in beta and subject to change. For more information, see "Variables."

• Users can dynamically name workflow runs. run-name accepts expressions, and the dynamic name appears in the list of workflow runs. For more information, see "Workflow syntax for GitHub Actions."

• Users can prevent a job from running on a runner outside the intended group by defining the names of the intended runner groups for a workflow within the runs-on key.

  runs-on:
    group: my-group
    labels: [ self-hosted, label-1 ]
  

  Additionally, GitHub Enterprise Server will no longer allow the creation of runner groups with identical names at the organization and enterprise level. A warning banner will appear for any runner groups within an organization that share a name with a runner group for the enterprise.

• Users can enforce standard CI/CD practices across all of an organization's repositories by defining required workflows. These workflows are triggered as required status checks for all pull requests that target repositories' default branch, which blocks merging until the check passes. This feature is in beta and subject to change. For more information, see "Required workflows."

• To enable standardization of OIDC configurations across cloud deployment workflows, organization owners and repository administrators can configure the subject claim format within OIDC tokens by defining a custom template. For more information, see "About security hardening with OpenID Connect."

• To enable more transparency and control over cache usage within repositories, users who cache dependencies and other reused files with actions/cache can manage caches from the instance's web UI. For more information, see "Caching dependencies to speed up workflows."

Community experience

• Users can set expectations surrounding availability by displaying a local timezone within their profiles. People who view the user's profile or hovercard will see the timezone, as well as how many hours behind or ahead they are of the user's local time. For more information, see "Personalizing your profile."

GitHub Discussions

• To improve discoverability, GitHub Discussions features the following improvements.

  • Repository owners can pin discussions to a specific category.
  • Category titles and descriptions are displayed on the category's page.

Organizations

• To manage how organization members fork repositories, organization owners can set a dedicated forking policy for any organization. This policy must be stricter than an a forking policy set for the enterprise. For more information, see "Managing the forking policy for your organization."

• Organization owners can improve organization security by preventing outside collaborators from requesting the installation of GitHub and OAuth apps. For more information, see "Limiting OAuth App and GitHub App access requests."

Repositories

• To avoid providing full administrative access to a repository when unnecessary, repository administrators can create a custom role that allows users to bypass branch protections. To enforce branch protections for all users with administrative access or bypass permissions, administrators can enable Do not allow bypassing the above settings. For more information, see "Managing custom repository roles for an organization" and "About protected branches."

• Repository administrators can ensure the security and stability of branches by locking the branch. For more information, see "About protected branches."

• In scenarios where someone should review code within a GitHub Actions workflow before the workflow runs, repository administrators can require approval from a user with write access to the repository before a workflow run can be triggered from a private fork. For more information, see "Managing GitHub Actions settings for a repository."

Issues

• The GraphQL API supports creation and removal of the link between a branch and an issue. For more information, see the following documentation.

  • "Creating a branch to work on an issue"
  • "createLinkedBranch" and "deleteLinkedBranch" in the "Mutations" GraphQL API documentation
  • "Objects" in the GraphQL API documentation

Releases

• Users can mark a specific release within a repository as the latest release using the web UI, REST API, or GraphQL API. For more information, see the following documentation.

  • "Managing releases in a repository"
  • "Releases" in the REST API documentation
  • "Objects" in the GraphQL API documentation

Integrations

• Users can save time and switch context less often by receiving and acting on real-time updates about GitHub Enterprise Server activity directly within Slack or Microsoft Teams. GitHub's integrations for these services are now generally available. For more information, see "GitHub extensions and integrations."

When a site administrator runs a command using administrative SSH access, the command is now logged. To help GitHub Support troubleshoot and debug, support bundles include a log containing these commands.

To simplify the discovery of events within enterprise, organization, or user audit logs, the search bar now displays a list of available filters.

Before a site administrator can migrate away from GitHub Enterprise Server using the GitHub Enterprise Importer CLI, the startRepositoryMigration GraphQL API, or the Start an organization migration REST API, the administrator must use the Management Console to configure a blob storage provider for the storage of migration archives. Supported provides include Amazon S3 and Azure Blob Storage. Previously, blob storage was not required and could optionally be configured using gh gei. This change adds support for migrations where the Git source or metadata is larger than 1 GB.

To help users on an instance with a GitHub Advanced Security license better understand detected secrets and take action, secret scanning alerts concerning third-party API keys now include a link to the provider's documentation. For more information, see "About secret scanning."

Users on an instance with a GitHub Advanced Security license will now see the actions that users took on a secret scanning alert directly within the alert's timeline, including when a contributor bypassed push protection for a secret.

Instances with a GitHub Advanced Security license will regularly run a historical scan to detect newly added secret types on repositories with GitHub Advanced Security and secret scanning enabled. Previously, users needed to manually run a historical scan.

On instances with a GitHub Advanced Security license, to ensure that future releases of GitHub Enterprise Server can always display a preview of a detected secret in the APIs or web UI, the detected secrets are now stored separately from source code. Detected secrets are stored using symmetric encryption. [Updated: 2023-02-15]

When using private registries for Dependabot updates, GitHub Enterprise Server behaves more securely. If a private registry is configured for any of the following ecosystems, the instance will no longer make any package requests to public registries.

• Bundler
• Docker
• Gradle
• Maven
• npm
• Nuget
• Python
• Yarn

For more information, see "Configuration options for the dependabot.yml file."

Elixir developers who use self-hosted Hex repositories can configure a private registry for Dependabot version updates on GitHub Enterprise Server. For more information, see "Configuration options for the dependabot.yml file."

Dependabot alerts features the following usability improvements.

• The page for an alert refreshes automatically after Dependabot attempts to create a pull request for an update.
• Alerts are more accurately mapped to pull requests from Dependabot updates.
• To improve the alert for the community, users can suggest improvements to alerts directly in the GitHub Advisory Database.

Users can more easily mention @dependabot. When mentioning users, the Dependabot user account now appears as an autocomplete suggestion.

In repositories with vulnerable dependencies, Dependabot will no longer display a yellow banner. To notify contributors of vulnerable dependencies, the Security tab displays an alert counter.

If a user forks a repository with an existing Dependabot configuration in dependabot.yml, Dependabot updates will be disabled in the fork by default. To enable updates in the fork, the user must visit the repository's code security and analysis settings. For more information, see "Configuring Dependabot version updates."

Integrators who wish to receive a webhook for Dependabot alerts must use the new dependabot_alert webhook. This webhook replaces the repository_vulnerability_alert webhook. For more information, see "Webhook events and payloads."

To improve readability of GitHub Actions workflows that reference other actions by commit SHA, action authors often write a comment including the corresponding semantic version on the line that calls the action. To save time, pull requests for Dependabot version updates will now automatically update the semantic version in these comments.

JavaScript developers who use Node.js, npm, and Dependabot security updates can save time when updating npm projects with transitive dependencies.

• Dependabot can update both parent and child dependencies together. Previously, Dependabot would not update transitive dependencies when the parent required an incompatible specific version range, requiring manual upgrades.
• Dependabot can create pull requests that resolve alerts where an update to a direct dependency would remove the vulnerable transitive dependency from the tree.

For more information, see "About Dependabot security updates."

For people who use Dependabot for version updates in the Docker ecosystem, Dependabot will proactively update Docker image tags in Kubernetes manifests. For more information, see "Configuring Dependabot version updates" and "Configuration options for the dependabot.yml file."

A number of improvements are available to users who contribute to security advisories on GitHub.com, including the following changes.

• To ensure faster review, GitHub prompts users to add a reason for the change.
• To ensure that the contribution matches the user's intent, GitHub will not reorder reference links in the diff.

GitHub Actions features the following discoverability and accessibility improvements.

• The navigation experience for searching workflows and workflow runs is improved.
• Added structure better represents the hierarchy between caller and called reusable workflows.
• The mobile browsing experience is more consistent, and supports multiple viewport sizes.

GitHub Actions workflows will no longer trigger endlessly when using GITHUB_TOKEN with workflow_dispatch and repository_dispatch events. Prior to this change, events triggered by GITHUB_TOKEN would not create a new workflow run. For more information, see "Triggering a workflow."

For scheduled runs of GitHub Actions workflows, users will see additional information about the repository, organization, and enterprise within the payload for github.event.

Users of GitHub Actions have better insight into the progress of a job when using environment protection rules. The workflow_job webhook supports a new waiting state whenever a job is awaiting an environment protection rule. Also, when a job refers to an environment key in its YAML definition, the workflow_job webhook payload will also include a new property, deployment. deployment contains metadata about the deployment that the check run created. For more information, see "Using environments for deployment."

Organization owners can find more meaningful context within audit log events.

• business.sso_response and org.sso_response events appear in the REST API and payloads for audit log streaming.
• repo.rename, project.rename, and protected_branch.update_name events include the current and past names for these renamed within the old_name field.
• Events for Dependabot alerts contain alert_number, ghsa_id, dismiss_reason, and dismiss_comment fields, in addition to a link back to the alert and an accurate timestamp.

Users can view a list that contains all of an organization's followers from the organization's profile.

The banner displayed atop an archived repository in the web UI now includes the repository's archival date.

The Conversations and Files tabs in pull requests now load more quickly due to deferred syntax highlighting.

To provide a more consistent experience between the web UI and users' workstations, and to speed up the process of checking whether users can merge a pull request automatically, GitHub Enterprise Server now uses the merge-ort strategy. For more information, see Merge strategies in the Git documentation.

To improve the display of the initial comment in pull requests that contain one commit, GitHub Enterprise Server now automatically reformats detailed commit messages to adhere to GitHub's Markdown conventions.

Before squash-merging a pull request, the web UI displays the email address of the commit's author. Previously, the commit author was only displayed when merging with a merge commit.

After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

After restoration of a backup created using GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use GitHub Enterprise Server Backup Utilities 3.8.1 and generate a new full backup using ghe-backup. For more information on using an existing backup, see "Известные проблемы с резервными копиями для вашего экземпляра." [Updated: 2023-07-31]

In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. After upgrading from GitHub Enterprise Server 3.8, on an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

CA certificate key too weak

To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

On a freshly set up GitHub Enterprise Server instance without any users, an attacker could create the first admin user.

Custom firewall rules are removed during the upgrade process.

When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

Actions services need to be restarted after restoring an instance from a backup taken on a different host.

In a repository's settings, enabling the option to allow users with read access to create discussions does not enable this functionality.

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.

In some cases, while converting an issue to a discussion, the conversion process may hang. In this situation, an enterprise owner can try the following troubleshooting steps to resolve the issue.

1. At the end of the stuck discussion's URL, note the discussion's number.
2. In the web UI, browse to the repository where the conversion is stuck.
3. In the top-right corner of the web UI, click .
4. Under "Collaboration", click NUMBER discussions.
5. In the list, click the number from step 1.
6. Under "Conversion", click Enqueue conversion job.
7. Wait a few minutes, then check the issue's status.

If the conversion still hasn't completed, contact GitHub Enterprise Support for assistance.

If the root site administrator is locked out of the Management Console after failed login attempts, the account will 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 "Устранение неполадок с доступом к консоли управления." [Updated: 2023-02-23]

During an upgrade to GitHub Enterprise Server 3.8.0 on a cluster, after you upgrade nodes other than the primary MySQL node and before you upgrade the primary MySQL node, the following error may appear multiple times after you run ghe-config-apply.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

You can safely ignore this message.

After upgrading to GitHub Enterprise Server 3.8.0, commands run via SSH on any of the instance's nodes will not be logged in /var/log/ssh-console-audit.log. To resolve this issue, SSH into the affected node and run the following command.

source /etc/bash.bashrc

On instances in a high availability configuration, git push operations may fail in the following situations.

• During creation of the repository on a replica node
• After failure to create the repository on a replica node, before automatic repair of the repository [Updated: 2023-03-17]

On instances in a high availability configuration, site administrators should only run the ghe-repl-start and ghe-repl-stop commands while the instance is in maintenance mode. For more information, see "Включение и планирование режима обслуживания" and "Сведения о настройке высокого уровня доступности." [Updated: 2023-03-17]

Use of the search API may cause subsequent requests to other interfaces to fail. When this issue occurs, impacted API or web UI users will receive HTTP 5xx responses and this NoMethodError exception will be logged:

NoMethodError (undefined method `starts_with?' for [:ok, "refs/heads/main"]:Array):

On an instance with a GitHub Advanced Security license where secret scanning is enabled, excessive logging in /var/log may cause user-facing errors and degraded system performance if logs consume all free space on the volume. To prevent this issue from impacting users, monitor free space on your instance's root volume. For more information, see "Configuring secret scanning for your appliance" and "Monitoring your appliance." If you suspect that this issue is affecting your instance and you need help, contact GitHub Support. [Updated: 2023-05-03]

In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-08-24]

When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

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. [Updated 2023-12-13]

Unsecure algorithms disabled for administrative SSH connections

• GitHub has disabled the use of unsecure algorithms for SSH connections to the administrative shell.

Deprecation of the repository_vulnerability_alert webhook

• For integrators who wish to receive webhooks for Dependabot alerts activity, the dependabot_alert webhook replaces the repository_vulnerability_alert webhook. For more information, see "Webhook events and payloads."

"Использование секретов в GitHub Actions" incorrectly indicated that secrets for GitHub Actions are encrypted in the instance's database. The article has been updated to reflect that secrets are not encrypted on the instance. To encrypt secrets at rest, you must encrypt your instance's block storage device. For more information, refer to the documentation for your hypervisor or cloud service. [Updated: 2023-06-01]

"Repositories" incorrectly indicated that repository administrators can require pull request approval by someone other than the last pusher. This feature is unavailable in GitHub Enterprise Server 3.8, and is available in GitHub Enterprise Server 3.10. For more information, see "Заметки о выпуске." [Updated 2023-08-07]