{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/github-advisory/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"id":"CVE-2026-35604"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["filebrowser","authorization-bypass","github-advisory","cve-2026-35604"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eFile Browser versions prior to 2.63.1 contain an authorization bypass vulnerability. Specifically, when an administrator revokes a user\u0026rsquo;s share and download permissions, existing share links created by that user remain fully accessible to unauthenticated users. The vulnerability exists because the public share download handler (\u003ccode\u003ehttp/public.go\u003c/code\u003e) does not re-check the share owner\u0026rsquo;s current permissions when serving shared files. This can lead to unauthorized data access and a false sense of security for administrators who believe that revoking permissions immediately terminates access to shared resources. The issue was verified against version 2.62.2 (commit 860c19d).\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn administrator creates a user account with Share and Download permissions.\u003c/li\u003e\n\u003cli\u003eThe user logs in and creates a share link for a file (e.g., \u003ccode\u003esecret.txt\u003c/code\u003e). The system generates a hash (e.g., \u003ccode\u003efB4Qwtsn\u003c/code\u003e) associated with the share.\u003c/li\u003e\n\u003cli\u003eAn unauthenticated user accesses the file via the share link (e.g., \u003ccode\u003e/api/public/dl/fB4Qwtsn\u003c/code\u003e), successfully downloading the content.\u003c/li\u003e\n\u003cli\u003eThe administrator revokes the user\u0026rsquo;s Share and Download permissions via the API, modifying the user\u0026rsquo;s record in the system.\u003c/li\u003e\n\u003cli\u003eThe revoked user attempts to create a new share link and is correctly denied access (403 Forbidden).\u003c/li\u003e\n\u003cli\u003eAn unauthenticated user attempts to access the file using the previously created share link (e.g., \u003ccode\u003e/api/public/dl/fB4Qwtsn\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe system retrieves the share link information but fails to validate if the original user still possesses Share and Download permissions.\u003c/li\u003e\n\u003cli\u003eThe system serves the file, bypassing the intended authorization restrictions and granting unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe vulnerability allows unauthorized access to files shared through File Browser, even after an administrator has revoked the share creator\u0026rsquo;s permissions. This can result in data breaches, as users who should no longer have access to shared resources can still retrieve them via existing share links. The administrator may believe that revoking permissions immediately stops all sharing, leading to a false sense of security. This is particularly impactful in environments where sensitive data is shared via File Browser and access control is critical.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade File Browser to version 2.63.1 or later to patch CVE-2026-35604.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for access to \u003ccode\u003e/api/public/dl/*\u003c/code\u003e endpoints (logsource: webserver, product: linux/windows) after revoking user permissions; correlate with user permission changes.\u003c/li\u003e\n\u003cli\u003eImplement the suggested fix by adding permission re-validation in \u003ccode\u003ewithHashFile\u003c/code\u003e as described in the advisory.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-08T00:04:59Z","date_published":"2026-04-08T00:04:59Z","id":"/briefs/2026-04-filebrowser-share-bypass/","summary":"File Browser share links remain accessible after Share/Download permissions are revoked, allowing continued access to shared files even after an administrator revokes the user's permissions.","title":"File Browser Share Links Accessible After Permission Revocation","url":"https://feed.craftedsignal.io/briefs/2026-04-filebrowser-share-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Monetr"],"_cs_severities":["medium"],"_cs_tags":["ssrf","monitr","github-advisory"],"_cs_type":"advisory","_cs_vendors":["Monetr"],"content_html":"\u003cp\u003eA server-side request forgery (SSRF) vulnerability was identified in the Lunch Flow integration of Monetr, affecting self-hosted instances. This vulnerability allows any authenticated user to cause the Monetr server to issue HTTP GET requests to arbitrary URLs, with the response body from non-200 upstream responses reflected back in the API error message. The URL validator on the \u003ccode\u003ePOST /api/lunch_flow/link\u003c/code\u003e endpoint lacked sufficient filtering, failing to block loopback, RFC1918, link-local, or cloud-provider metadata addresses. This allows attackers to potentially access internal resources or cloud instance metadata. The vulnerability was addressed in Monetr version 1.12.5. The hosted \u003ccode\u003emy.monetr.app\u003c/code\u003e service is not affected because \u003ccode\u003eLunchFlow.Enabled\u003c/code\u003e is set to \u003ccode\u003efalse\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker registers an account on a vulnerable self-hosted Monetr instance where public sign-up is enabled (\u003ccode\u003eAllowSignUp=true\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Monetr instance.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious \u003ccode\u003ePOST\u003c/code\u003e request to the \u003ccode\u003e/api/lunch_flow/link\u003c/code\u003e endpoint, providing a URL pointing to an internal resource, such as a cloud metadata endpoint (e.g., \u003ccode\u003ehttp://169.254.169.254/latest/meta-data/\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe Monetr server, due to insufficient URL validation, accepts the malicious URL.\u003c/li\u003e\n\u003cli\u003eThe Monetr server issues an HTTP GET request to the attacker-supplied URL.\u003c/li\u003e\n\u003cli\u003eThe external service or internal resource responds to the Monetr server.\u003c/li\u003e\n\u003cli\u003eIf the response is not a 200 OK, the Monetr server reflects the response body in the API error message within the JSON response to the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker observes the reflected response body, potentially revealing sensitive information like cloud instance metadata or internal service details.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SSRF vulnerability can lead to the exposure of sensitive information, such as cloud instance metadata (e.g., AWS EC2 IMDS). This could allow an attacker to gain unauthorized access to other cloud resources or internal systems. The vulnerable instances are self-hosted Monetr deployments running the default configuration with \u003ccode\u003eLunchFlow.Enabled=true\u003c/code\u003e and \u003ccode\u003eAllowSignUp=true\u003c/code\u003e. An attacker could also cause a denial-of-service by providing a URL that returns a very large response body, exhausting the server\u0026rsquo;s memory.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Monetr version \u003ccode\u003ev1.12.5\u003c/code\u003e or later to patch the SSRF vulnerability. This version introduces a new config field \u003ccode\u003eLunchFlow.AllowedApiUrls\u003c/code\u003e and caps response body reads at 10 MiB.\u003c/li\u003e\n\u003cli\u003eFor operators who cannot upgrade immediately, set \u003ccode\u003eMONETR_ALLOW_SIGN_UP=false\u003c/code\u003e to disable public sign-up, limiting access to the vulnerable endpoint to trusted users.\u003c/li\u003e\n\u003cli\u003eAlternatively, disable Lunch Flow entirely by setting \u003ccode\u003elunchFlow.enabled: false\u003c/code\u003e in your config file. This will cause the vulnerable endpoints to return 404.\u003c/li\u003e\n\u003cli\u003eImplement network-level egress restrictions to limit outbound HTTP traffic from the Monetr pod/container to only \u003ccode\u003elunchflow.app\u003c/code\u003e (or other legitimate Lunch Flow hosts), mitigating the SSRF primitive.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T12:00:00Z","date_published":"2024-05-02T12:00:00Z","id":"/briefs/2024-05-monetr-ssrf/","summary":"A server-side request forgery (SSRF) vulnerability in Monetr's Lunch Flow integration allows authenticated users on self-hosted instances to send HTTP GET requests to arbitrary URLs, potentially exposing sensitive information.","title":"Monetr Lunch Flow SSRF Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-05-monetr-ssrf/"}],"language":"en","title":"CraftedSignal Threat Feed — Github-Advisory","version":"https://jsonfeed.org/version/1.1"}