1. CVE-2026-10840 (OpenShift Pipelines / Tekton) — El fallo está en el tekton-scheduler-rolebinding, que otorga al grupo system:authenticated acceso de escritura a recursos de Kueue y cert-manager. Este defecto vive en cómo el operador productizado de Red Hat configura el RBAC. En OKD normalmente instalarías el operador Tekton/Pipelines de la comunidad, no el openshift-pipelines-operator-rh. Si tu OKD usa el operador upstream con manifiestos distintos, podrías no tener exactamente ese ClusterRoleBinding
Verificacion
oc get clusterrolebinding tekton-scheduler-rolebinding -o yaml- Sin resultado
Pipelines (CVE-2026-10840) — descartado ✅
El tekton-scheduler-rolebinding no existe en tu clúster. Ese ClusterRoleBinding es precisamente el origen del fallo crítico (9.6), así que ese vector específico no te aplica. Tu OKD no tiene el RBAC defectuoso del operador productizado de Red Hat.
CVE-2026-10843
2. CVE-2026-10843 (Cloud Credential Operator en modo Mint sobre AWS) — Aquí hay que tener más cuidado. El Cloud Credential Operator es literalmente el mismo repositorio openshift/cloud-credential-operator que usan tanto OpenShift como OKD, y el modo Mint existe igual en OKD: la documentación de OKD 4 confirma que el CCO puede operar en modo Mint, Passthrough o Manual. Si el defecto está en el código core del CCO, un clúster OKD corriendo CCO en modo Mint sobre AWS sí podría estar expuesto al mismo fallo subyacente, aunque el CVE no lo nombre. OKD Documentation
Verificacion
oc get cloudcredentials cluster -o=jsonpath={.spec.credentialsMode}
oc get secret aws-creds -n kube-system -o jsonpath --template '{ .metadata.annotations }'CCO modo Mint (CVE-2026-10843) — descartado ✅
El secret aws-creds en kube-system no e
xiste (NotFound). Ese secret es donde el CCO guarda las credenciales root de AWS cuando opera en modo Mint o Passthrough. Su ausencia indica que tu clúster no está usando el modo Mint — lo más probable es que esté en modo Manual/STS (con AWS IAM Roles for Service Accounts, donde no se almacenan llaves de larga duración), que es justamente el modo que queda fuera del escenario de este CVE.
CVE-2026-1784
CVE-2026-1784 — este sí es relevante para OKD ⚠️
A diferencia de los anteriores, este no vive en un operador opcional ni en un modo de credenciales que puedas no estar usando. Está en el router/ingress controller, que es un componente core que OKD comparte directamente con OpenShift.
El detalle del fallo: la vulnerabilidad surge del recurso Route de OpenShift, que facilita el acceso a los pods vía HAProxy en un subdominio, y las verificaciones insuficientes sobre spec.path en los documentos Route permiten a un atacante inyectar configuraciones maliciosas, lo que deriva en ejecución remota de código. Tiene una puntuación CVSS de 8.8, clasificada como severidad alta. BitNinjaBitNinja
Por qué importa para OKD: el código afectado está en el repositorio openshift/router, que contiene el router HAProxy de referencia. Y ese repositorio es explícito en que estas imágenes son gestionadas por el cluster-ingress-operator en clústeres OpenShift 4.0+, y el router de OpenShift puede ejecutarse incluso contra un clúster Kubernetes vanilla. En otras palabras: OKD usa el mismo router HAProxy y el mismo recurso Route que OpenShift, construidos desde el mismo código fuente upstream. Esto no es empaquetado exclusivo de Red Hat como los CVE anteriores — es infraestructura compartida que tu OKD casi con seguridad tiene desplegada por defecto. GitHub
Cómo verificarlo en tu clúster
A diferencia de los otros dos, aquí no hay un «no existe el recurso» que te saque del problema, porque el router sí existe. Lo que tenés que mirar es versión y superficie de exposición:
# 1. Versión de OKD (para cruzar con el fix upstream)
oc get clusterversion
# 2. Imagen del router que estás corriendo
oc -n openshift-ingress get deployment router-default \
-o jsonpath='{.spec.template.spec.containers[0].image}'; echo
# 3. Pods del ingress
oc -n openshift-ingress get podsY lo más importante desde el punto de vista de riesgo real — quién puede crear o modificar objetos Route, ya que el ataque requiere inyectar vía spec.path:
- Resultados
cgi@okd-provisioner-nodo01:~$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.21.0-okd-scos.ec.13 True False 188d Cluster version is 4.21.0-okd-scos.ec.13
cgi@okd-provisioner-nodo01:~$ oc -n openshift-ingress get deployment router-default \
-o jsonpath='{.spec.template.spec.containers[0].image}'; echo
quay.io/okd/scos-content@sha256:15f7c73f9dc18306517efbe262185db61897fe61677d8e3d20b9944217d6c915
cgi@okd-provisioner-nodo01:~$ oc -n openshift-ingress get pods
NAME READY STATUS RESTARTS AGE
router-default-57f846f57c-5l2p5 1/1 Running 0 32d
router-default-57f846f57c-b2bcf 1/1 Running 0 68d
router-default-57f846f57c-lb9bl 1/1 Running 0 56d
cgi@okd-provisioner-nodo01:~$ oc adm policy who-can create routes --all-namespaces
resourceaccessreviewresponse.authorization.openshift.io/<unknown>
Namespace: <all>
Verb: create
Resource: routes.route.openshift.io
Users: system:admin
system:serviceaccount:kubevirt-hyperconverged:cdi-operator
system:serviceaccount:kubevirt-hyperconverged:hyperconverged-cluster-operator
system:serviceaccount:kubevirt-hyperconverged:kubevirt-operator
system:serviceaccount:openshift-apiserver-operator:openshift-apiserver-operator
system:serviceaccount:openshift-apiserver:openshift-apiserver-sa
system:serviceaccount:openshift-authentication-operator:authentication-operator
system:serviceaccount:openshift-authentication:oauth-openshift
system:serviceaccount:openshift-cluster-storage-operator:cluster-storage-operator
system:serviceaccount:openshift-cluster-version:default
system:serviceaccount:openshift-config-operator:openshift-config-operator
system:serviceaccount:openshift-controller-manager-operator:openshift-controller-manager-operator
system:serviceaccount:openshift-etcd-operator:etcd-operator
system:serviceaccount:openshift-etcd:installer-sa
system:serviceaccount:openshift-image-registry:cluster-image-registry-operator
system:serviceaccount:openshift-infra:ingress-to-route-controller
system:serviceaccount:openshift-infra:template-instance-controller
system:serviceaccount:openshift-infra:template-instance-finalizer-controller
system:serviceaccount:openshift-ingress-operator:ingress-operator
system:serviceaccount:openshift-kube-apiserver-operator:kube-apiserver-operator
system:serviceaccount:openshift-kube-apiserver:installer-sa
system:serviceaccount:openshift-kube-apiserver:localhost-recovery-client
system:serviceaccount:openshift-kube-controller-manager-operator:kube-controller-manager-operator
system:serviceaccount:openshift-kube-controller-manager:installer-sa
system:serviceaccount:openshift-kube-controller-manager:localhost-recovery-client
system:serviceaccount:openshift-kube-scheduler-operator:openshift-kube-scheduler-operator
system:serviceaccount:openshift-kube-scheduler:installer-sa
system:serviceaccount:openshift-kube-scheduler:localhost-recovery-client
system:serviceaccount:openshift-kube-storage-version-migrator-operator:kube-storage-version-migrator-operator
system:serviceaccount:openshift-kube-storage-version-migrator:kube-storage-version-migrator-sa
system:serviceaccount:openshift-machine-config-operator:machine-config-operator
system:serviceaccount:openshift-network-operator:cluster-network-operator
system:serviceaccount:openshift-oauth-apiserver:oauth-apiserver-sa
system:serviceaccount:openshift-operator-lifecycle-manager:olm-operator-serviceaccount
system:serviceaccount:openshift-operators:argocd-operator-controller-manager
system:serviceaccount:openshift-service-ca-operator:service-ca-operator
system:serviceaccount:prueba-vale:argocd-argocd-application-controller
Groups: system:cluster-admins
system:masters
cgi@okd-provisioner-nodo01:~$ oc get clusterrolebindings -o json | \
grep -i route
"name": "openshift-ingress-router",
"name": "openshift-ingress-router"
"name": "router",
"name": "router-monitoring",
"name": "router-monitoring"
"name": "system:controller:route-controller",
"name": "system:controller:route-controller"
"name": "route-controller",
"name": "system:openshift:openshift-controller-manager:ingress-to-route-controller",
"name": "system:openshift:openshift-controller-manager:ingress-to-route-controller"
"name": "ingress-to-route-controller",
"name": "system:openshift:openshift-route-controller-manager",
"name": "system:openshift:openshift-route-controller-manager"
"name": "route-controller-manager-sa",
"namespace": "openshift-route-controller-manager"
"name": "system:openshift:tokenreview-openshift-route-controller-manager",
"name": "system:openshift:tokenreview-openshift-route-controller-manager"
"name": "route-controller-manager-sa",
"namespace": "openshift-route-controller-manager"
Análisis de versión: muy probablemente vulnerable
Tu clúster corre 4.21.0-okd-scos.ec.13. El ec.13 indica un engineering candidate (build de desarrollo / pre-release), y lo más importante: el clusterversion muestra SINCE 188d — llevás 188 días en esa misma versión. Además, los pods del router tienen entre 32 y 68 días sin reiniciarse, lo que confirma que no han recibido una imagen nueva recientemente.
El problema: el fix de CVE-2026-1784 es de hace pocos días. En el ecosistema OpenShift apareció en z-streams muy recientes — por ejemplo, OpenShift Container Platform 4.19.33 incluye una actualización de seguridad que aborda CVE-2026-1784 junto con otros CVE, y se recomienda a los usuarios de 4.19 actualizar a esta versión, y ese aviso es de hace apenas unos días. Un build de OKD de hace ~188 días (aproximadamente diciembre 2025) casi con certeza precede al parche. OffSeq Threat Radar
Conclusión sobre versión: tu router HAProxy está corriendo código anterior al fix. Este vector está, con alta probabilidad, presente en tu clúster.
Análisis de superficie de ataque: acá está la buena noticia
Quién puede crear Routes a nivel de clúster está acotado a componentes de sistema confiables: system:admin, los grupos system:cluster-admins y system:masters, y un montón de serviceaccount de operadores (kubevirt, apiserver, authentication, etc.). No aparece system:authenticated ni un rol genérico que dé a cualquier usuario autenticado la capacidad de crear Routes en todo el clúster. Eso reduce mucho el riesgo práctico.
Pero hay dos matices que sí debés revisar:
- ArgoCD / GitOps. Veo dos service accounts de Argo con permiso de crear Routes:
- system:serviceaccount:openshift-operators:argocd-operator-controller-manager
- system:serviceaccount:prueba-vale:argocd-argocd-application-controller
Esto es un vector real: si por esos ArgoCD pasan manifiestos desde repositorios Git que no controlás del todo, un Route con un spec.path malicioso podría llegar al router. El riesgo depende de quién puede hacer commit a los repos que Argo sincroniza. El namespace prueba-vale («prueba») sugiere que ahí hay actividad de testing — vale la pena auditar qué despliega ese Argo.
- Permisos a nivel de proyecto (no visibles aquí). El comando who-can –all-namespaces muestra principalmente bindings a nivel de clúster. En OpenShift/OKD, los roles admin y edit de proyecto incluyen crear Routes, pero esos permisos namespace-scoped no siempre aparecen en esta consulta. Si das proyectos con edit/admin a usuarios poco confiables, ellos podrían crear Routes en sus propios namespaces y no los verías en esta lista. Para confirmarlo:
# Revisá RoleBindings namespace-scoped que otorguen edit/admin a usuarios reales
oc get rolebindings --all-namespaces -o json | \
grep -iE '"name": "(admin|edit)"' -A5
# Y mirá si hay usuarios/grupos no-sistema con esos roles
oc get rolebindings --all-namespaces \
-o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ROLE:.roleRef.name | \
grep -iE 'admin|edit'- Resultados
cgi@okd-provisioner-nodo01:~$ oc get rolebindings --all-namespaces -o json | \
grep -iE '"name": "(admin|edit)"' -A5
"name": "admin",
"namespace": "allam",
"resourceVersion": "10592571",
"uid": "68cda6f2-e5da-4330-a5a5-86d765248790"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "allam2",
"resourceVersion": "10595191",
"uid": "b3553937-e5be-457f-9ce1-9a931ba241ff"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "cluster-maintenance",
"resourceVersion": "109616193",
"uid": "e2758bdc-559a-42c5-8156-e31ff5148a99"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "edit",
"namespace": "cluster-maintenance",
"resourceVersion": "109697790",
"uid": "7bc98324-edc1-4253-808c-1c46d20adea9"
},
"roleRef": {
--
"name": "edit"
},
"subjects": [
{
"kind": "ServiceAccount",
"name": "image-pruner",
--
"name": "admin",
"namespace": "correo",
"resourceVersion": "97625335",
"uid": "8f5ceb2c-4c4a-49fa-aa50-c2217423c29d"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "desarrollo-vm",
"resourceVersion": "6356644",
"uid": "ed686463-e291-46a7-819b-98bd57eb3506"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "desarrollo",
"resourceVersion": "27969476",
"uid": "e5a447de-2eba-4f2d-8300-d9e183cfc027"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "develop",
"resourceVersion": "95905051",
"uid": "c225254f-ce12-4f16-80db-611980883c92"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "ever",
"resourceVersion": "10597830",
"uid": "42c3c31e-269b-477d-8b10-e8129aebe6c7"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin"
},
"subjects": [
{
"kind": "ServiceAccount",
"name": "argocd-application-controller",
--
"name": "admin",
"namespace": "explorador-alfresco",
"resourceVersion": "5661498",
"uid": "4ac5ee46-e34f-4d41-b102-6187995a4d72"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "infra",
"resourceVersion": "20767514",
"uid": "6a67422f-6400-4adf-a473-250e1059c0bc"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin"
},
"subjects": [
{
"kind": "ServiceAccount",
"name": "cluster-cloud-controller-manager",
--
"name": "edit"
},
"subjects": [
{
"kind": "ServiceAccount",
"name": "cluster-samples-operator",
--
"name": "admin",
"namespace": "production",
"resourceVersion": "121265267",
"uid": "d8d4bf2d-885c-496c-bfa3-400f9d300c69"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "proyecto-base",
"resourceVersion": "11212278",
"uid": "46ec4e3e-558f-4e9a-881b-72eac28ab239"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "prueba-vale",
"resourceVersion": "11313381",
"uid": "b8c58207-8790-4253-bf30-4ff760336981"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "staging",
"resourceVersion": "96052752",
"uid": "e8bc331a-fbba-4adb-a921-c3d19df9b065"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "test-2",
"resourceVersion": "29752859",
"uid": "2faac485-ce2f-412a-b0ec-cbfc5e56d18b"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
--
"name": "admin",
"namespace": "una-microservice-infra",
"resourceVersion": "27010464",
"uid": "84ec0c45-9c0e-443e-ad89-59e1f23bd79b"
},
"roleRef": {
--
"name": "admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "User",
cgi@okd-provisioner-nodo01:~$ oc get rolebindings --all-namespaces \
-o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ROLE:.roleRef.name | \
grep -iE 'admin|edit'
allam admin admin
allam2 admin admin
cluster-maintenance admin admin
cluster-maintenance edit edit
correo admin admin
desarrollo-vm admin admin
desarrollo admin admin
develop admin admin
ever admin admin
ever admin-0 admin
explorador-alfresco admin admin
infra admin admin
openshift-cloud-controller-manager cluster-cloud-controller-manager admin
openshift-console-user-settings console-user-settings-admin console-user-settings-admin
openshift-console-user-settings user-settings-kubeadmin-rolebinding user-settings-kubeadmin-role
openshift-monitoring alertmanager-prometheusk8s monitoring-alertmanager-edit
openshift-monitoring insights-operator-alertmanager monitoring-alertmanager-edit
openshift cluster-samples-operator-openshift-edit edit
production admin admin
proyecto-base admin admin
prueba-vale admin admin
staging admin admin
test-2 admin admin
una-microservice-infra admin admin
- Verificamos
oc get routes --all-namespaces -o json | \
jq -r '.items[] | [.metadata.namespace, .metadata.name, .spec.path] | @tsv'- Resultado
allam admin User/kube:admin
allam2 admin User/allam@una.ac.cr
cluster-maintenance admin User/kube:admin
cluster-maintenance edit ServiceAccount/image-pruner
correo admin User/system:admin
desarrollo-vm admin User/kube:admin
desarrollo admin User/kube:admin
develop admin User/kube:admin
ever admin User/ever.vega.suazo@una.ac.cr
ever admin ServiceAccount/argocd-application-controller
explorador-alfresco admin User/kube:admin
infra admin User/kube:admin
openshift-cloud-controller-manager admin ServiceAccount/cluster-cloud-controller-manager
openshift edit ServiceAccount/cluster-samples-operator
production admin User/kube:admin
proyecto-base admin User/valeria.herrera.rodriguez@una.ac.cr
prueba-vale admin User/kube:admin
staging admin User/kube:admin
test-2 admin User/kube:admin
una-microservice-infra admin User/kube:admin
Veredicto sobre el riesgo práctico
Son tres usuarios humanos (cuentas @una.ac.cr, claramente personas reales de tu organización) que, por tener admin en sus proyectos, pueden crear Routes y por tanto alcanzar el vector de CVE-2026-1784. Esto baja bastante respecto a mi alarma anterior — no son 16 usuarios arbitrarios, son 3 cuentas nominales identificables dentro de tu propia institución.
Cómo dimensionar el riesgo de forma realista:
- No es un vector anónimo ni externo. Requiere una de esas tres credenciales válidas. Son personas de tu organización, no atacantes cualquiera de internet.
- Pero sí es escalada de privilegios. Un project-admin es un rol intencionalmente limitado: no debería poder ejecutar código en los nodos de infraestructura. Este CVE rompe esa frontera — convierte «admin de mi proyecto» en «RCE en el router». El modelo de confianza importa: ¿confiás en esas tres personas a nivel de poder ejecutar código en tu plano de infraestructura? Si una de esas cuentas se compromete (phishing, credencial filtrada), el atacante hereda el vector.
- El ArgoCD de ever es el punto que yo vigilaría con más atención, porque amplía la superficie de «una persona» a «cualquiera que pueda hacer merge en el repo Git que ese Argo sincroniza». Conviene confirmar qué repositorio alimenta ese argocd-application-controller y quién tiene acceso de escritura.
Confirmacion final
oc auth can-i create routes --as=ever.vega.suazo@una.ac.cr -n ever
oc auth can-i create routes --as=allam@una.ac.cr -n allam2
oc auth can-i create routes --as=valeria.herrera.rodriguez@una.ac.cr -n proyecto-base- Resultado
cgi@okd-provisioner-nodo01:~$ oc auth can-i create routes --as=ever.vega.suazo@una.ac.cr -n ever
yes
cgi@okd-provisioner-nodo01:~$ oc auth can-i create routes --as=allam@una.ac.cr -n allam2
yes
cgi@okd-provisioner-nodo01:~$ oc auth can-i create routes --as=valeria.herrera.rodriguez@una.ac.cr -n proyecto-base
yes
Recomendación final
- Parchá el router actualizando OKD cuando puedas — es el cierre de raíz del vector.
- Auditá el ArgoCD de ever — confirmá repo de origen y permisos de escritura.
- Revisá si esas tres personas necesitan admin o si edit sin gestión de Routes les alcanza (aunque ojo: edit también suele permitir Routes en OpenShift, así que verificá el rol exacto si querés restringir).
- Auditá Routes existentes en esos tres namespaces buscando spec.path anómalos.
Estado final, ya sin pendientes de verificación
El vector queda confirmado empíricamente:
ever.vega.suazo@una.ac.crpuede crear Routes eneverallam@una.ac.crpuede crear Routes enallam2valeria.herrera.rodriguez@una.ac.crpuede crear Routes enproyecto-base- Más el
argocd-application-controllerenever(GitOps), que sigue pendiente de auditar en cuanto a repo de origen.