GitHub Enterprise Server has Critical SSRF that Exposes Internal Credentials (CVE-2026-9312)

GitHub has fixed a critical server-side request forgery vulnerability in GitHub Enterprise Server, the self-hosted edition that banks, fintechs, and public agencies run within their own data centres to keep control of the code. Catalogued as CVE-2026-9312 and disclosed by GitHub itself on 27 May, the vulnerability received a score of 9.2 on CVSS 4.0 and allows an unauthenticated attacker to force the server to issue requests against internal services, with the potential to expose credentials.

How the vulnerability works

The entry point is an upload endpoint that poorly validates received data. By injecting path traversal sequences into the request parameters, the attacker disrupts the expected flow and redirects internal API calls to destinations under their control, a classic SSRF pattern recorded as CWE-918. From there, according to the record published by GitHub, it is possible to reach internal services and expose sensitive credentials.

The CVSS vector tells the rest. The vulnerability does not require privileges (PR:N) or user interaction (UI:N), making it reachable from the edge of the network, but specific conditions in the environment are required: the string indicates high complexity (AC:H) and present attack requirements (AT:P). When these conditions are met, the impact on confidentiality, integrity, and availability of the system is high across all three axes (VC:H/VI:H/VA:H). It is the sum of unauthorised access combined with total impact that sustains the score of 9.2.

SSRF vulnerabilities are a recurring plague for internet-exposed enterprise applications because they turn the server into an intermediary for the attacker: anyone communicating with the external system also indirectly communicates with everything the system can see internally. In a product that orchestrates source code, this "internal view" includes precisely what no one wants to be leaked.

Which versions need a patch

Four release lines are affected: from 3.16.0 to 3.16.19, from 3.17.0 to 3.17.16, from 3.18.0 to 3.18.10, and from 3.19.0 to 3.19.7. The fixes were released in versions 3.16.20, 3.17.17, 3.18.11, and 3.19.8, listed in the platform’s administration release notes. Installations on any earlier builds within these ranges remain exposed.

Here is the operational detail that separates GitHub Enterprise Server from the public GitHub cloud: the update is the customer’s responsibility. There is no silent patch applied by the vendor overnight. The remediation clock starts ticking for each company's infrastructure team, and every day of delay is an additional day of exposure.

What this means for Brazil

The Brazilian reading involves where GHES is typically installed. Companies that cannot or do not wish to hand over the repository to GitHub’s cloud, such as banks, insurance companies, government integrators, and IT consultancies that safeguard clients' regulated code, maintain the self-hosted version to keep the repository within the perimeter and comply with data residency requirements under the LGPD and the regulations of the Central Bank. The side effect is that many of these instances are accessible via the internet to facilitate remote work and integration with delivery pipelines.

An unauthenticated SSRF in this context carries more weight than average. GitHub Enterprise Server is closely linked to CI/CD secrets, build runners, and internal artifact registries. A credential leaked in this manner does not just open one repository: it opens the pipeline that compiles and packages the software destined for production. For a consultancy hosting the code of dozens of clients on the same instance, the impact radius calculation is immediate, and the incident of one becomes an incident for all.

The practical recommendation does not depend on whether there has been observed exploitation. Pre-authentication vulnerabilities accessible via the network automatically go to the top of the queue by definition, and the window between the publication of the advisory and the mass scanning of exposed servers is typically measured in days. Those operating GHES aimed at the internet should treat the upgrade to the patched build as a priority task for the week and, in parallel, review which service tokens have been within reach of the vulnerable endpoint. Patching closes the door; credential rotation answers the question that the patch cannot, that of who has already passed through it.