pow

Version	Released
`1.0.39` patch	Jan 11, 2025
`1.0.38` patch	Apr 11, 2024
`1.0.37` patch	Mar 03, 2024
`1.0.36` patch	Feb 08, 2024
`1.0.35` patch	Jan 05, 2024
`1.0.34` patch	Sep 18, 2023
`1.0.33` patch 1 CVE	Sep 06, 2023
`1.0.32` patch 1 CVE	Aug 30, 2023
`1.0.31` patch 1 CVE	Jun 09, 2023
`1.0.30` patch 1 CVE	Apr 28, 2023
`1.0.29` patch 1 CVE	Mar 21, 2023
`1.0.28` patch 1 CVE	Mar 17, 2023
`1.0.27` patch 1 CVE	Apr 28, 2022
`1.0.26` patch 1 CVE	Nov 06, 2021
`1.0.25` patch 1 CVE	Sep 27, 2021
`1.0.24` patch 1 CVE	May 27, 2021
`1.0.23` patch 1 CVE	Mar 22, 2021
`1.0.22` patch 1 CVE	Jan 27, 2021
`1.0.21` patch 1 CVE	Sep 13, 2020
`1.0.20` patch 1 CVE	Apr 22, 2020
`1.0.19` patch 1 CVE	Mar 13, 2020
`1.0.18` patch 1 CVE	Feb 15, 2020
`1.0.17` patch 1 CVE	Feb 04, 2020
`1.0.16` patch 1 CVE	Jan 08, 2020
`1.0.15` patch 2 CVEs	Nov 20, 2019
`1.0.14` patch 2 CVEs	Oct 29, 2019
`1.0.13` patch 1 CVE	Aug 25, 2019
`1.0.12` patch 1 CVE	Aug 16, 2019
`1.0.11` patch 1 CVE	Jun 14, 2019
`1.0.10` patch 1 CVE	Jun 09, 2019
`1.0.9` patch 1 CVE	Jun 04, 2019
`1.0.8` patch 1 CVE	May 24, 2019
`1.0.7` patch 1 CVE	May 01, 2019
`1.0.6` patch 1 CVE	Apr 19, 2019
`1.0.5` patch 1 CVE	Apr 09, 2019
`1.0.4` patch 1 CVE	Mar 14, 2019
`1.0.3` patch 1 CVE	Mar 09, 2019
`1.0.2` patch 1 CVE	Feb 28, 2019
`1.0.1` patch 1 CVE	Jan 27, 2019
`1.0.0` initial 1 CVE	Nov 18, 2018
`1.0.0-rc.4` pre 1 CVE	Sep 05, 2018
`1.0.0-rc.3` pre 1 CVE	Aug 26, 2018
`1.0.0-rc.2` pre 1 CVE	Aug 25, 2018
`1.0.0-rc.1` pre 1 CVE	Aug 25, 2018
`1.0.0-rc.0` pre 1 CVE	Aug 12, 2018
`0.1.0-rc.1` pre 1 CVE	Aug 11, 2018
`0.1.0-alpha.8` pre 1 CVE	Aug 11, 2018
`0.1.0-alpha.7` pre 1 CVE	Aug 11, 2018
`0.1.0-alpha.6` pre 1 CVE	Aug 07, 2018
`0.1.0-alpha.5` pre 1 CVE	Aug 06, 2018

1.0.39 patch

Jan 11, 2025

1.0.38 patch

Apr 11, 2024

1.0.37 patch

Mar 03, 2024

1.0.36 patch

Feb 08, 2024

1.0.35 patch

Jan 05, 2024

1.0.34 patch

Sep 18, 2023

1.0.33 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Sep 06, 2023

1.0.32 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Aug 30, 2023

1.0.31 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Jun 09, 2023

1.0.30 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Apr 28, 2023

1.0.29 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Mar 21, 2023

1.0.28 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Mar 17, 2023

1.0.27 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Apr 28, 2022

1.0.26 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Nov 06, 2021

1.0.25 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Sep 27, 2021

1.0.24 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

May 27, 2021

1.0.23 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Mar 22, 2021

1.0.22 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Jan 27, 2021

1.0.21 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Sep 13, 2020

1.0.20 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Apr 22, 2020

1.0.19 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Mar 13, 2020

1.0.18 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Feb 15, 2020

1.0.17 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Feb 04, 2020

1.0.16 patch

1 CVE

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

Jan 08, 2020

1.0.15 patch

2 CVEs

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

CVE-2020-5205 GHSA-v2wf-c3j6-wpvw Apr 12, 2022

Session fixation

6.5 / 10

Medium

Network High Low Required Changed High Low None

Impact

The use of Plug.Session in Pow.Plug.Session is susceptible to session fixation attacks if a persistent session store is used for Plug.Session, such as Redis or a database. Cookie store, which is used in most Phoenix apps, doesn't have this vulnerability.

Workarounds

Call Plug.Conn.configure_session(conn, renew: true) periodically and after privilege change. A custom authorization plug can be written where the create/3 method should return the conn only after Plug.Conn.configure_session/2 have been called on it.

References

https://github.com/danschultzer/pow/commit/578ffd3d8bb8e8a26077b644222186b108da474f
https://www.owasp.org/index.php/Session_fixation

Affected versions


          0.1.0-alpha


          0.1.0-alpha.1


          0.1.0-alpha.2


          0.1.0-alpha.3


          0.1.0-alpha.4


          0.1.0-alpha.5


          0.1.0-alpha.6


          0.1.0-alpha.7


          0.1.0-alpha.8


          0.1.0-rc.1


          1.0.0


          1.0.0-rc.0

+ 19 more


            1.0.0-rc.1


            1.0.0-rc.2


            1.0.0-rc.3


            1.0.0-rc.4


            1.0.1


            1.0.10


            1.0.11


            1.0.12


            1.0.13


            1.0.14


            1.0.15


            1.0.2


            1.0.3


            1.0.4


            1.0.5


            1.0.6


            1.0.7


            1.0.8


            1.0.9

Fixed in


          1.0.16

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 20, 2019

1.0.14 patch

2 CVEs

CVE-2023-42446 GHSA-3cjh-p6pw-jhv9 Sep 19, 2023

Pow Mnesia cache doesn't invalidate all expired keys on startup

6.5 / 10

Medium

Network Low Low None Unchanged None High None

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Affected versions


          1.0.14


          1.0.15


          1.0.16


          1.0.17


          1.0.18


          1.0.19


          1.0.20


          1.0.21


          1.0.22


          1.0.23


          1.0.24


          1.0.25

+ 8 more


            1.0.26


            1.0.27


            1.0.28


            1.0.29


            1.0.30


            1.0.31


            1.0.32


            1.0.33

Fixed in


          1.0.34

References

Updated Dec 10, 2025 · Source: OSV.dev

CVE-2020-5205 GHSA-v2wf-c3j6-wpvw Apr 12, 2022

Session fixation

6.5 / 10

Medium

Network High Low Required Changed High Low None

Impact

The use of Plug.Session in Pow.Plug.Session is susceptible to session fixation attacks if a persistent session store is used for Plug.Session, such as Redis or a database. Cookie store, which is used in most Phoenix apps, doesn't have this vulnerability.

Workarounds

Call Plug.Conn.configure_session(conn, renew: true) periodically and after privilege change. A custom authorization plug can be written where the create/3 method should return the conn only after Plug.Conn.configure_session/2 have been called on it.

References

https://github.com/danschultzer/pow/commit/578ffd3d8bb8e8a26077b644222186b108da474f
https://www.owasp.org/index.php/Session_fixation

Affected versions


          0.1.0-alpha


          0.1.0-alpha.1


          0.1.0-alpha.2


          0.1.0-alpha.3


          0.1.0-alpha.4


          0.1.0-alpha.5


          0.1.0-alpha.6


          0.1.0-alpha.7


          0.1.0-alpha.8


          0.1.0-rc.1


          1.0.0


          1.0.0-rc.0

+ 19 more


            1.0.0-rc.1


            1.0.0-rc.2


            1.0.0-rc.3


            1.0.0-rc.4


            1.0.1


            1.0.10


            1.0.11


            1.0.12


            1.0.13


            1.0.14


            1.0.15


            1.0.2


            1.0.3


            1.0.4


            1.0.5


            1.0.6


            1.0.7


            1.0.8


            1.0.9

Fixed in


          1.0.16

References

Updated Jul 08, 2026 · Source: OSV.dev

Oct 29, 2019

1.0.13 patch

1 CVE

Aug 25, 2019

1.0.12 patch

1 CVE

Aug 16, 2019

1.0.11 patch

1 CVE

Jun 14, 2019

1.0.10 patch

1 CVE

Jun 09, 2019

1.0.9 patch

1 CVE

Jun 04, 2019

1.0.8 patch

1 CVE

May 24, 2019

1.0.7 patch

1 CVE

May 01, 2019

1.0.6 patch

1 CVE

Apr 19, 2019

1.0.5 patch

1 CVE

Apr 09, 2019

1.0.4 patch

1 CVE

Mar 14, 2019

1.0.3 patch

1 CVE

Mar 09, 2019

1.0.2 patch

1 CVE

Feb 28, 2019

1.0.1 patch

1 CVE

Jan 27, 2019

1.0.0 initial

1 CVE

Nov 18, 2018

1.0.0-rc.4 pre

1 CVE

Sep 05, 2018

1.0.0-rc.3 pre

1 CVE

Aug 26, 2018

1.0.0-rc.2 pre

1 CVE

Aug 25, 2018

1.0.0-rc.1 pre

1 CVE

Aug 25, 2018

1.0.0-rc.0 pre

1 CVE

Aug 12, 2018

0.1.0-rc.1 pre

1 CVE

Aug 11, 2018

0.1.0-alpha.8 pre

1 CVE

Aug 11, 2018

0.1.0-alpha.7 pre

1 CVE

Aug 11, 2018

0.1.0-alpha.6 pre

1 CVE

Aug 07, 2018

0.1.0-alpha.5 pre

1 CVE

Aug 06, 2018

Activity

Details