Bunkum
An open-source protocol-agnostic request server for custom game servers, built with flexibility yet ease of use in mind.
Activity
- Latest release
- 1y ago
- Total releases
- 107
- Cadence
- ~4 days
- Last 12 months
- 0
Details
- License
- unknown
- First release
- Jan 21, 2023
| Version | Released | |
|---|---|---|
4.9.0
minor
| ||
4.8.1
patch
| ||
4.8.0
minor
| ||
4.7.1
patch
| ||
4.7.0
minor
| ||
4.6.0
minor
| ||
4.5.6
patch
| ||
4.5.5
patch
| ||
4.5.4
patch
| ||
4.5.3
patch
| ||
4.5.2
patch
| ||
4.5.1
patch
| ||
4.5.0
minor
| ||
4.4.5
patch
| ||
4.4.4
patch
| ||
4.4.3
patch
| ||
4.4.2
patch
| ||
4.4.1
patch
| ||
4.4.0
minor
| ||
4.3.3
patch
| ||
4.3.2
patch
| ||
4.3.1
patch
| ||
4.3.0
minor
| ||
4.2.3
patch
| ||
4.2.2
patch
| ||
4.2.1
patch
| ||
4.2.0
minor
1 CVE
CVE-2023-45814
GHSA-jrf2-h5j6-3rrq
Oct 19, 2023
Bunkum tokens cached in the AuthenticationService are susceptible to a use-after-free
5.3
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
None
ImpactFirst, a little bit of background. So, in the beginning, Bunkum's Bunkum 4.0 then changed to enforce relations between Naturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of Security-wise, the scope is fairly limited, can only be pulled off on a couple endpoints given a few conditions, and you can't guarantee which token you're going to get. Also, the token would get invalidated properly if the endpoint had either a PatchesThe fix is to just wipe the token cache after the request was handled, which is now in Affected versions
4.0.0
4.0.1
4.1.0
4.2.0
Fixed in
4.2.1
References Updated Feb 16, 2024 · Source: OSV.dev | ||
4.1.0
minor
1 CVE
CVE-2023-45814
GHSA-jrf2-h5j6-3rrq
Oct 19, 2023
Bunkum tokens cached in the AuthenticationService are susceptible to a use-after-free
5.3
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
None
ImpactFirst, a little bit of background. So, in the beginning, Bunkum's Bunkum 4.0 then changed to enforce relations between Naturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of Security-wise, the scope is fairly limited, can only be pulled off on a couple endpoints given a few conditions, and you can't guarantee which token you're going to get. Also, the token would get invalidated properly if the endpoint had either a PatchesThe fix is to just wipe the token cache after the request was handled, which is now in Affected versions
4.0.0
4.0.1
4.1.0
4.2.0
Fixed in
4.2.1
References Updated Feb 16, 2024 · Source: OSV.dev | ||
4.0.1
patch
1 CVE
CVE-2023-45814
GHSA-jrf2-h5j6-3rrq
Oct 19, 2023
Bunkum tokens cached in the AuthenticationService are susceptible to a use-after-free
5.3
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
None
ImpactFirst, a little bit of background. So, in the beginning, Bunkum's Bunkum 4.0 then changed to enforce relations between Naturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of Security-wise, the scope is fairly limited, can only be pulled off on a couple endpoints given a few conditions, and you can't guarantee which token you're going to get. Also, the token would get invalidated properly if the endpoint had either a PatchesThe fix is to just wipe the token cache after the request was handled, which is now in Affected versions
4.0.0
4.0.1
4.1.0
4.2.0
Fixed in
4.2.1
References Updated Feb 16, 2024 · Source: OSV.dev | ||
4.0.0
major
1 CVE
CVE-2023-45814
GHSA-jrf2-h5j6-3rrq
Oct 19, 2023
Bunkum tokens cached in the AuthenticationService are susceptible to a use-after-free
5.3
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
None
ImpactFirst, a little bit of background. So, in the beginning, Bunkum's Bunkum 4.0 then changed to enforce relations between Naturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of Security-wise, the scope is fairly limited, can only be pulled off on a couple endpoints given a few conditions, and you can't guarantee which token you're going to get. Also, the token would get invalidated properly if the endpoint had either a PatchesThe fix is to just wipe the token cache after the request was handled, which is now in Affected versions
4.0.0
4.0.1
4.1.0
4.2.0
Fixed in
4.2.1
References Updated Feb 16, 2024 · Source: OSV.dev | ||
3.5.0
minor
| ||
3.4.5
patch
| ||
3.4.4
patch
| ||
3.4.3
patch
| ||
3.4.2
patch
| ||
3.4.1
patch
| ||
3.4.0
minor
| ||
3.3.18
patch
| ||
3.3.17
patch
| ||
3.3.16
patch
| ||
3.3.15
patch
| ||
3.3.14
patch
| ||
3.3.13
patch
| ||
3.3.12
patch
| ||
3.3.11
patch
| ||
3.3.10
patch
| ||
3.3.9
patch
| ||
3.3.8
patch
| ||
3.3.7
patch
| ||
3.3.6
patch
|