Approved changes feed: RSS · Atom

cpe:2.3:a:kubeoperator:kubepi:*:*:*:*:*:*:*:*

part: a version: * update: *

VendorKubeoperator (8368dfc5-94fa-5ee7-aa56-c740d05d960e)
ProductKubepi (3e86c762-a74e-55e5-afe5-b81743f4ab2a)
Edition*
Language*
Software edition*
Target software*
Target hardware*
Other*
NotesImported from gcve-enriched-dumps CVE data

PURL mappings

PURLSourceLast updated
No PURL mappings for this CPE yet.

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
CVE:CVE-2023-22479 vulnerable 2026-06-08 05:54:26.407056 KubePi vulnerable to session fixation attack
HIGH (7.5)
KubePi is a modern Kubernetes panel. A session fixation attack allows an attacker to hijack a legitimate user session, versions 1.6.3 and below are susceptible. A patch will be released in version 1.6.4.
Published: 2023-01-10T20:34:08.097Z
Updated: 2025-03-10T21:30:47.885Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2023-22478 vulnerable 2026-06-08 05:54:26.406675 KubePi is vulnerable to missing authorization
HIGH (7.3)
KubePi is a modern Kubernetes panel. The API interfaces with unauthorized entities and may leak sensitive information. This issue has been patched in version 1.6.4. There are currently no known workarounds.
Published: 2023-01-14T00:22:54.146Z
Updated: 2025-03-10T21:29:57.856Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2023-22463 vulnerable 2026-06-08 05:54:26.353413 KubePi's Hardcoded Jwtsigkeys allows malicious actor to login with a forged JWT token
CRITICAL (9.8)
KubePi is a k8s panel. The jwt authentication function of KubePi through version 1.6.2 uses hard-coded Jwtsigkeys, resulting in the same Jwtsigkeys for all online projects. This means that an attacker can forge any jwt token to take over the administrator account of any online project. Furthermore, they may use the administrator to take over the k8s cluster of the target enterprise. `session.go`, the use of hard-coded JwtSigKey, allows an attacker to use this value to forge jwt tokens arbitrarily. The JwtSigKey is confidential and should not be hard-coded in the code. The vulnerability has been fixed in 1.6.3. In the patch, JWT key is specified in app.yml. If the user leaves it blank, a random key will be used. There are no workarounds aside from upgrading.
Published: 2023-01-04T15:04:18.195Z
Updated: 2025-03-10T21:32:56.890Z
Reference links
Imported from gcve-enriched-dumps CVE data

Contribute

You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.