CVE-2019-3876

mediumPriorität · verfolgen · 25EPSS 0.007 · 52. PerzentilEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.67% (52nd) EPSS
CVSS 4.3 · medium
Is it mine?
29 products
Prüfe deine Angriffsfläche
Who says so?
5 sources
cnnvd · enisa_euvd · nvd · osv

EPSS · bewertet 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

Behebungen

Hersteller-Fix, Mitigation oder Workaround, wie von den Quellen veröffentlicht.

Ein Hersteller-Fix ist verfügbar.

  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenatomic-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
  • Behobenjenkins-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
  • Behobenjenkins-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

Technischer Schweregrad, 0–10. Eine Zeile je Quelle.

6.3
010

Basiswert 0–10 · höher = schwerwiegender · Vektor überfahren zum Auflösen

v2.04.3mediumAV:N/AC:M/Au:N/C:N/I:P/A:Nprimary · NVD / NIST USAusnutzbarkeit 8.6 · Auswirkung 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 USAusnutzbarkeit 2.8 · Auswirkung 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 USAusnutzbarkeit 1.6 · Auswirkung 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

schwächen

Die CWE-Schwächeklassen, zu denen dies gehört.

CWE-352USCWE-352USCWE-352US
04

betroffene Produkte (29)

Betroffene Produkte und Versionsbereiche.

20 von 29 angezeigt
05

Advisories (2)

Hersteller- und Ökosystem-Meldungen dazu.

  • 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

auch bekannt als (3)

Weitere Namen und Kennungen dieser Entität.

07

quellen

Welche Quellen diesen Datensatz belegen und wann.

cnnvdenisa_euvdnvdosvredhat_csafNVDCVE.orgMITRE
veröffentlicht 2019-04-01geändert 2026-06-17
08

Referenzen (16)

Externe Belege — Patches, Meldungen, Analysen.

scry

Angreifer nutzen Schwachstellen wie diese gegen im Internet exponierte Dienste aus. Sehen Sie mit einem kostenlosen Passiv-Scan, was exponiert ist.

Kostenloser Scan