Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Minder's Git provider is vulnerable to a denial of service from a maliciously configured GitHub repository. The Git provider clones users repositories using the github.com/go-git/go-git/v5 library on these lines: https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89 The Git provider does the following on these lines: First, it sets the CloneOptions, specifying the url, the depth etc: https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62 It then validates the options: https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L66-L68 It then sets up an in-memory filesystem, to which it clones: https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L70-L71 Finally, it clones the repository:…
Recommended action: Upgrade to 0.0.52 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Minder is vulnerable to a denial-of-service (DoS) attack which could allow an attacker to crash the Minder server and deny other users access to it. The root cause of the vulnerability is that Minders sigstore verifier reads an untrusted response entirely into memory without enforcing a limit on the response body. An attacker can exploit this by making Minder make a request to an attacker-controlled endpoint which returns a response with a large body which will crash the Minder server. Specifically, the point of failure is where Minder parses the response from the GitHub attestations endpoint in getAttestationReply. Here, Minder makes a request to the orgs/$owner/attestations/$checksumref GitHub endpoint (line 285) and then parses the response into the AttestationReply (line 295): https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/verifier/sigstore/container/container.go#L271-L300 The way Minder parses the response on line 295 makes it prone to…
Recommended action: Upgrade to 0.0.51 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Minder engine is susceptible to a denial of service from memory exhaustion that can be triggered from maliciously created templates. Minder engine uses templating to generate strings for various use cases such as URLs, messages for pull requests, descriptions for advisories. In some cases can the user control both the template and the params for it, and in a subset of these cases, Minder reads the generated template entirely into memory. When Minders templating meets both of these conditions, an attacker is able to generate large enough templates that Minder will exhaust memory and crash. One of these places is the REST ingester: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L115-L123 With control over both endpoint and retp on the following line: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L121 … an attacker can make Minder generate a…
Recommended action: Upgrade to 0.0.50 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Minder REST ingester is vulnerable to a denial of service attack via an attacker-controlled REST endpoint that can crash the Minder server. The REST ingester allows users to interact with REST endpoints to fetch data for rule evaluation. When fetching data with the REST ingester, Minder sends a request to an endpoint and will use the data from the body of the response as the data to evaluate against a certain rule. Minder sends the request on these lines: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L131-L139 … and parses the response body on these lines: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L147-L150 https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L196-L220 Minder creates the URL of the endpoint via templating on these lines:…
Recommended action: Upgrade to 0.0.49 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Minder's HandleGithubWebhook is susceptible to a denial of service attack from an untrusted HTTP request. The vulnerability exists before the request has been validated, and as such the request is still untrusted at the point of failure. This allows an attacker with the ability to send requests to HandleGithubWebhook to crash the Minder controlplane and deny other users from using it. One of the first things that HandleGithubWebhook does is to validate the payload signature. This is done by way of the internal helper validatePayloadSignature: https://github.com/stacklok/minder/blob/ee66f6c0763212503c898cfefb65ce1450c7f5ac/internal/controlplane/handlersgithubwebhooks.go#L213-L218 validatePayloadSignature generates a reader from the incoming request by way of the internal helper readerFromRequest: https://github.com/stacklok/minder/blob/ee66f6c0763212503c898cfefb65ce1450c7f5ac/internal/controlplane/handlersgithubwebhooks.go#L337-L342 To create a reader from the incoming request,…
Recommended action: Upgrade to 0.0.48 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/stacklok/minder >= 0.0.39, <= 0.0.39
Fixed in
0.0.40· Vendor fix available
Issue
Impact A recent refactoring added the ability to get GitHub repositories registered to a project without specifying a specific provider. Unfortunately, the SQL query for doing so was missing parenthesis, and would select a random repository. Patches Patched in #2941 Workarounds Revert prior to 5c381cf, or roll forward past 2eb94e7 References N/A
Recommended action: Upgrade to 0.0.40 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Minder user can use the endpoints listed in the issue title to access any repository in the DB, irrespective of who owns the repo and any permissions that user may have. Details https://github.com/stacklok/minder/blob/e88e4b286e4bc04c03b0332a77961f085e1aa77f/database/query/repositories.sql#L22-L23 https://github.com/stacklok/minder/blob/a115c8524fbd582b2b277eaadce024bebbded508/internal/controlplane/handlersrepositories.go#L277-L278 The DB query used here checks by repo owner, repo name and provider name (which is always "github"). These query values are not distinct for the particular user - as long as the user has valid credentials and a provider, they can set the repo owner/name to any value they want and the server will return information on this repo. DeleteRepositoryByName uses the same query and I have been able to delete another user's repo using this technique. The GetArtifactByName endpoint also uses this DB query. I have not reproduced the behaviour with this…
Recommended action: Upgrade to 0.0.33 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using a modified client or the grpc interface directly, the RegisterRepository call accepts both the repository owner / repo and the repoid. Furthermore, these two are not checked for matching before registering webhooks and data in the database. Details It is possible for an attacker to register a repository with a invalid or differing upstream ID, which causes Minder to report the repository as registered, but not remediate any future changes which conflict with policy (because the webhooks for the repo do not match any known repository in the database). When attempting to register a repo with a different repo ID, the registered provider must have admin on the named repo, or a 404 error will result. Similarly, if the stored provider token does not have repo access, then the remediations will not apply successfully. Lastly, it appears that reconciliation actions do not execute against repos with this type of mismatch. PoC With an RPC like the following text proto: I was…
Recommended action: Upgrade to 0.20240226.1425 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.