<Vulnerability name="CVE-2026-10101">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Moderate</ThreatSeverity>
    <PublicDate>2026-05-29T12:00:00</PublicDate>
    <Bugzilla id="2483298" url="https://bugzilla.redhat.com/show_bug.cgi?id=2483298" xml:lang="en:us">
assisted-service: assisted-service: InfraEnv status leaks referenced pull-secret contents to namespace view users
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>6.3</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:L/A:N</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-201</CWE>
    <Details xml:lang="en:us" source="Red Hat">
ACM/MCE assisted-service writes raw referenced pull-secret contents into `InfraEnv.status.conditions[].message` when pull-secret validation fails. A namespace principal with the stock `view` ClusterRole cannot directly read Secrets, but can read `InfraEnv` objects and recover the referenced Secret's `.dockerconfigjson` data from status.

This bypasses the Kubernetes/OpenShift RBAC separation between read-only namespace viewers and Secret readers. In the reproduced proof, the same ServiceAccount was denied `get` and `list` on Secrets, but recovered synthetic pull-secret `username`, `password`, `email`, and base64 `auth` fields through `InfraEnv.status`.
    </Details>
    <Statement xml:lang="en:us">
Red Hat rates this flaw as Moderate impact. Exploitation requires a namespace "view" user to be in a namespace where an InfraEnv references a pull secret that fails assisted-service validation -- a condition the "view" user cannot trigger themselves. Red Hat scores UI:R (User Interaction Required) because the leak only exists when an administrator creates or updates an InfraEnv referencing a pull secret that fails validation; without that admin action, there is nothing to exploit. The direct impact is confidentiality: the full pull-secret content is disclosed through InfraEnv status, bypassing the Kubernetes RBAC boundary that prevents "view" users from reading Secrets. Red Hat scores I:L (Integrity: Low) rather than I:H because, with Scope: Unchanged, integrity impact should reflect the vulnerable component (MCE/ACM), not external registries. The leaked credential's write capability is conditional on the specific credential's permissions and does not represent integrity compromise of the ACM/MCE cluster itself.
    </Statement>
    <PackageState cpe="cpe:/a:redhat:multicluster_engine">
        <ProductName>Multicluster Engine for Kubernetes</ProductName>
        <FixState>Under investigation</FixState>
        <PackageName>multicluster-engine/assisted-service-9-rhel9</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-10101
https://nvd.nist.gov/vuln/detail/CVE-2026-10101
    </References>
</Vulnerability>