OpenShift’s Translation Endpoint Can Read Files Without a Login
A translation request should return language resources. In the OpenShift console, two unsanitised query parameters can instead let an unauthenticated remote attacker reach JSON files outside the intended directory.
Red Hat’s official record rates CVE-2026-75887 Important, with a CVSS 3.1 score of 7.5. The affected /locales/resource.json endpoint is available without authentication. By manipulating its lng and ns parameters, an attacker can read *.json files available to the console pod, including plugin manifests and configuration files. The same input path can reach registered dynamic-plugin backends.
This is missed coverage of a 23 September disclosure, not a newly discovered issue today. Red Hat’s CSAF record was initially released at 20:57:32 UTC that day and last generated at 22:00 UTC. As of the 28 September review, it lists the OpenShift Container Platform 4 console packages as affected, supplies no fixed product state and says no mitigation meeting Red Hat’s ease, applicability and stability criteria is available.
CISA’s enrichment of the CVE record recorded no exploitation as of 24 September at 14:52:14 UTC. No credible public proof of concept or confirmed in-the-wild use was identified in the sources reviewed through 28 September. That is a statement about available evidence, not a guarantee that the path is unknown to attackers.
The locale handler trusts paths it should contain
Red Hat’s bug record explains the trust failure. The locale endpoint is registered without an authentication handler. Its language and namespace values come directly from the request without sanitisation.
For ordinary namespaces, the handler combines those values with the console’s public locale directory and passes the resulting filename to Go’s file-serving code. Normalising a path removes redundant elements, but it does not by itself prove that the final file remains underneath the intended directory. The usual path-traversal guard inspects the request URL, while this vulnerable path is constructed separately for the file argument.
The result is an unauthenticated read primitive limited to JSON files the console pod can access. The vendor specifically names ConfigMap-mounted plugin manifests and configuration files as examples. That does not mean every secret in a cluster becomes readable. It does mean defenders must examine what JSON material their console image, mounts and plugins actually expose rather than treating the base score as the full impact assessment.
A second branch of the handler deals with namespaces prefixed for plugins. There, the unsanitised language value can be inserted into a request path sent to registered dynamic-plugin services. Each installed plugin can therefore add another backend and another boundary that needs inspection.
Red Hat lists OpenShift 4 as affected but no fixed release
The current Red Hat security data names these affected components:
| Product | Affected component | Fixed version in the reviewed record |
|---|---|---|
| Red Hat OpenShift Container Platform 4 | openshift4/ose-console | None listed |
| Red Hat OpenShift Container Platform 4 | openshift4/ose-console-rhel9 | None listed |
Red Hat’s CVSS vector is network-accessible, low complexity, no privileges required and no user interaction. The assessed impact is high for confidentiality, with no direct integrity or availability impact. That distinction matters. The flaw reads data; the reviewed primary sources do not say it writes files, runs code or takes over a cluster.
The Bugzilla description says the issue was reproduced on an OpenShift 5.0 nightly cluster. That test result does not narrow Red Hat’s formal affected-product statement, which currently lists the OpenShift Container Platform 4 console components. Defenders should follow the official product status rather than infer safety from the reproduction environment.
This issue is also separate from the OpenShift oc-mirror signature-bypass problem BlackTree covered on 23 September. That earlier article concerns the integrity of mirrored content. The present flaw concerns unauthenticated file disclosure through the web console and plugin routing.
Inventory the reachable console before choosing a temporary control
Because the reviewed Red Hat record gives no fixed build or supported mitigation, the immediate task is exposure and evidence management.
Start by identifying every OpenShift 4 console endpoint, including environments reachable only through a VPN, bastion or private ingress. Record the console image digest, deployment revision, mounted ConfigMaps and registered dynamic plugins. A version label alone may not capture a rebuilt or vendor-customised image.
Review ingress, proxy and console access logs for requests to /locales/resource.json. Look for unusual values in lng or ns, repeated requests for unrelated namespaces, encoded path separators or traversal markers, and requests that line up with access to plugin backends. Preserve the raw request, timestamp, source address, forwarded headers and the console pod instance that handled it. Avoid reducing the review to one literal exploit string because equivalent encodings may differ.
Inspect which JSON files are present in the console pod and which are mounted at runtime. This is not an instruction to copy sensitive content into an incident ticket. Record paths, ownership and sensitivity through the organisation’s evidence process, then determine whether the exposed material contains service locations, plugin configuration, credentials or other information that changes the incident’s scope.
Compensating controls need testing and an expiry date
Red Hat does not provide a mitigation that meets its product-security criteria. Organisations may still consider temporary network or ingress restrictions based on their own architecture, but those are BlackTree operational suggestions, not a vendor-certified fix.
Restricting console access to trusted administrative networks can reduce the population able to reach the endpoint. A proxy rule that blocks suspicious traversal syntax or limits access to the locale path may add protection, but an overly broad rule can break localisation or plugin behaviour. Test any control on a representative cluster, confirm that alternative ingress routes cannot bypass it, and preserve the original request data needed for investigation.
Do not remove dynamic plugins solely because their presence expands the review boundary. First determine whether each plugin is registered, reachable and business-critical. If a plugin backend must be disabled, use the supported change process and retain the configuration required to restore it safely.
Monitor Red Hat’s CSAF record and product errata for a fixed console image. When a fix appears, validate the exact OpenShift release and image digest, deploy it through the normal cluster change path, then retest the endpoint and temporary ingress controls. Remove compensating rules only after the patched console is confirmed across every cluster.
The dangerous assumption here is that a public translation endpoint can only return harmless language strings. Until Red Hat publishes a fixed product state, defenders should treat the console’s JSON boundary as part of the attack surface and establish exactly what an unauthenticated request could have reached.
Sources
- Red Hat CSAF security data record, initially released 23 September 2026 at 20:57:32.813 UTC; current record generated at 22:00 UTC.
- Red Hat Bugzilla 2517889, technical path description and reproduction context.
- CVE.org record and CISA enrichment, including an SSVC assessment dated 24 September 2026 at 14:52:14.603303 UTC.
- BlackTree CVE record for CVE-2026-75887, exact destination verified 28 September 2026.
