Kolega-Ai-Dev

**Name of the Vulnerable Software and Affected Versions** portainer-ce versions 2.33.0 through 2.33.7 portainer-ce-agent versions 2.33.0 through 2.33.7 **Description** An authorization bypass exists in the middleware layer `kubeClientMiddleware` within the `api/http/handler/kubernetes/handler.go` file. The middleware validates user tokens before forwarding traffic to Kubernetes clusters; however, when the `security.RetrieveTokenData()` function returns an error, the system writes an HTTP 403 response but fails to stop execution. This allows the request to proceed to the handler with a nil `tokenData` value, bypassing authorization checks. An attacker with a valid Portainer session can use this flaw to read or modify Kubernetes resources, such as pods, secrets, config maps, and deployments, on target endpoints that their role should not permit. This could potentially lead to lateral movement if sensitive credentials are recovered from Kubernetes secrets. **Recommendations** Update portainer-ce to version 2.33.8. Update portainer-ce-agent to version 2.33.8. Restrict Kubernetes endpoint access by removing access for users who do not require it. Audit Kubernetes RBAC to ensure the service account used by Portainer follows the principle of least privilege.

**Name of the Vulnerable Software and Affected Versions** Portainer Community Edition versions prior to 2.39.0 **Description** The backup restore feature accepts a `.tar.gz` archive and extracts it to a target directory on the server. The extraction function `ExtractTarGz()` in `api/archive/targz.go` constructs output paths using `filepath.Clean(filepath.Join(outputDirPath, header.Name))`, which fails to prevent directory traversal. A crafted archive containing entries such as `../../etc/cron.d/evil` can resolve to paths outside the extraction root, allowing an attacker with administrator access to write files to arbitrary locations on the server filesystem. This can lead to arbitrary file writes at any path accessible to the Portainer process and potential host persistence by writing to cron directories, SSH authorized key files, or executable paths. **Recommendations** Update to version 2.39.0 or later. Update to version 2.33.8 for those using the 2.33.x LTS branch. Only restore archives from trusted sources and avoid archives from untrusted parties or unencrypted channels. Use backup encryption to ensure that only those with the correct passphrase can provide a valid archive for extraction.

**Name of the Vulnerable Software and Affected Versions** Langflow versions prior to 1.9.0 **Description** Langflow is a tool for building and deploying AI-powered agents and workflows. The `delete api key route()` endpoint, which accepts the `api key id` path parameter, performs only a generic authentication check. The `delete api key()` function does not verify if the API key belongs to the current user before deleting it. This allows an authenticated attacker to enumerate and delete API keys belonging to other users by guessing or discovering their API key IDs, potentially leading to account takeover, denial of service, and disruption of integrations. The vulnerable code is located in src/backend/base/langflow/api/v1/api key.py lines 44-53. The `delete api key()` function in crud.py lines 44-49 retrieves the API key by ID and deletes it without checking ownership. **Recommendations** Modify the `delete api key` endpoint and function: Pass `current user` to the `delete` function. In `delete api key()`, verify `api key.user id == current user.id` before deletion. Raise a 403 Forbidden error if the user does not own the key.

**Name of the Vulnerable Software and Affected Versions** NocoDB versions prior to 0.301.0 **Description** A Server-Side Request Forgery (SSRF) issue exists in the `uploadViaURL` functionality due to an unprotected `HEAD` request. The initial metadata request executes without validation, allowing limited outbound requests to arbitrary URLs before SSRF controls are applied. The `uploadViaURL()` function uses `axios.head()` to retrieve metadata without SSRF filtering. This request is performed before SSRF protections are enforced. The impact is limited as only `HEAD` requests are affected, and no direct exfiltration of response data occurs. However, it may allow blind SSRF via outbound `HEAD` requests, limited internal service probing, and interaction with sensitive internal endpoints that respond to `HEAD` requests. The issue does not provide arbitrary data access or full internal network compromise on its own. A proof of concept involves sending a POST request to the `/api/v2/storage/upload-by-url` endpoint with a malicious URL in the `url` parameter. **Recommendations** Versions prior to 0.301.0 should be updated to version 0.301.0 or later.