diff --git a/content/copilot/how-tos/copilot-cli/use-copilot-cli/overview.md b/content/copilot/how-tos/copilot-cli/use-copilot-cli/overview.md index 8a96504d3b22..d8f7740f27e4 100644 --- a/content/copilot/how-tos/copilot-cli/use-copilot-cli/overview.md +++ b/content/copilot/how-tos/copilot-cli/use-copilot-cli/overview.md @@ -263,7 +263,23 @@ For more information, see [AUTOTITLE](/copilot/how-tos/copilot-cli/customize-cop {% data variables.copilot.copilot_cli_short %} comes with the {% data variables.product.github %} MCP server already configured. This MCP server allows you to interact with resources on {% data variables.product.prodname_dotcom_the_website %}—for example, allowing you to merge pull requests from the CLI. -To extend the functionality available to you in {% data variables.copilot.copilot_cli_short %}, you can add more MCP servers: +To extend the functionality available to you in {% data variables.copilot.copilot_cli_short %}, you can add more MCP servers. + +To add a remote HTTP server directly from your terminal without starting an interactive session, use: + +```shell copy +copilot mcp add --transport http SERVER-NAME URL +``` + +For example: + +```shell copy +copilot mcp add --transport http sentry https://mcp.sentry.dev/mcp +``` + +For local servers and additional options, see [AUTOTITLE](/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers#using-the-copilot-mcp-add-subcommand). + +Alternatively, add a server from an interactive session: 1. Use the following slash command: diff --git a/content/copilot/reference/ai-models/supported-models.md b/content/copilot/reference/ai-models/supported-models.md index 08ee0de02638..5c28b3d96c59 100644 --- a/content/copilot/reference/ai-models/supported-models.md +++ b/content/copilot/reference/ai-models/supported-models.md @@ -104,11 +104,13 @@ The following table lists AI models that are retired or scheduled for retirement | Model name | Retirement date | Suggested alternative | |-------------------------------------------------------------|-----------------------------|-----------------------------------| | {% for model in tables.copilot.model-deprecation-history %} | -| {{ model.name }} | {{ model.retirement_date }} | {{ model.suggested_alternative }} | +| {{ model.name }}{% if model.name == 'Claude Sonnet 4.6' %}[^claude-sonnet-46-annual]{% endif %} | {{ model.retirement_date }} | {{ model.suggested_alternative }} | | {% endfor %} | {% endrowheaders %} +[^claude-sonnet-46-annual]: {% data variables.copilot.copilot_claude_sonnet_46 %} remains available to individual {% data variables.product.prodname_copilot_short %} subscribers on annual plans. The retirement of {% data variables.copilot.copilot_claude_sonnet_46 %} does not apply to these subscribers. + ## Supported AI models per client The following table shows which models are available in each client. diff --git a/content/copilot/reference/copilot-cli-reference/cli-command-reference.md b/content/copilot/reference/copilot-cli-reference/cli-command-reference.md index bd9cbfcdad15..a3ef4694186d 100644 --- a/content/copilot/reference/copilot-cli-reference/cli-command-reference.md +++ b/content/copilot/reference/copilot-cli-reference/cli-command-reference.md @@ -653,18 +653,30 @@ Use `copilot mcp` to manage MCP server configurations from the command line with |------------|-------------| | `list [--json]` | List all configured MCP servers grouped by source, including plugin-provided servers. | | `get [--json]` | Show configuration and tools for a specific server. For plugin-provided servers, also shows the source plugin name and version. | -| `add ` | Add a server to the user configuration. Writes to `~/.copilot/mcp-config.json`. | +| `add [options] [url]` | Add a server to the user configuration. Writes to `~/.copilot/mcp-config.json`. | | `remove ` | Remove a user-level server. Workspace servers must be edited in their configuration files directly. | +For local (stdio) servers, provide the command after `--`: + +```shell copy +copilot mcp add SERVER-NAME -- COMMAND [ARGS...] +``` + +For remote HTTP or SSE servers, specify the transport and provide the URL: + +```shell copy +copilot mcp add --transport http SERVER-NAME URL +``` + **`copilot mcp add` options:** | Option | Description | |--------|-------------| | `-- [args...]` | Command and arguments for local (stdio) servers. | -| `--url ` | URL for remote servers. | -| `--type ` | Transport type: `local`, `stdio`, `http`, or `sse`. | +| `` | URL for remote servers. | +| `--transport ` | Transport type: `stdio`, `http`, or `sse`. The default is `stdio`. | | `--env KEY=VALUE` | Environment variable (repeatable). | -| `--header KEY=VALUE` | HTTP header for remote servers (repeatable). | +| `--header "HEADER: VALUE"` | HTTP header for remote servers (repeatable). | | `--tools ` | Tool filter: `"*"` for all, a comma-separated list, or `""` for none. | | `--timeout ` | Timeout in milliseconds. | | `--json` | Output added configuration as JSON. | diff --git a/content/copilot/reference/github-copilot-app-reference/index.md b/content/copilot/reference/github-copilot-app-reference/index.md index 018c32873244..06e4bda07a62 100644 --- a/content/copilot/reference/github-copilot-app-reference/index.md +++ b/content/copilot/reference/github-copilot-app-reference/index.md @@ -1,10 +1,11 @@ --- title: '{% data variables.copilot.github_copilot_app %} reference' shortTitle: '{% data variables.copilot.github_copilot_app %} reference' -intro: 'Find reference information for slash commands and {% data variables.product.github %}-provided built-in skills in the {% data variables.copilot.github_copilot_app %}.' +intro: 'Find reference information for repository configuration, slash commands, and {% data variables.product.github %}-provided built-in skills in the {% data variables.copilot.github_copilot_app %}.' versions: feature: copilot children: + - /repository-configuration - /slash-commands - /built-in-skills contentType: reference diff --git a/content/copilot/reference/github-copilot-app-reference/repository-configuration.md b/content/copilot/reference/github-copilot-app-reference/repository-configuration.md new file mode 100644 index 000000000000..89ed9b6f89ef --- /dev/null +++ b/content/copilot/reference/github-copilot-app-reference/repository-configuration.md @@ -0,0 +1,160 @@ +--- +title: Repository configuration for the GitHub Copilot app +shortTitle: Repository configuration +allowTitleToDifferFromFilename: true +intro: 'Define repository-specific instructions, scripts, and automation behavior for the {% data variables.copilot.github_copilot_app %}.' +product: '{% data reusables.gated-features.github-app %}
Download {% data variables.copilot.github_copilot_app %} {% octicon "link-external" height:16 %}' +versions: + feature: copilot +contentType: reference +category: + - Author and optimize with Copilot + - Configure Copilot +--- + +Use `.github/github-app.yml` in your repository to define how the {% data variables.copilot.github_copilot_app %} should behave for that project. + +You can also edit these project settings in the app UI. If `.github/github-app.yml` already exists, UI changes are written back to that file. If it does not exist yet, you can create it from current project settings in the app. + +## About the config file location + +Create the file at: + +```text copy +.github/github-app.yml +``` + +The app also supports the legacy filename `.github/copilot-desktop.yml` for backward compatibility. + +For UI-based customization steps, see [AUTOTITLE](/copilot/how-tos/github-copilot-app/customize-github-copilot-app). + +## Review and trust the configuration + +When the app detects a configuration from the repository, it does not apply repository instructions, scripts, or other settings from the file until you review and accept the configuration. This protects you from running commands or applying settings that were added by another contributor. Configurations that you create or update through the app UI are trusted automatically. + +> [!WARNING] +> Before accepting a repository configuration, review every configured command and the dependencies it runs. Scripts and their child processes receive the {% data variables.product.github %} credentials described later in this article, so never configure them to log or persist these environment variables. + +If the file changes outside the app, including changes to whitespace or comments, you must review and accept the updated configuration before the app applies it. Until you accept the current version, the app continues to use the project settings that were previously configured in the app. + +## Example configuration + +```yaml copy +instructions: | + Use bun instead of npm. + +scripts: + - name: Setup + command: bun install + triggers: + - session.create + - name: Run + command: bun run dev + - name: Archive cleanup + command: rm -rf node_modules + triggers: + - session.archive + +server_ready_pattern: '(?i)Local:\s+(https?://\S+)' +auto_open_in_browser: true + +automation: + auto_issue_session: true + remote_control: false +``` + +## Configure instructions and scripts + +### `instructions` + +Use `instructions` to add repository-specific guidance to the system prompt for sessions in the project. If you also configure global instructions in the app, the global instructions are applied first, followed by the project instructions. + +### `scripts` + +Use `scripts` to define commands that appear in the app and can run manually or on specific triggers. + +Each script item supports: + +* `name` (`string`): Display name in the UI. +* `command` (`string`): Command to run. +* `triggers` (`string[]`, optional): Events that auto-run the script. + +Scripts without `triggers` are manual. + +### Trigger values + +Use canonical trigger values in your file: + +* `session.create` +* `session.archive` + +The app also accepts these legacy aliases when parsing existing files: + +* `workspace.create` (alias for `session.create`) +* `workspace.archive` (alias for `session.archive`) + +When a triggered script runs, `COPILOT_SCRIPT_TRIGGER` is set to the canonical value: + +* `session.create` +* `session.archive` + +## Configure server detection and browser behavior + +### `server_ready_pattern` + +`server_ready_pattern` is a regular expression used to detect when a run script has started a server. + +Patterns use the syntax supported by Rust's `regex` crate. For syntax details, see [Syntax](https://docs.rs/regex/1/regex/#syntax) in the crate documentation. If the pattern is invalid, the app uses its default server detection pattern. + +Use a first capture group for the detected URL or port. The app reads capture group `1`: + +* If the capture is a URL (`http://...` or `https://...`), the URL is used. +* If the capture is only a port number (for example `3000`), the app converts it to `http://localhost:3000`. + +### `auto_open_in_browser` + +If `auto_open_in_browser` is `true`, the app opens the detected run URL in the integrated browser. If this field is omitted, the effective default is `true`. + +## Configure automation behavior + +Set automation options under `automation`: + +* `automation.auto_issue_session` (`boolean`) controls whether the app automatically starts a session with issue context. If omitted, the effective default is `true`. +* `automation.remote_control` (`boolean`) controls whether sessions can be accessed from the {% data variables.product.github %} web interface or {% data variables.product.prodname_mobile %}. If omitted, the effective default is `false`. + +If your {% data variables.product.prodname_copilot_short %} seat comes from an organization, the applicable "Store local sessions in the Cloud" policy must be set to "View and control" for remote control to be available. Enterprise-managed `remoteControl` settings can further restrict remote control even when `automation.remote_control` is `true`. For more information, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/about-remote-control) and [AUTOTITLE](/copilot/reference/enterprise-administrators/enterprise-managed-settings). + +## Runtime environment variables for scripts + +Scripts run with these app-provided environment variables: + +| Variable | Description | +| --- | --- | +| `COPILOT_WORKSPACE_NAME` | Current workspace name. | +| `COPILOT_WORKSPACE_PATH` | Absolute path to the workspace. | +| `COPILOT_ROOT_PATH` | Absolute path to the project root checkout. | +| `COPILOT_DEFAULT_BRANCH` | Project default branch. | +| `COPILOT_PORT` | App WebSocket port for the current workspace context. | +| `COPILOT_SCRIPT_TRIGGER` | Trigger that launched the script (only set for triggered scripts). | +| `GH_TOKEN` | Token for the selected {% data variables.product.github %} account. | +| `GH_HOST` | Host for the selected {% data variables.product.github %} account. | +| `COPILOT_GH_ACCOUNT_*` | Host- and account-specific tokens for every signed-in account, including the selected account. | + +For each `COPILOT_GH_ACCOUNT_*` variable, the app lowercases the host and login, leaves ASCII letters and digits unchanged, and replaces every other UTF-8 byte with its uppercase hexadecimal value surrounded by underscores. The variable name uses the format `COPILOT_GH_ACCOUNT__`. For example, the token for `alice` on `github.com` is `COPILOT_GH_ACCOUNT_github_2E_com_alice`, and the token for `user` on `ghe-example.com` is `COPILOT_GH_ACCOUNT_ghe_2D_example_2E_com_user`. + +## Legacy compatibility + +For backward compatibility, the app can still parse the older object-based `scripts` shape: + +```yaml copy +scripts: + setup: bun install + run: bun run dev + archive: rm -rf node_modules +``` + +In this legacy shape: + +* `setup` maps to a script with the create trigger. +* `archive` maps to a script with the archive trigger. +* `run` maps to manual script entries and can be either a single command string or a list of `{ name, command }` objects. diff --git a/data/release-notes/enterprise-server/3-17/16.yml b/data/release-notes/enterprise-server/3-17/16.yml index f5aa94a0a680..c907858fc154 100644 --- a/data/release-notes/enterprise-server/3-17/16.yml +++ b/data/release-notes/enterprise-server/3-17/16.yml @@ -9,6 +9,8 @@ sections: **HIGH**: An attacker with local access to the instance could escalate privileges to root by exploiting the Dirty Frag Linux kernel vulnerabilities in the IPsec ESP and RxRPC networking subsystems. GitHub has requested [CVE-2026-43284](https://ubuntu.com/security/CVE-2026-43284) and [CVE-2026-43500](https://ubuntu.com/security/CVE-2026-43500) for these vulnerabilities. - | **HIGH**: An attacker could extract sensitive environment variables from a GitHub Enterprise Server instance through a timing side-channel attack against the security advisories package lookup feature. On instances with GitHub Packages enabled, the package URL endpoint did not validate the supplied package name, enabling a Server-Side Request Forgery (SSRF) to internal services. This required no authentication when private mode was disabled, or any authenticated user otherwise. To mitigate this issue, GitHub removed the affected endpoint from GitHub Enterprise Server. GitHub has requested CVE ID [CVE-2026-8606](https://www.cve.org/cverecord?id=CVE-2026-8606) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + **MEDIUM**: An attacker could render a GitHub Enterprise Server instance unresponsive, causing a denial of service, by sending a crafted form-encoded HTTP POST request containing deeply nested parameters that forced excessive CPU consumption during parameter parsing and exhausted the request-handling worker pool. GitHub parsed parameters before routing and authentication, so an attacker could use any POST endpoint without an account or privileges. GitHub has requested CVE ID [CVE-2026-15996](https://www.cve.org/cverecord?id=CVE-2026-15996) for this vulnerability. - | Packages have been updated to the latest security versions. bugs: diff --git a/data/release-notes/enterprise-server/3-17/19.yml b/data/release-notes/enterprise-server/3-17/19.yml new file mode 100644 index 000000000000..9e458f2987fd --- /dev/null +++ b/data/release-notes/enterprise-server/3-17/19.yml @@ -0,0 +1,80 @@ +date: '2026-08-05' +sections: + security_fixes: + - | + **HIGH**: A path traversal vulnerability allowed an unauthenticated attacker to delete the user storage directory on the GitHub Enterprise Server instance, including Git LFS objects, release assets, attachments, and avatars, via the unsanitized X-GitHub-Request-Id request header. Exploitation required network access to the instance and worked when private mode was enabled. GitHub has requested CVE ID [CVE-2026-17556](https://www.cve.org/cverecord?id=CVE-2026-17556) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + Some internal, auto-generated secrets were not redacted when users compiled a support bundle. + bugs: + - | + `ghe-service-list` omitted unhealthy Nomad-backed services from its output on single-node and high-availability appliances. Stopped or failed services, such as `babeld` or `nginx`, appeared in neither the `active` nor `inactive` section. + - | + Administrators could not remove a node with `ghe-remove-node` when the provided hostname was a substring of another node hostname. + - | + When administrators generated a support bundle with `ghe-support-bundle` while OpenTelemetry was enabled, a VictoriaMetrics export failure could produce a corrupt bundle because a log message was sent to `stdout` instead of `stderr`. + - | + Organizations that had upgraded from GitHub Enterprise Server 3.15 to 3.17 and had previously added **Organization admin** to delegated bypass approvers experienced security configurations that displayed the **read** role in the bypass list dropdown. This display was misleading, and **read** users were not granted bypass approval permissions. + - | + On instances where a GitHub App listed the repositories for its installation through the REST API, response time and CPU usage on the appliance increased with the number of repositories the installation could access. For installations with access to many repositories, or on instances with large configuration sets, this could make these requests slow and contribute to sustained high CPU on the appliance. Repository configuration for these requests is loaded in a single batch instead of separately for each repository. + - | + On instances with large organizations, listing organization members (for example, via the `membersWithRole` GraphQL API connection) could be slow and consume excessive CPU because a permission check was evaluated for each member instead of once per organization. + - | + When a user deleted an organization that owned GitHub Apps, repositories owned by that organization were not deleted. + - | + Maintenance jobs did not correctly process very large repositories whose sizes exceeded the capacity of a 32-bit signed integer database column. + changes: + - | + Improvements to authorization, migration APIs, and bug fixes supporting increased migration fidelity. + - | + To guard against rare image corruption caused by an unexpected restart or interruption during an upgrade, the integrity of Docker images is now verified after an upgrade completes. If a corrupted image is detected, a warning is logged so an administrator can recover it. + - | + The size limit for `ghe-migrator` exports (80GB uncompressed, 40GB compressed) has been removed. If disk space is a concern, site administrators can configure a limit of their choice with the `ENTERPRISE_MIGRATIONS_MAX_EXPORT_ARCHIVE_SIZE_GB` environment variable. + - | + Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/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. + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may time out on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps. + - | + {% 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`. + - | + An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning. + - | + When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded. + - | + When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + In a cluster, the host running restore requires access to the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + Unexpected elements may appear in the UI on the repository overview page for locked repositories. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. + - | + Git versions are mismatched between containers on the instance. + - | + Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-18/10.yml b/data/release-notes/enterprise-server/3-18/10.yml index b530661e3420..7c2aa4471c5c 100644 --- a/data/release-notes/enterprise-server/3-18/10.yml +++ b/data/release-notes/enterprise-server/3-18/10.yml @@ -9,6 +9,8 @@ sections: **HIGH**: An attacker with local access to the instance could escalate privileges to root by exploiting the Dirty Frag Linux kernel vulnerabilities in the IPsec ESP and RxRPC networking subsystems. GitHub has requested [CVE-2026-43284](https://ubuntu.com/security/CVE-2026-43284) and [CVE-2026-43500](https://ubuntu.com/security/CVE-2026-43500) for these vulnerabilities. - | **HIGH**: An attacker could extract sensitive environment variables from a GitHub Enterprise Server instance through a timing side-channel attack against the security advisories package lookup feature. On instances with GitHub Packages enabled, the package URL endpoint did not validate the supplied package name, enabling a Server-Side Request Forgery (SSRF) to internal services. This required no authentication when private mode was disabled, or any authenticated user otherwise. To mitigate this issue, GitHub removed the affected endpoint from GitHub Enterprise Server. GitHub has requested CVE ID [CVE-2026-8606](https://www.cve.org/cverecord?id=CVE-2026-8606) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + **MEDIUM**: An attacker could render a GitHub Enterprise Server instance unresponsive, causing a denial of service, by sending a crafted form-encoded HTTP POST request containing deeply nested parameters that forced excessive CPU consumption during parameter parsing and exhausted the request-handling worker pool. GitHub parsed parameters before routing and authentication, so an attacker could use any POST endpoint without an account or privileges. GitHub has requested CVE ID [CVE-2026-15996](https://www.cve.org/cverecord?id=CVE-2026-15996) for this vulnerability. - | Packages have been updated to the latest security versions. bugs: diff --git a/data/release-notes/enterprise-server/3-18/13.yml b/data/release-notes/enterprise-server/3-18/13.yml new file mode 100644 index 000000000000..9b72ca97ca4f --- /dev/null +++ b/data/release-notes/enterprise-server/3-18/13.yml @@ -0,0 +1,92 @@ +date: '2026-08-05' +sections: + security_fixes: + - | + **HIGH**: A path traversal vulnerability allowed an unauthenticated attacker to delete the user storage directory on the GitHub Enterprise Server instance, including Git LFS objects, release assets, attachments, and avatars, via the unsanitized X-GitHub-Request-Id request header. Exploitation required network access to the instance and worked when private mode was enabled. GitHub has requested CVE ID [CVE-2026-17556](https://www.cve.org/cverecord?id=CVE-2026-17556) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + Some internal, auto-generated secrets were not redacted when users compiled a support bundle. + bugs: + - | + On a {% data variables.product.prodname_ghe_server %} cluster upgrade, if all Consul server nodes restarted concurrently, the cluster could lose its Nomad leader and fail to recover, causing the upgrade to loop and fail rather than complete. + - | + On a {% data variables.product.prodname_ghe_server %} cluster with multiple nodes, requests to the container registry could fail with `503` errors if the container registry service was running on a different node than the one handling the request. + - | + `ghe-service-list` omitted unhealthy Nomad-backed services from its output on single-node and high-availability appliances. Stopped or failed services, such as `babeld` or `nginx`, appeared in neither the `active` nor `inactive` section. + - | + Administrators could not remove a node with `ghe-remove-node` when the provided hostname was a substring of another node hostname. + - | + On clustered instances, `ghe-remove-node` could incorrectly determine that a web or job node was the last `web-server` or `job-server` in the cluster. + - | + During hotpatching, custom `sshd_config` directives, such as directives added by cloud guest agents, were overwritten instead of being preserved as they were during feature upgrades. + - | + When administrators generated a support bundle with `ghe-support-bundle` while OpenTelemetry was enabled, a VictoriaMetrics export failure could produce a corrupt bundle because a log message was sent to `stdout` instead of `stderr`. + - | + For organizations that applied a security configuration to a large number of repositories at once, background job processing could be overwhelmed and leave some repositories stuck in the `attaching` state. + - | + On instances where a GitHub App listed the repositories for its installation through the REST API, response time and CPU usage on the appliance increased with the number of repositories the installation could access. For installations with access to many repositories, or on instances with large configuration sets, this could make these requests slow and contribute to sustained high CPU on the appliance. Repository configuration for these requests is loaded in a single batch instead of separately for each repository. + - | + On instances with large organizations, listing organization members (for example, via the `membersWithRole` GraphQL API connection) could be slow and consume excessive CPU because a permission check was evaluated for each member instead of once per organization. + - | + When a user deleted an organization that owned GitHub Apps, repositories owned by that organization were not deleted. + - | + Maintenance jobs did not correctly process very large repositories whose sizes exceeded the capacity of a 32-bit signed integer database column. + - | + When site administrators collected support bundles, secrets in Slack callback URLs were not sanitized. + - | + On instances that use `actions-rate-limiting.queue-runs-per-minute`, queue run rate limiting could be calculated incorrectly. + changes: + - | + Improvements to authorization, migration APIs, and bug fixes supporting increased migration fidelity. + - | + The size limit for `ghe-migrator` exports (80GB uncompressed, 40GB compressed) has been removed. If disk space is a concern, site administrators can configure a limit of their choice with the `ENTERPRISE_MIGRATIONS_MAX_EXPORT_ARCHIVE_SIZE_GB` environment variable. + - | + Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/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. + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may time out on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps. + - | + {% 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`. + - | + An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning. + - | + When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded. + - | + When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + In a cluster, the host running restore requires access to the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + Unexpected elements may appear in the UI on the repository overview page for locked repositories. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + The setting to define private registries at the organization level for code scanning is only available if Dependabot is also enabled for the instance. + - | + Custom NTP settings are removed during the upgrade process. + - | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. + - | + Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-19/10.yml b/data/release-notes/enterprise-server/3-19/10.yml new file mode 100644 index 000000000000..522d7e5d3d17 --- /dev/null +++ b/data/release-notes/enterprise-server/3-19/10.yml @@ -0,0 +1,98 @@ +date: '2026-08-05' +sections: + security_fixes: + - | + **HIGH**: A path traversal vulnerability allowed an unauthenticated attacker to delete the user storage directory on the GitHub Enterprise Server instance, including Git LFS objects, release assets, attachments, and avatars, via the unsanitized X-GitHub-Request-Id request header. Exploitation required network access to the instance and worked when private mode was enabled. GitHub has requested CVE ID [CVE-2026-17556](https://www.cve.org/cverecord?id=CVE-2026-17556) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + Some internal, auto-generated secrets were not redacted when users compiled a support bundle. + bugs: + - | + On a {% data variables.product.prodname_ghe_server %} cluster upgrade, if all Consul server nodes restarted concurrently, the cluster could lose its Nomad leader and fail to recover, causing the upgrade to loop and fail rather than complete. + - | + On a {% data variables.product.prodname_ghe_server %} cluster with multiple nodes, requests to the container registry could fail with `503` errors if the container registry service was running on a different node than the one handling the request. + - | + `ghe-service-list` omitted unhealthy Nomad-backed services from its output on single-node and high-availability appliances. Stopped or failed services, such as `babeld` or `nginx`, appeared in neither the `active` nor `inactive` section. + - | + Administrators could not remove a node with `ghe-remove-node` when the provided hostname was a substring of another node hostname. + - | + On clustered instances, `ghe-remove-node` could incorrectly determine that a web or job node was the last `web-server` or `job-server` in the cluster. + - | + During hotpatching, custom `sshd_config` directives, such as directives added by cloud guest agents, were overwritten instead of being preserved as they were during feature upgrades. + - | + When administrators generated a support bundle with `ghe-support-bundle` while OpenTelemetry was enabled, a VictoriaMetrics export failure could produce a corrupt bundle because a log message was sent to `stdout` instead of `stderr`. + - | + Users experienced unnecessary reconnects or intermittent delivery delays in Kafka Lite-backed features when idle connections timed out too aggressively. GitHub Enterprise Server updated the idle connection timeout behavior to better preserve stable idle connections and reduce avoidable disruptions. + - | + For organizations that applied a security configuration to a large number of repositories at once, background job processing could be overwhelmed and leave some repositories stuck in the `attaching` state. + - | + On instances where a GitHub App listed the repositories for its installation through the REST API, response time and CPU usage on the appliance increased with the number of repositories the installation could access. For installations with access to many repositories, or on instances with large configuration sets, this could make these requests slow and contribute to sustained high CPU on the appliance. Repository configuration for these requests is loaded in a single batch instead of separately for each repository. + - | + Cached license information was not cleared until the instance was restarted. + - | + On instances with large organizations, listing organization members (for example, via the `membersWithRole` GraphQL API connection) could be slow and consume excessive CPU because a permission check was evaluated for each member instead of once per organization. + - | + When a user deleted an organization that owned GitHub Apps, repositories owned by that organization were not deleted. + - | + Maintenance jobs did not correctly process very large repositories whose sizes exceeded the capacity of a 32-bit signed integer database column. + - | + A repair of a standalone repository could fail with the error `not a standalone repository` if the repair detected changes only to the repository's wiki. + - | + When site administrators collected support bundles, secrets in Slack callback URLs were not sanitized. + - | + Users experienced stale or idle client connections that were not cleaned up promptly, which could lead to unnecessary resource usage over time. Idle client connections are now reaped more reliably to improve connection lifecycle management. + - | + On instances that use `actions-rate-limiting.queue-runs-per-minute`, queue run rate limiting could be calculated incorrectly. + changes: + - | + Improvements to authorization, migration APIs, and bug fixes supporting increased migration fidelity. + - | + On large GitHub Enterprise Server instances, kafka-lite and Redis memory limits scale with CPU count to reduce event-processing bottlenecks. Existing defaults are unchanged for smaller instances. + - | + MySQL memory allocation now auto-scales on large-memory appliances. Appliances with 84 GB or more of RAM receive proportionally larger InnoDB buffer pool caps (up to 512 GB), and an explicitly configured `ghe-config mysql.max-memory` value is now honored directly instead of being silently capped by the internal memory budget. Appliances with less than 84 GB of RAM are unaffected. + - | + The size limit for `ghe-migrator` exports (80GB uncompressed, 40GB compressed) has been removed. If disk space is a concern, site administrators can configure a limit of their choice with the `ENTERPRISE_MIGRATIONS_MAX_EXPORT_ARCHIVE_SIZE_GB` environment variable. + - | + Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may time out on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps. + - | + {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %} + - | + When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`. + - | + When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded. + - | + When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + In a cluster, the host running restore requires access to the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + The setting to define private registries at the organization level for code scanning is only available if Dependabot is also enabled for the instance. + - | + An issue in the Management Console means the Backups (Preview) and Updates tabs may fail to open and instead return an Internal Server Error. We recommend using the command line interface (CLI) for backups and updates. + - | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. + - | + Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-19/7.yml b/data/release-notes/enterprise-server/3-19/7.yml index 8da320fe8756..949f9b6d1e01 100644 --- a/data/release-notes/enterprise-server/3-19/7.yml +++ b/data/release-notes/enterprise-server/3-19/7.yml @@ -9,6 +9,8 @@ sections: **HIGH**: An attacker with local access to the instance could escalate privileges to root by exploiting the Dirty Frag Linux kernel vulnerabilities in the IPsec ESP and RxRPC networking subsystems. GitHub has requested [CVE-2026-43284](https://ubuntu.com/security/CVE-2026-43284) and [CVE-2026-43500](https://ubuntu.com/security/CVE-2026-43500) for these vulnerabilities. - | **HIGH**: An attacker could extract sensitive environment variables from a GitHub Enterprise Server instance through a timing side-channel attack against the security advisories package lookup feature. On instances with GitHub Packages enabled, the package URL endpoint did not validate the supplied package name, enabling a Server-Side Request Forgery (SSRF) to internal services. This required no authentication when private mode was disabled, or any authenticated user otherwise. To mitigate this issue, GitHub removed the affected endpoint from GitHub Enterprise Server. GitHub has requested CVE ID [CVE-2026-8606](https://www.cve.org/cverecord?id=CVE-2026-8606) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + **MEDIUM**: An attacker could render a GitHub Enterprise Server instance unresponsive, causing a denial of service, by sending a crafted form-encoded HTTP POST request containing deeply nested parameters that forced excessive CPU consumption during parameter parsing and exhausted the request-handling worker pool. GitHub parsed parameters before routing and authentication, so an attacker could use any POST endpoint without an account or privileges. GitHub has requested CVE ID [CVE-2026-15996](https://www.cve.org/cverecord?id=CVE-2026-15996) for this vulnerability. - | Packages have been updated to the latest security versions. bugs: diff --git a/data/release-notes/enterprise-server/3-20/3.yml b/data/release-notes/enterprise-server/3-20/3.yml index 017d085b6fe4..b14fd04bb040 100644 --- a/data/release-notes/enterprise-server/3-20/3.yml +++ b/data/release-notes/enterprise-server/3-20/3.yml @@ -9,6 +9,8 @@ sections: **HIGH**: An attacker with local access to the instance could escalate privileges to root by exploiting the Dirty Frag Linux kernel vulnerabilities in the IPsec ESP and RxRPC networking subsystems. GitHub has requested [CVE-2026-43284](https://ubuntu.com/security/CVE-2026-43284) and [CVE-2026-43500](https://ubuntu.com/security/CVE-2026-43500) for these vulnerabilities. - | **HIGH**: An attacker could extract sensitive environment variables from a GitHub Enterprise Server instance through a timing side-channel attack against the security advisories package lookup feature. On instances with GitHub Packages enabled, the package URL endpoint did not validate the supplied package name, enabling a Server-Side Request Forgery (SSRF) to internal services. This required no authentication when private mode was disabled, or any authenticated user otherwise. To mitigate this issue, GitHub removed the affected endpoint from GitHub Enterprise Server. GitHub has requested CVE ID [CVE-2026-8606](https://www.cve.org/cverecord?id=CVE-2026-8606) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + **MEDIUM**: An attacker could render a GitHub Enterprise Server instance unresponsive, causing a denial of service, by sending a crafted form-encoded HTTP POST request containing deeply nested parameters that forced excessive CPU consumption during parameter parsing and exhausted the request-handling worker pool. GitHub parsed parameters before routing and authentication, so an attacker could use any POST endpoint without an account or privileges. GitHub has requested CVE ID [CVE-2026-15996](https://www.cve.org/cverecord?id=CVE-2026-15996) for this vulnerability. - | Packages have been updated to the latest security versions. bugs: diff --git a/data/release-notes/enterprise-server/3-20/6.yml b/data/release-notes/enterprise-server/3-20/6.yml new file mode 100644 index 000000000000..f7547c5e9865 --- /dev/null +++ b/data/release-notes/enterprise-server/3-20/6.yml @@ -0,0 +1,94 @@ +date: '2026-08-05' +sections: + security_fixes: + - | + **HIGH**: A path traversal vulnerability allowed an unauthenticated attacker to delete the user storage directory on the GitHub Enterprise Server instance, including Git LFS objects, release assets, attachments, and avatars, via the unsanitized X-GitHub-Request-Id request header. Exploitation required network access to the instance and worked when private mode was enabled. GitHub has requested CVE ID [CVE-2026-17556](https://www.cve.org/cverecord?id=CVE-2026-17556) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + Some internal, auto-generated secrets were not redacted when users compiled a support bundle. + bugs: + - | + On a {% data variables.product.prodname_ghe_server %} cluster upgrade, if all Consul server nodes restarted concurrently, the cluster could lose its Nomad leader and fail to recover, causing the upgrade to loop and fail rather than complete. + - | + On a {% data variables.product.prodname_ghe_server %} cluster with multiple nodes, requests to the container registry could fail with `503` errors if the container registry service was running on a different node than the one handling the request. + - | + `ghe-service-list` omitted unhealthy Nomad-backed services from its output on single-node and high-availability appliances. Stopped or failed services, such as `babeld` or `nginx`, appeared in neither the `active` nor `inactive` section. + - | + Administrators could not remove a node with `ghe-remove-node` when the provided hostname was a substring of another node hostname. + - | + On clustered instances, `ghe-remove-node` could incorrectly determine that a web or job node was the last `web-server` or `job-server` in the cluster. + - | + During hotpatching, custom `sshd_config` directives, such as directives added by cloud guest agents, were overwritten instead of being preserved as they were during feature upgrades. + - | + When administrators generated a support bundle with `ghe-support-bundle` while OpenTelemetry was enabled, a VictoriaMetrics export failure could produce a corrupt bundle because a log message was sent to `stdout` instead of `stderr`. + - | + Users experienced unnecessary reconnects or intermittent delivery delays in Kafka Lite-backed features when idle connections timed out too aggressively. GitHub Enterprise Server updated the idle connection timeout behavior to better preserve stable idle connections and reduce avoidable disruptions. + - | + For organizations that applied a security configuration to a large number of repositories at once, background job processing could be overwhelmed and leave some repositories stuck in the `attaching` state. + - | + On instances where a GitHub App listed the repositories for its installation through the REST API, response time and CPU usage on the appliance increased with the number of repositories the installation could access. For installations with access to many repositories, or on instances with large configuration sets, this could make these requests slow and contribute to sustained high CPU on the appliance. Repository configuration for these requests is loaded in a single batch instead of separately for each repository. + - | + Cached license information was not cleared until the instance was restarted. + - | + On instances with large organizations, listing organization members (for example, via the `membersWithRole` GraphQL API connection) could be slow and consume excessive CPU because a permission check was evaluated for each member instead of once per organization. + - | + Editing an existing repository ruleset on GitHub Enterprise Server could fail with an `Unexpected parameter automatic_copilot_code_review_enabled` error after upgrading. + - | + When a user deleted an organization that owned GitHub Apps, repositories owned by that organization were not deleted. + - | + Maintenance jobs did not correctly process very large repositories whose sizes exceeded the capacity of a 32-bit signed integer database column. + - | + Users saw unexpected entries on the enterprises **People** page: ProgrammaticAccessBot accounts appeared alongside human users. + - | + A repair of a standalone repository could fail with the error `not a standalone repository` if the repair detected changes only to the repository's wiki. + - | + When site administrators collected support bundles, secrets in Slack callback URLs were not sanitized. + - | + Users experienced stale or idle client connections that were not cleaned up promptly, which could lead to unnecessary resource usage over time. Idle client connections are now reaped more reliably to improve connection lifecycle management. + - | + On instances that use `actions-rate-limiting.queue-runs-per-minute`, queue run rate limiting could be calculated incorrectly. + changes: + - | + Improvements to authorization, migration APIs, and bug fixes supporting increased migration fidelity. + - | + On large GitHub Enterprise Server instances, kafka-lite and Redis memory limits scale with CPU count to reduce event-processing bottlenecks. Existing defaults are unchanged for smaller instances. + - | + MySQL memory allocation now auto-scales on large-memory appliances. Appliances with 84 GB or more of RAM receive proportionally larger InnoDB buffer pool caps (up to 512 GB), and an explicitly configured `ghe-config mysql.max-memory` value is now honored directly instead of being silently capped by the internal memory budget. Appliances with less than 84 GB of RAM are unaffected. + - | + The size limit for `ghe-migrator` exports (80GB uncompressed, 40GB compressed) has been removed. If disk space is a concern, site administrators can configure a limit of their choice with the `ENTERPRISE_MIGRATIONS_MAX_EXPORT_ARCHIVE_SIZE_GB` environment variable. + - | + Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may time out on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps. + - | + When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + In a cluster, the host running restore requires access to the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. + - | + On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: `ghe-config --unset 'app.actions.actions-repos-sha1sum'`, `ghe-config-apply`, and `/usr/local/share/enterprise/ghe-run-init-actions-graph`. + - | + Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-21/4.yml b/data/release-notes/enterprise-server/3-21/4.yml new file mode 100644 index 000000000000..3c6c1eec7970 --- /dev/null +++ b/data/release-notes/enterprise-server/3-21/4.yml @@ -0,0 +1,94 @@ +date: '2026-08-05' +sections: + security_fixes: + - | + **HIGH**: A path traversal vulnerability allowed an unauthenticated attacker to delete the user storage directory on the GitHub Enterprise Server instance, including Git LFS objects, release assets, attachments, and avatars, via the unsanitized X-GitHub-Request-Id request header. Exploitation required network access to the instance and worked when private mode was enabled. GitHub has requested CVE ID [CVE-2026-17556](https://www.cve.org/cverecord?id=CVE-2026-17556) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com/). + - | + Some internal, auto-generated secrets were not redacted when users compiled a support bundle. + bugs: + - | + On a {% data variables.product.prodname_ghe_server %} cluster upgrade, if all Consul server nodes restarted concurrently, the cluster could lose its Nomad leader and fail to recover, causing the upgrade to loop and fail rather than complete. + - | + On a {% data variables.product.prodname_ghe_server %} cluster with multiple nodes, requests to the container registry could fail with `503` errors if the container registry service was running on a different node than the one handling the request. + - | + `ghe-service-list` omitted unhealthy Nomad-backed services from its output on single-node and high-availability appliances. Stopped or failed services, such as `babeld` or `nginx`, appeared in neither the `active` nor `inactive` section. + - | + Administrators could not remove a node with `ghe-remove-node` when the provided hostname was a substring of another node hostname. + - | + On clustered instances, `ghe-remove-node` could incorrectly determine that a web or job node was the last `web-server` or `job-server` in the cluster. + - | + During hotpatching, custom `sshd_config` directives, such as directives added by cloud guest agents, were overwritten instead of being preserved as they were during feature upgrades. + - | + When administrators generated a support bundle with `ghe-support-bundle` while OpenTelemetry was enabled, a VictoriaMetrics export failure could produce a corrupt bundle because a log message was sent to `stdout` instead of `stderr`. + - | + Users experienced unnecessary reconnects or intermittent delivery delays in Kafka Lite-backed features when idle connections timed out too aggressively. GitHub Enterprise Server updated the idle connection timeout behavior to better preserve stable idle connections and reduce avoidable disruptions. + - | + Repository administrators and users subscribed to secret scanning alerts did not receive email notifications summarizing newly detected secrets. + - | + When users changed the visibility of a repository, they sometimes received a 500 error. + - | + On instances where a GitHub App listed the repositories for its installation through the REST API, response time and CPU usage on the appliance increased with the number of repositories the installation could access. For installations with access to many repositories, or on instances with large configuration sets, this could make these requests slow and contribute to sustained high CPU on the appliance. Repository configuration for these requests is loaded in a single batch instead of separately for each repository. + - | + Cached license information was not cleared until the instance was restarted. + - | + On instances with large organizations, listing organization members (for example, via the `membersWithRole` GraphQL API connection) could be slow and consume excessive CPU because a permission check was evaluated for each member instead of once per organization. + - | + Editing an existing repository ruleset on GitHub Enterprise Server could fail with an `Unexpected parameter automatic_copilot_code_review_enabled` error after upgrading. + - | + When a user deleted an organization that owned GitHub Apps, repositories owned by that organization were not deleted. + - | + Users saw unexpected entries on the enterprises **People** page: ProgrammaticAccessBot accounts appeared alongside human users. + - | + Maintenance jobs did not correctly process very large repositories whose sizes exceeded the capacity of a 32-bit signed integer database column. + - | + A repair of a standalone repository could fail with the error `not a standalone repository` if the repair detected changes only to the repository's wiki. + - | + When site administrators collected support bundles, secrets in Slack callback URLs were not sanitized. + - | + Users experienced stale or idle client connections that were not cleaned up promptly, which could lead to unnecessary resource usage over time. Idle client connections are now reaped more reliably to improve connection lifecycle management. + - | + On instances that use `actions-rate-limiting.queue-runs-per-minute`, queue run rate limiting could be calculated incorrectly. + changes: + - | + Improvements to authorization, migration APIs, and bug fixes supporting increased migration fidelity. + - | + On large GitHub Enterprise Server instances, kafka-lite and Redis memory limits scale with CPU count to reduce event-processing bottlenecks. Existing defaults are unchanged for smaller instances. + - | + MySQL memory allocation now auto-scales on large-memory appliances. Appliances with 84 GB or more of RAM receive proportionally larger InnoDB buffer pool caps (up to 512 GB), and an explicitly configured `ghe-config mysql.max-memory` value is now honored directly instead of being silently capped by the internal memory budget. Appliances with less than 84 GB of RAM are unaffected. + - | + The size limit for `ghe-migrator` exports (80GB uncompressed, 40GB compressed) has been removed. If disk space is a concern, site administrators can configure a limit of their choice with the `ENTERPRISE_MIGRATIONS_MAX_EXPORT_ARCHIVE_SIZE_GB` environment variable. + - | + Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may time out on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps. + - | + When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + In a cluster, the host running restore requires access to the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. + - | + On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: `ghe-config --unset 'app.actions.actions-repos-sha1sum'`, `ghe-config-apply`, and `/usr/local/share/enterprise/ghe-run-init-actions-graph`. diff --git a/data/tables/copilot/model-deprecation-history.yml b/data/tables/copilot/model-deprecation-history.yml index a1967a15c88c..63ef00286ae6 100644 --- a/data/tables/copilot/model-deprecation-history.yml +++ b/data/tables/copilot/model-deprecation-history.yml @@ -11,6 +11,30 @@ # - retirement_date: The official retirement date for the model (YYYY-MM-DD). # - suggested_alternative: The model recommended for migration. +- name: 'Claude Opus 4.5' + retirement_date: '2026-09-01' + suggested_alternative: 'Claude Opus 5' + +- name: 'Claude Opus 4.6' + retirement_date: '2026-09-01' + suggested_alternative: 'Claude Opus 5' + +- name: 'Claude Sonnet 4.5' + retirement_date: '2026-09-01' + suggested_alternative: 'Claude Sonnet 5' + +- name: 'Claude Sonnet 4.6' + retirement_date: '2026-09-01' + suggested_alternative: 'Claude Sonnet 5' + +- name: 'Gemini 3.1 Pro' + retirement_date: '2026-09-01' + suggested_alternative: 'Gemini 3.6 Flash' + +- name: 'Raptor mini' + retirement_date: '2026-09-01' + suggested_alternative: 'MAI-Code-1-Flash' + - name: 'Gemini 2.5 Pro' retirement_date: '2026-07-31' suggested_alternative: 'Gemini 3.1 Pro'