k3sm runs privileged components (a root networking helper and a process sandbox), so a public bug report is a disclosed zero-day before there is a fix. Please report privately.

Reporting a Vulnerability#

Do not open a public GitHub issue for a security problem. Use these channels, in this order of preference:

Open a private GitHub security advisory from the affected repository’s Security tab, using Report a vulnerability. This channel comes first because it is private, it supports coordinated and embargoed collaboration, and a CVE can be issued from it. Direct links: k3sm, runtimed, darwin-net, apis. If you are unsure which repository is affected, use k3sm.
Email kitsumiko@k3sm.io if the advisory flow is unavailable to you, or if you would rather not open a GitHub account to make a report.
Or contact the maintainer directly by messaging @kitsumiko on GitHub.

Please include the affected component and a reproduction if you have one.

What Counts as High Severity#

Local privilege escalation is anything that gets from the unprivileged _k3sm user, or from inside a Pod, to root. The k3sm-netd helper is the only long-running root component and accepts a closed, typed RPC over a uid-authenticated socket; making it act outside that contract is serious. (A data root on its own volume adds a root daemon that mounts it at boot.)
Sandbox escape is anything that lets a Pod’s process reach outside its Seatbelt profile, such as reading /Users, writing outside its own data volume, or reaching another Pod’s files.
Guest kernel or initramfs substitution is a way to make a vm guest boot an unpinned kernel or initramfs. The digest pin is the whole trust chain, because a VM-booted kernel gets no OS code-signing check.

Also serious: a way to join a cluster without the join credentials, a way to impersonate a node, a flaw in certificate issuance or trust, and a weakness in the release download path.

Where the Trust Boundaries Sit#

The server’s own node runs as system:node:<name> under the Node authorizer, so a node bug cannot act as cluster admin.
Secrets are unencrypted in the datastore unless the cluster was created with sudo k3sm install --secrets-encryption, which is opt-in and off by default.
The admin token and the datastore connection string stay off the server’s command line, and the mesh keys sit under a root-owned state root.
A torn-down Pod’s address is blackholed, a defence against a macOS kernel panic seen on the pod network.
Releases are not yet Developer-ID signed or notarized. The install script checks a download against its published checksum, which shows the file is intact and says nothing about who built it.

What Is a Documented Limitation, Not a Vulnerability#

These design trade-offs are stated in advance in limitations. A report about one is still welcome as a discussion rather than an embargoed advisory.

Same-node Pods share one trust domain, because every Pod on a node runs as the same _k3sm user, with no per-Pod uid isolation and no network namespace. The vm RuntimeClass, the path for untrusted work, boots each Pod into its own micro-VM with the supervisor confined on the host. It is linux/arm64 and single-node, and a container in one of its Pods can read volumes it does not mount.
NetworkPolicy is a policy hint, enforced only on Service-VIP-mediated ingress on the server node. Direct Pod-IP traffic bypasses it, egress rules and ipBlock are not enforced, and a joined worker enforces no policy at all. It is not a security boundary.
Seatbelt network permission is all-or-nothing, because macOS accepts no per-address filters in a sandbox profile. The per-Pod egress opt-in is an admission-level contract with no packet filter behind it.
Pods share the node’s port space, so a Pod and a LoadBalancer listener can collide on a port.

A new case in one of these classes is worth reporting, and so is documentation that describes a boundary as stronger than it is.

Disclosure#

k3sm follows coordinated disclosure. A report is acknowledged, a fix is worked under embargo, and you are credited when the fix is released, unless you would rather not be.

Supported Versions#

Please report against the latest main. There is no supported-versions policy yet; one comes with the first stable release planned. Fixes ship in a new pre-release, which re-running the install script installs.

The canonical policy is SECURITY in the repository.