jupyterhub-kubespawner

Version	Released
`7.1.0` minor	Jul 16, 2026
`7.0.0` major	Oct 25, 2024
`7.0.0b3` pre	Oct 11, 2024
`7.0.0b2` pre	Oct 02, 2024
`7.0.0b1` pre	Sep 23, 2024
`6.2.0` minor	Nov 23, 2023
`6.1.0` minor	Sep 28, 2023
`6.0.0` major	May 31, 2023
`5.0.0` major	Apr 18, 2023
`4.3.0` minor	Nov 03, 2022
`4.2.0` minor	Aug 29, 2022
`4.1.0` minor	May 19, 2022
`4.0.0` major	Apr 23, 2022
`3.0.2` patch	Mar 15, 2022
`3.0.1` patch	Mar 14, 2022
`3.0.0` major	Mar 14, 2022
`2.0.1` patch	Feb 15, 2022
`2.0.0` major	Nov 28, 2021
`1.1.2` patch	Nov 03, 2021
`1.1.1` patch	Oct 04, 2021
`1.1.0` minor	Jul 21, 2021
`1.0.0` major	May 14, 2021
`0.16.1` patch	Mar 01, 2021
`0.16.0` minor	Feb 26, 2021
`0.15.0` minor	Dec 15, 2020
`0.14.1` patch	Oct 23, 2020
`0.14.0` minor	Oct 05, 2020
`0.13.0` minor	Sep 04, 2020
`0.12.0` minor	Jul 17, 2020
`0.11.1` patch 1 CVE	Nov 29, 2019
`0.11.0` minor 1 CVE	Nov 28, 2019
`0.10.1` patch 1 CVE	Dec 11, 2018
`0.10.0` minor 1 CVE	Dec 05, 2018
`0.9.0` minor 1 CVE	Sep 03, 2018
`0.9.0b2` pre 1 CVE	Aug 27, 2018
`0.9.0b1` pre 1 CVE	Aug 19, 2018
`0.8.1` patch 1 CVE	Jan 30, 2018
`0.8` minor 1 CVE	Jan 24, 2018
`0.7.1` minor 1 CVE	Nov 28, 2017
`0.6.0` minor 1 CVE	Aug 29, 2017
`0.5.1` patch 1 CVE	Dec 31, 2016
`0.5` initial 1 CVE	Nov 17, 2016

7.1.0 minor

Jul 16, 2026

7.0.0 major

Oct 25, 2024

7.0.0b3 pre

Oct 11, 2024

7.0.0b2 pre

Oct 02, 2024

7.0.0b1 pre

Sep 23, 2024

6.2.0 minor

Nov 23, 2023

6.1.0 minor

Sep 28, 2023

6.0.0 major

May 31, 2023

5.0.0 major

Apr 18, 2023

4.3.0 minor

Nov 03, 2022

4.2.0 minor

Aug 29, 2022

4.1.0 minor

May 19, 2022

4.0.0 major

Apr 23, 2022

3.0.2 patch

Mar 15, 2022

3.0.1 patch

Mar 14, 2022

3.0.0 major

Mar 14, 2022

2.0.1 patch

Feb 15, 2022

2.0.0 major

Nov 28, 2021

1.1.2 patch

Nov 03, 2021

1.1.1 patch

Oct 04, 2021

1.1.0 minor

Jul 21, 2021

1.0.0 major

May 14, 2021

0.16.1 patch

Mar 01, 2021

0.16.0 minor

Feb 26, 2021

0.15.0 minor

Dec 15, 2020

0.14.1 patch

Oct 23, 2020

0.14.0 minor

Oct 05, 2020

0.13.0 minor

Sep 04, 2020

0.12.0 minor

Jul 17, 2020

0.11.1 patch

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 29, 2019

0.11.0 minor

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 28, 2019

0.10.1 patch

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Dec 11, 2018

0.10.0 minor

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Dec 05, 2018

0.9.0 minor

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Sep 03, 2018

0.9.0b2 pre

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Aug 27, 2018

0.9.0b1 pre

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Aug 19, 2018

0.8.1 patch

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Jan 30, 2018

0.8 minor

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Jan 24, 2018

0.7.1 minor

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 28, 2017

0.6.0 minor

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Aug 29, 2017

0.5.1 patch

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Dec 31, 2016

0.5 initial

1 CVE

CVE-2020-15110 GHSA-v7m9-9497-p9gr PYSEC-2020-51 Jul 22, 2020

Possible pod name collisions in jupyterhub-kubespawner

High

Network Low Low None

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
enabled named_servers (not default), and
an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
- usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in kubespawner
Email us at security@ipython.org

Credit: Jining Huang

Affected versions

0.1


          0.10.0


          0.10.1


          0.11.0


          0.11.1

0.5


          0.5.1


          0.6.0


          0.7.1

0.8


          0.8.1


          0.9.0

+ 2 more


            0.9.0b1


            0.9.0b2

Fixed in


          0.12.0

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 17, 2016

Activity

Reach

Details