CVE-2024-0200

What it actually does

CVE-2024-0200 is an unsafe reflection flaw in GitHub Enterprise Server that can allow a logged-in user with organization owner privileges to invoke user-controlled methods. If successfully exploited, the vulnerability can lead to remote code execution on the GitHub Enterprise Server appliance, giving the attacker the ability to execute commands or code in the context of the vulnerable application/service. Because GitHub Enterprise Server stores source code, CI/CD metadata, secrets-adjacent configuration, issues, pull requests, and user identity data, successful exploitation can affect confidentiality, integrity, and availability at a high level.

Why it matters to the business

A successful attack can compromise a self-hosted source code management platform, potentially exposing proprietary source code, enabling tampering with repositories or release workflows, disrupting developer operations, and creating a path to broader software supply-chain compromise. The risk is elevated because public exploit maturity is reported as weaponized and EPSS is high, indicating meaningful likelihood of exploitation activity, even though the vulnerability is not currently listed in CISA KEV and is not specifically associated with ransomware campaigns. Organizations running unsupported or unpatched GitHub Enterprise Server versions prior to the fixed releases should treat remediation as urgent, especially where many internal teams, repositories, or downstream build/release processes depend on the instance.

How an attack unfolds

An attacker first needs access to a valid account on the GitHub Enterprise Server instance and must hold the organization owner role for at least one organization. From that position, the attacker interacts with vulnerable functionality that performs unsafe reflection using attacker-controlled input. By crafting input that causes unintended method invocation, the attacker can move from reflection injection to execution of attacker-selected methods and ultimately remote code execution on the appliance. After code execution, the attacker may attempt to read repositories, harvest credentials or tokens available to the application, modify code or workflow configuration, create persistence through accounts, SSH keys, OAuth applications, or hooks, and erase or reduce evidence in application and system logs.

How to fix it

Upgrade GitHub Enterprise Server to a fixed version immediately. The vulnerability affects all GitHub Enterprise Server versions prior to 3.12 and was fixed in 3.8.13, 3.9.8, 3.10.5, and 3.11.3; version 3.12 and later are not affected according to the advisory. If immediate upgrade is not possible, reduce exposure by restricting network access to the GHES appliance, requiring VPN or trusted administrative networks, enforcing SSO and MFA, reviewing and minimizing organization owner membership, disabling or removing dormant privileged accounts, and monitoring privileged account activity closely. Because exploitation requires organization owner privileges, privilege hygiene is an important compensating control, but it should not be treated as a substitute for patching.

How to confirm the fix worked

Confirm the running GitHub Enterprise Server version from the appliance management console or administrative CLI and verify it is 3.8.13, 3.9.8, 3.10.5, 3.11.3, 3.12, or later. Validate that no GHES instance remains on 3.8.12 or earlier in the 3.8 line, 3.9.7 or earlier in the 3.9 line, 3.10.4 or earlier in the 3.10 line, 3.11.2 or earlier in the 3.11 line, or any older unsupported version. Review organization owner membership and confirm all owner accounts are expected, active, MFA-protected, and tied to authorized personnel. After upgrade, perform a functional smoke test of repository access, authentication, hooks, integrations, and CI/CD integrations. If exposure is uncertain, run authenticated version checks and review upgrade logs to confirm the patched package was applied successfully.

Typical attack path

1. Obtain valid GitHub Enterprise Server credentials through phishing, credential reuse, token theft, insider access, or prior compromise.
2. Ensure the compromised account has organization owner privileges or escalate to an organization owner role through social engineering or abuse of existing permissions.
3. Send crafted requests to vulnerable GitHub Enterprise Server functionality that uses unsafe reflection with user-controlled input.
4. Trigger unintended method execution and achieve remote code execution on the GHES appliance.
5. Execute reconnaissance commands to identify repositories, users, tokens, hooks, workflows, integrations, and appliance configuration.
6. Exfiltrate source code, secrets-adjacent configuration, package metadata, or CI/CD material, or modify repositories and workflow definitions.
7. Establish persistence by adding users, SSH keys, deploy keys, OAuth apps, webhooks, GitHub Apps, or other durable access paths.
8. Attempt to cover tracks by deleting or altering audit-relevant activity, rotating through accounts, or blending activity with legitimate administrative operations.

How to detect it

To determine whether exploitation already occurred, focus on privileged account activity and appliance-level execution artifacts. Review GitHub Enterprise Server audit logs for organization owner actions immediately before unusual repository, hook, integration, workflow, token, or user changes. Correlate GHES audit logs with authentication logs, SSO identity provider logs, reverse proxy/WAF logs, SSH logs, and appliance syslog for suspicious requests made by organization owner accounts, especially from unusual IP addresses, geographies, user agents, or time windows. Look for newly created users, owner role grants, SSH keys, deploy keys, OAuth applications, GitHub Apps, personal access tokens, webhooks, branch protection changes, Actions/workflow changes, and unexpected repository transfers or downloads. On the appliance, inspect system logs for unexpected child processes spawned by application services, shell execution, outbound network connections, archive creation, credential access, persistence mechanisms, cron jobs, modified startup scripts, and attempts to clear logs. If exploitation is suspected, preserve logs and disk evidence before remediation, rotate secrets, and compare repository and workflow state against known-good baselines.

• github-enterprise.log
• audit.log
• /var/log/syslog
• /var/log/auth.log
• /var/log/nginx/
• /var/log/github/
• /var/log/gitauth.log
• /var/log/enterprise-manage/
• /data/user/common/
• /data/github/current/
• /etc/cron.d/
• /var/spool/cron/
• /tmp/
• /var/tmp/
• org.add_member
• org.update_member
• org.remove_member
• org.add_owner
• org.update_member_repository_creation_permission
• org.update_default_repository_permission
• repo.create
• repo.destroy
• repo.transfer
• repo.add_member
• repo.add_deploy_key
• repo.add_webhook
• repo.update_webhook
• repo.remove_webhook
• oauth_application.create
• oauth_application.update
• integration_installation.create
• integration_installation_repositories.add
• user.add_ssh_key
• user.create_personal_access_token
• protected_branch.destroy
• protected_branch.update
• workflow_run
• curl
• wget
• bash -c
• sh -c
• python -c
• python3 -c
• perl -e
• ruby -e
• nc
• ncat
• socat
• /bin/bash
• /bin/sh

What your security team should do

• Prioritize patching all GitHub Enterprise Server instances to 3.8.13, 3.9.8, 3.10.5, 3.11.3, 3.12, or later, with urgency due to weaponized exploit maturity and high EPSS.
• Immediately inventory all GHES appliances, including non-production, disaster recovery, development, and isolated instances, and identify any versions prior to the fixed releases.
• Review all organization owner accounts for legitimacy, recent changes, dormant accounts, missing MFA, unusual SSO status, newly added SSH keys, OAuth authorizations, deploy keys, and GitHub Apps.
• Restrict access to GHES administrative and application interfaces to trusted networks where operationally feasible until patching and review are complete.
• Search audit, application, authentication, proxy, and system logs for unusual organization owner activity, unexpected administrative changes, anomalous requests, and signs of command execution on the appliance.
• Rotate credentials, personal access tokens, deploy keys, webhook secrets, GitHub App private keys, and CI/CD secrets if exploitation is suspected or privileged account compromise is found.
• Review repositories and workflows for unauthorized commits, branch protection changes, altered release pipelines, new webhooks, suspicious Actions/workflow changes, and malicious package publishing activity.
• Preserve forensic evidence before rebuilding or reimaging any suspected compromised appliance, including audit logs, application logs, syslog, shell history, process listings, scheduled jobs, and relevant appliance snapshots.