1
0
mirror of synced 2026-01-06 15:01:04 -05:00
Files
docs/data/release-notes/enterprise-server/3-13/14.yml
release-controller[bot] 92fb340b5b Patch release notes for GitHub Enterprise Server (#55292)
Co-authored-by: Release-Controller <releasecontroller@github.com>
Co-authored-by: Rachael Rose Renk <91027132+rachaelrenk@users.noreply.github.com>
Co-authored-by: Sarah Schneider <sarahs@github.com>
Co-authored-by: Sarah Schneider <sarahs@users.noreply.github.com>
Co-authored-by: Alex Cyphus <983880+ACyphus@users.noreply.github.com>
2025-04-17 22:20:53 +00:00

45 lines
5.1 KiB
YAML

date: '2025-04-17'
sections:
security_fixes:
- |
**HIGH**: An attacker could execute arbitrary code, potentially leading to privilege escalation and system compromise, by exploiting the pre-receive hook functionality to bind to dynamically allocated ports that become temporarily available, such as during a hot patch upgrade. This vulnerability is only exploitable under specific operational conditions, such as during the hot patching process, and requires either site administrator permissions or a user with privileges to modify repositories containing pre-receive hooks. GitHub has requested CVE ID: [CVE-2025-3509](https://www.cve.org/cverecord?id=CVE-2025-3509) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/).
- |
**MEDIUM:** An attacker could view private repository names, which the signed-in user is not authorized to see, in the GitHub Advanced Security Overview. This was due to a missing authorization check and occurred when filtering with _only_ `archived:`. GitHub has requested CVE ID [CVE-2025-3124](https://www.cve.org/CVERecord?id=CVE-2025-3124) for this vulnerability.
bugs:
- |
In the commit author filter dropdown on the commit history page for a repository, users could not search for a specific author (such as `foo`) if their search query had already returned a similar username (such as `foobar`).
- |
Various repository content API endpoints were unable to parse revisions containing invalid UTF-8 byte sequences, triggering `500 Internal Server Error` responses.
- |
The "Get allowed actions and reusable workflows" APIs for enterprises, organizations, and repositories did not include the `verified_allowed` response field.
changes:
- |
Upgrading using a hot patch package will fail if the Elasticsearch status is not green. To help prevent post-upgrade problems when the Elasticsearch status is red, usually in a high-availability configuration, a check has been added.
- |
Merging a pull request using the "Rebase and merge" option is now limited to 100 commits. If you have a pull request with more than 100 commits, you need to either create a merge commit, or squash and merge, or split the commits up into multiple pull requests.
known_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 "[AUTOTITLE](/admin/configuration/administering-your-instance-from-the-management-console/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account)."
- |
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.
- |
For an instance in a cluster configuration and with GitHub Actions enabled, restoring a cluster from backup requires targeting the primary DB node.
- |
When following the steps for [Replacing the primary MySQL node](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed.
- |
Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
- |
{% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
- |
When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
- |
When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed.
- |
Services may respond with a `503` status due to an out of date `haproxy` configuration. This can usually be resolved with a `ghe-config-apply` run.
- |
After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance.
- |
After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows.