CVE-2019-3876

mediumpriority · track · 25EPSS 0.007 · 52 %ileEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.67% (52nd) EPSS
CVSS 4.3 · medium
Is it mine?
29 products
Check your exposure
Who says so?
5 sources
cnnvd · enisa_euvd · nvd · osv

EPSS · scored 2026-10-27

A flaw was found in the /oauth/token/request custom endpoint of the OpenShift OAuth server allowing for XSS generation of CLI tokens due to missing X-Frame-Options and CSRF protections. If not otherwise prevented, a separate XSS vulnerability via JavaScript could further allow for the extraction of these tokens.

01

remediations

Vendor fix, mitigation, or workaround guidance, as published by each source.

A vendor fix is available.

  • Fixedatomic-openshift-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-0:3.11.129-1.git.0.bd4f2d5.el7.src as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-clients-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-clients-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-clients-redistributable-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-docker-excluder-0:3.11.129-1.git.0.bd4f2d5.el7.noarch as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-excluder-0:3.11.129-1.git.0.bd4f2d5.el7.noarch as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-hyperkube-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-hyperkube-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-hypershift-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-hypershift-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-master-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-master-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-node-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-node-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-pod-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-pod-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-sdn-ovs-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-sdn-ovs-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-template-service-broker-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-template-service-broker-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-tests-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedatomic-openshift-tests-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedjenkins-2-plugins-0:3.11.1560870549-1.el7.noarch as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Fixedjenkins-2-plugins-0:3.11.1560870549-1.el7.src as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    For OpenShift Container Platform 3.11 see the following documentation for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html

    https://access.redhat.com/errata/RHSA-2019:1851
  • Workaroundatomic-openshift-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-0:3.11.129-1.git.0.bd4f2d5.el7.src as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-clients-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-clients-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-clients-redistributable-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-docker-excluder-0:3.11.129-1.git.0.bd4f2d5.el7.noarch as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-excluder-0:3.11.129-1.git.0.bd4f2d5.el7.noarch as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-hyperkube-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-hyperkube-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-hypershift-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-hypershift-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-master-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-master-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-node-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-node-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-pod-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-pod-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-sdn-ovs-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-sdn-ovs-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-template-service-broker-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-template-service-broker-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-tests-0:3.11.129-1.git.0.bd4f2d5.el7.ppc64le as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundatomic-openshift-tests-0:3.11.129-1.git.0.bd4f2d5.el7.x86_64 as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundjenkins-2-plugins-0:3.11.1560870549-1.el7.noarch as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

  • Workaroundjenkins-2-plugins-0:3.11.1560870549-1.el7.src as a component of Red Hat OpenShift Container Platform 3.11redhat_csaf

    Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins

02

cvss

Technical severity, 0–10. One row per scoring source.

6.3
010

base score 0–10 · higher = more severe · hover a vector to decode

v2.04.3mediumAV:N/AC:M/Au:N/C:N/I:P/A:Nprimary · NVD / NIST USexploitability 8.6 · impact 2.9
v3.16.3mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:Lprimary · NVD / NIST USexploitability 2.8 · impact 3.4
v3.05mediumCVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:Lsecondary · secalert@redhat.com USexploitability 1.6 · impact 3.4
v3.05mediumCVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:Lsecondary · ENISA EU
v3.05mediumCVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:Lsecondary · Red Hat Product Security US
v3.15.8mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L/E:Usecondary · CVSS-BT (t0sche)
v3.16.3mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:Lsecondary · OSV
03

weaknesses

The CWE weakness classes this flaw belongs to.

CWE-352USCWE-352USCWE-352US
04

affected products (29)

Products and version ranges known to be affected.

showing 20 of 29
05

advisories (2)

Vendor and ecosystem advisories describing this.

  • RHSA-2019:1851Red Hat Security Advisory: OpenShift Container Platform 3.11 security update2019-07-24csaf · redhat_csafUS

    An update for atomic-openshift and jenkins-2-plugins is now available for Red Hat OpenShift Container Platform 3.11. Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

  • GHSA-jgwg-35hf-xqrrWithdrawn Advisory: OpenShift OAuth Server XSS Vulnerability2022-05-13ghsa · osvUS

    ## Withdrawn Advisory This advisory has been withdrawn because the vulnerability does not affect a package in one of the GitHub Advisory Database's [supported ecosystems](https://github.com/github/advisory-database/blob/main/README.md#supported-ecosystems). This link is maintained to preserve external references. ## Original Description A flaw was found in the `/oauth/token/request` custom endpoint of the OpenShift OAuth server allowing for XSS generation of CLI tokens due to missing X-Frame-Options and CSRF protections. If not otherwise prevented, a separate XSS vulnerability via JavaScript could further allow for the extraction of these tokens.

06

also known as (3)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

cnnvdenisa_euvdnvdosvredhat_csafNVDCVE.orgMITRE
published 2019-04-01modified 2026-06-17
08

references (16)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan