{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/authentication/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["sentry","Sentry SaaS"],"_cs_severities":["medium"],"_cs_tags":["authentication","saml","sso","account takeover","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Sentry"],"content_html":"\u003cp\u003eA critical vulnerability, CVE-2026-42354, has been identified in the SAML Single Sign-On (SSO) implementation of Sentry, potentially allowing an attacker to compromise user accounts. This vulnerability stems from improper authentication during the SAML SSO process, leading to the possibility of user identity linking. The vulnerability affects Sentry versions 21.12.0 up to and including 26.4.0. To exploit this vulnerability, an attacker requires a malicious SAML Identity Provider and access to another organization within the same Sentry instance, coupled with knowledge of the victim\u0026rsquo;s email address. This attack vector poses a significant risk to self-hosted Sentry instances that are configured with multiple organizations (SENTRY_SINGLE_ORGANIZATION = False), where a malicious user possesses the necessary permissions to modify SSO settings for a different organization. Sentry SaaS has already been patched in April.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains access to a Sentry instance that has multiple organizations configured.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains permissions to modify the SAML SSO settings of at least one organization within the Sentry instance.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious SAML Identity Provider (IdP) designed to inject or manipulate user identity attributes.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the malicious SAML IdP to initiate a single sign-on (SSO) process to a Sentry organization they control.\u003c/li\u003e\n\u003cli\u003eThe attacker provides the email address of the targeted victim, linking the victim\u0026rsquo;s identity in the Sentry instance to the malicious SAML IdP.\u003c/li\u003e\n\u003cli\u003eThe victim attempts to log in to their Sentry account through SAML SSO.\u003c/li\u003e\n\u003cli\u003eDue to the vulnerability, Sentry incorrectly authenticates the victim based on the attributes provided by the attacker\u0026rsquo;s malicious SAML IdP.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully takes over the victim\u0026rsquo;s account, gaining access to sensitive data and functionalities associated with the victim\u0026rsquo;s privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability can lead to complete account takeover, resulting in unauthorized access to sensitive project data, configuration settings, and potentially even administrative privileges within the Sentry instance. This poses a substantial risk to organizations using vulnerable Sentry versions, as attackers could exfiltrate sensitive information, modify configurations, or disrupt services. The impact is particularly severe for self-hosted Sentry instances with multiple organizations, where a single compromised account could lead to broader access across the entire platform.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade self-hosted Sentry instances to version 26.4.1 or higher to patch CVE-2026-42354.\u003c/li\u003e\n\u003cli\u003eEnable user account-based two-factor authentication (2FA) for all Sentry accounts as a preventative measure, as mentioned in the Workarounds section.\u003c/li\u003e\n\u003cli\u003eMonitor Sentry audit logs for any unauthorized changes to SAML SSO configurations, particularly within multi-organization setups, to detect potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eReview and restrict permissions for modifying SSO settings across all organizations to minimize the attack surface, as described in the Overview.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-30T20:45:20Z","date_published":"2026-04-30T20:45:20Z","id":"/briefs/2026-05-sentry-saml-takeover/","summary":"A critical vulnerability (CVE-2026-42354) exists in Sentry's SAML SSO implementation that allows an attacker to take over any user account by using a malicious SAML Identity Provider and another organization on the same Sentry instance, affecting self-hosted users with multiple organizations configured if a malicious user has permissions to modify SSO settings, while Sentry SaaS was patched in April and self-hosted users are advised to upgrade to version 26.4.1 or higher.","title":"Sentry SAML SSO Improper Authentication Allows User Identity Linking","url":"https://feed.craftedsignal.io/briefs/2026-05-sentry-saml-takeover/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["@jupyter-notebook/help-extension","notebook","jupyterlab","@jupyterlab/help-extension","Jupyter Notebook"],"_cs_severities":["high"],"_cs_tags":["xss","jupyter","authentication","account-takeover","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Jupyter","NVIDIA"],"content_html":"\u003cp\u003eA stored Cross-Site Scripting (XSS) vulnerability has been identified in Jupyter Notebook and JupyterLab, impacting versions 7.0.0 through 7.5.5 of Jupyter Notebook and versions up to 4.5.6 of JupyterLab. Discovered by Daniel Teixeira of the NVIDIA AI Red Team, this flaw allows an attacker to craft malicious notebook files containing XSS payloads embedded within the command linker functionality. When a user opens and interacts with these files, the injected script executes, potentially stealing the user\u0026rsquo;s authentication token. Successful exploitation grants the attacker full control over the user\u0026rsquo;s Jupyter account, enabling them to read, modify, and create files, execute arbitrary code via running kernels, and establish shell access through created terminals. This vulnerability poses a significant risk to data confidentiality, integrity, and system availability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker crafts a malicious Jupyter Notebook file containing a stored XSS payload within the command linker functionality.\u003c/li\u003e\n\u003cli\u003eThe attacker distributes the malicious notebook file to a target user (e.g., via email, shared repository, or compromised website).\u003c/li\u003e\n\u003cli\u003eThe victim opens the malicious notebook file in a vulnerable version of Jupyter Notebook or JupyterLab.\u003c/li\u003e\n\u003cli\u003eThe victim interacts with a seemingly legitimate control element within the notebook that is, in fact, part of the XSS payload.\u003c/li\u003e\n\u003cli\u003eThe injected XSS code executes in the victim\u0026rsquo;s browser, stealing their authentication token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen authentication token to authenticate to the Jupyter REST API.\u003c/li\u003e\n\u003cli\u003eThe attacker gains complete control over the victim\u0026rsquo;s Jupyter account.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions, such as reading files, modifying files, executing arbitrary code, or creating terminals for shell access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this XSS vulnerability enables complete account takeover, allowing attackers to read, modify, and create files, access running kernels and execute arbitrary code, and create terminals for shell access within the victim\u0026rsquo;s Jupyter environment. This can lead to data exfiltration, code injection, and potential compromise of sensitive information stored within the Jupyter Notebook environment. Given the widespread use of Jupyter Notebook in data science, machine learning, and research environments, this vulnerability can have far-reaching consequences for individuals and organizations relying on these tools.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately upgrade Jupyter Notebook to version 7.5.6 or later, and JupyterLab to version 4.5.7 or later to patch CVE-2026-40171.\u003c/li\u003e\n\u003cli\u003eApply the workaround to disable the help extension via CLI as specified in the advisory to mitigate the vulnerability until patching is possible.\u003c/li\u003e\n\u003cli\u003eImplement the hardening measure by disabling the command linker functionality via \u003ccode\u003eoverrides.json\u003c/code\u003e to prevent XSS attacks, referencing the configuration details in the advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Jupyter Notebook CommandLinker XSS Attempt\u0026rdquo; to detect potential exploitation attempts based on specific HTTP request characteristics.\u003c/li\u003e\n\u003cli\u003eEducate users about the risks of opening untrusted Jupyter Notebook files and interacting with potentially malicious content.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-30T17:25:47Z","date_published":"2026-04-30T17:25:47Z","id":"/briefs/2024-01-30-jupyter-xss/","summary":"A stored Cross-Site Scripting (XSS) vulnerability in Jupyter Notebook versions 7.0.0 through 7.5.5 and JupyterLab versions up to 4.5.6 allows attackers to steal authentication tokens by tricking users into interacting with malicious notebook files, leading to complete account takeover via the Jupyter REST API.","title":"Jupyter Notebook Authentication Token Theft via CommandLinker XSS","url":"https://feed.craftedsignal.io/briefs/2024-01-30-jupyter-xss/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["admidio"],"_cs_severities":["medium"],"_cs_tags":["saml","signature-bypass","authentication","authorization","web-application"],"_cs_type":"advisory","_cs_vendors":["admidio"],"content_html":"\u003cp\u003eAdmidio, a free web-based content management system for organizations and groups, contains a critical vulnerability in its SAML Single Sign-On (SSO) implementation. The \u003ccode\u003evalidateSignature()\u003c/code\u003e method within the SAMLService class returns error strings upon signature validation failure, rather than throwing exceptions. The calling functions, \u003ccode\u003ehandleSSORequest()\u003c/code\u003e and \u003ccode\u003ehandleSLORequest()\u003c/code\u003e, incorrectly assume that the method throws an exception, and therefore, do not check the return value. This oversight renders the \u003ccode\u003esmc_require_auth_signed\u003c/code\u003e configuration option ineffective, allowing attackers to forge SAML AuthnRequests and LogoutRequests. An attacker can exploit this vulnerability to obtain sensitive user information or cause denial of service by terminating user sessions. This affects Admidio versions 5.0.8 and earlier and requires SAML SSO to be enabled.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious SAML AuthnRequest or LogoutRequest without a valid signature, impersonating a legitimate Service Provider (SP).\u003c/li\u003e\n\u003cli\u003eThe attacker sends the forged SAML request to the Admidio instance via HTTP GET or POST to \u003ccode\u003emodules/sso/index.php\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ereceiveMessage()\u003c/code\u003e function parses the SAML binding directly from the HTTP request, requiring no prior authentication.\u003c/li\u003e\n\u003cli\u003eThe Entity ID is extracted from the forged request\u0026rsquo;s Issuer element, and the corresponding client configuration is loaded.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003evalidateSignature()\u003c/code\u003e function is called, but its return value (indicating signature validity) is discarded.\u003c/li\u003e\n\u003cli\u003eFor AuthnRequests, if the targeted user has an active session (\u003ccode\u003e$gValidLogin\u003c/code\u003e is true), the login form is skipped.\u003c/li\u003e\n\u003cli\u003eAdmidio builds a SAML Response containing the user\u0026rsquo;s attributes (login, name, email, roles) and sends it to the attacker-controlled \u003ccode\u003eAssertionConsumerServiceURL\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eFor LogoutRequests, the user\u0026rsquo;s session is immediately terminated in the database, triggering a cascading single logout across all registered SPs.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability can lead to several critical impacts. The primary impact is the complete bypass of signature enforcement, negating the security benefits of the \u003ccode\u003esmc_require_auth_signed\u003c/code\u003e setting. This can lead to the disclosure of sensitive user attributes, including login name, email, and role memberships, to unauthorized parties by forging SSO requests and redirecting them to attacker-controlled endpoints. Furthermore, attackers can terminate any user\u0026rsquo;s Admidio session by forging SLO requests, potentially causing a denial-of-service condition. This vulnerability affects all Admidio instances with SAML SSO enabled and can potentially impact all users of the system.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the recommended fix in the Admidio codebase to check the return value of \u003ccode\u003evalidateSignature()\u003c/code\u003e and throw an exception on failure, as outlined in the advisory (\u003ca href=\"https://github.com/advisories/GHSA-25cw-98hg-g3cg)\"\u003ehttps://github.com/advisories/GHSA-25cw-98hg-g3cg)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Admidio Forged SAML AuthnRequest Detection\u0026rdquo; to detect potentially malicious SAML AuthnRequests lacking a valid signature via webserver logs.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Admidio Forged SAML LogoutRequest Detection\u0026rdquo; to detect potentially malicious SAML LogoutRequests lacking a valid signature via webserver logs.\u003c/li\u003e\n\u003cli\u003eMonitor webserver logs for requests to \u003ccode\u003e/adm_program/modules/sso/index.php/saml/sso\u003c/code\u003e and \u003ccode\u003e/adm_program/modules/sso/index.php/saml/slo\u003c/code\u003e without proper signature validation to detect potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of Admidio to address CVE-2026-41669.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-29T21:56:13Z","date_published":"2026-04-29T21:56:13Z","id":"/briefs/2026-04-admidio-saml-bypass/","summary":"Admidio's SAML Identity Provider implementation fails to properly validate signatures on SAML AuthnRequests and LogoutRequests, enabling attackers to bypass signature enforcement, potentially disclose user attributes via forged SSO requests, and terminate user sessions via forged SLO requests.","title":"Admidio SAML Signature Validation Bypass Allows Forged AuthnRequests and LogoutRequests","url":"https://feed.craftedsignal.io/briefs/2026-04-admidio-saml-bypass/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.8,"id":"CVE-2026-41404"}],"_cs_exploited":false,"_cs_products":["OpenClaw"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","authentication","cve-2026-41404"],"_cs_type":"advisory","_cs_vendors":["OpenClaw"],"content_html":"\u003cp\u003eOpenClaw before version 2026.3.31 is vulnerable to a privilege escalation flaw within its trusted-proxy authentication mechanism. This vulnerability, identified as CVE-2026-41404, stems from an incomplete scope clearing process. The core issue lies in the ability for attackers to declare operator scopes on clients that are not part of the Control-UI. This leads to a situation where these self-declared scopes are erroneously persisted on authentication paths that bear identity. This allows an attacker to escalate their privileges to operator.admin, effectively gaining administrative control over the OpenClaw instance. This poses a significant risk to the confidentiality, integrity, and availability of systems relying on OpenClaw for authentication and authorization.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies an OpenClaw instance using trusted-proxy authentication mode.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a request to a non-Control-UI client, declaring operator scopes within the authentication header.\u003c/li\u003e\n\u003cli\u003eOpenClaw\u0026rsquo;s incomplete scope clearing mechanism fails to remove the attacker-declared operator scopes.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates through an identity-bearing authentication path.\u003c/li\u003e\n\u003cli\u003eDue to the persisted operator scopes, the attacker is granted elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the escalated operator.admin privileges to perform unauthorized actions. This could include modifying configurations, accessing sensitive data, or disrupting services.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access by creating new administrator accounts.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows an attacker to gain operator.admin privileges within the OpenClaw environment. This can lead to complete control over the affected OpenClaw instance. Consequences include unauthorized access to sensitive data, modification of system configurations, and disruption of services. The severity is compounded by the fact that the vulnerability exists in the authentication mechanism, potentially affecting all users and systems relying on OpenClaw for access control.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade OpenClaw to version 2026.3.31 or later to patch CVE-2026-41404.\u003c/li\u003e\n\u003cli\u003eImplement strict input validation on authentication headers to prevent the declaration of unauthorized scopes.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect OpenClaw Unauthorized Scope Declaration\u003c/code\u003e to monitor for suspicious authentication requests.\u003c/li\u003e\n\u003cli\u003eReview and audit existing OpenClaw configurations to identify and remove any unauthorized operator scopes.\u003c/li\u003e\n\u003cli\u003eMonitor logs for successful logins with unexpected admin privileges.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-29T12:00:00Z","date_published":"2026-04-29T12:00:00Z","id":"/briefs/2026-04-openclaw-privilege-escalation/","summary":"OpenClaw before 2026.3.31 contains an incomplete scope-clearing vulnerability in trusted-proxy authentication mode that allows operator.admin privilege escalation by declaring operator scopes on non-Control-UI clients.","title":"OpenClaw Privilege Escalation via Trusted Proxy Authentication (CVE-2026-41404)","url":"https://feed.craftedsignal.io/briefs/2026-04-openclaw-privilege-escalation/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.1,"id":"CVE-2026-27197"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["sentry","saml","sso","authentication","account-takeover"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA critical vulnerability (CVE-2026-27197) has been identified in the SAML Single Sign-On (SSO) implementation within Sentry, a popular error tracking and performance monitoring platform. This vulnerability allows a malicious actor to potentially take over user accounts by leveraging a rogue SAML Identity Provider (IdP) in conjunction with another organization configured within the same Sentry instance. The attacker needs to know the victim\u0026rsquo;s email address for successful exploitation. This flaw primarily impacts self-hosted Sentry deployments with multiple organizations enabled (SENTRY_SINGLE_ORGANIZATION = False) and where a malicious user possesses the ability to modify SSO settings for another organization. Sentry SaaS was patched on February 18, 2026. Self-hosted users should upgrade to version 26.2.0 or later to remediate this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains access to a Sentry instance that hosts multiple organizations. This could be through compromised credentials or other initial access vectors.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target user\u0026rsquo;s email address within the Sentry instance.\u003c/li\u003e\n\u003cli\u003eThe attacker gains permissions to modify SSO settings for an organization within the Sentry instance.\u003c/li\u003e\n\u003cli\u003eThe attacker configures a malicious SAML Identity Provider (IdP) for the organization they control. This IdP is designed to spoof user identities.\u003c/li\u003e\n\u003cli\u003eThe victim attempts to log in to Sentry via SAML SSO.\u003c/li\u003e\n\u003cli\u003eSentry redirects the victim to the attacker\u0026rsquo;s malicious SAML IdP for authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s malicious SAML IdP asserts the victim\u0026rsquo;s identity (using the known email address) to Sentry, but the assertion is illegitimate and controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eSentry, due to the vulnerability, improperly validates the SAML assertion, allowing the attacker to successfully authenticate as the victim and gain unauthorized access to their account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows an attacker to completely take over a targeted user\u0026rsquo;s Sentry account. This grants the attacker the ability to access sensitive project data, modify configurations, invite/remove team members, and potentially disrupt the entire Sentry instance\u0026rsquo;s operations. The vulnerability affects Sentry versions 21.12.0 up to, but not including, 26.2.0. The number of potential victims depends on the number of vulnerable Sentry instances with multiple organizations configured and the attacker\u0026rsquo;s ability to modify SSO settings.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade self-hosted Sentry instances to version 26.2.0 or later to patch CVE-2026-27197.\u003c/li\u003e\n\u003cli\u003eEnable two-factor authentication (2FA) on all Sentry accounts. Users can manage this in Account Settings \u0026gt; Security, as mentioned in the \u003ca href=\"https://sentry.zendesk.com/hc/en-us/articles/46773315774235-How-do-I-enable-two-factor-authentication-2FA-on-my-Sentry-account\"\u003ehelpdesk article\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor Sentry logs for unusual SSO configuration changes, specifically modifications to SAML Identity Provider settings. Deploy a rule that detects modifications to the \u003ccode\u003eSENTRY_SINGLE_ORGANIZATION\u003c/code\u003e setting, as this is a prerequisite for exploitation.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003eDetect Suspicious SAML Authentication\u003c/code\u003e to identify potential unauthorized SAML authentication attempts based on unusual IP addresses or user agents.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-18T12:00:00Z","date_published":"2026-04-18T12:00:00Z","id":"/briefs/2026-04-sentry-saml-sso-takeover/","summary":"A critical vulnerability in Sentry's SAML SSO implementation allows account takeover by exploiting improper authentication when multiple organizations are configured, affecting versions 21.12.0 to 26.2.0 and requiring a malicious SAML Identity Provider and knowledge of the victim's email address.","title":"Sentry SAML SSO Improper Authentication Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-04-sentry-saml-sso-takeover/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.1,"id":"CVE-2026-40162"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve-2026-40162","file-write","authentication"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eBugSink, a self-hosted error tracking tool, is susceptible to an authenticated file write vulnerability in version 2.1.0. This vulnerability, identified as CVE-2026-40162, allows an attacker with a valid authentication token to write attacker-controlled content to a filesystem location writable by the BugSink process. The flaw resides in the artifact bundle assembly flow. Successful exploitation could allow an attacker to achieve arbitrary code execution on the BugSink server or compromise sensitive data. Organizations using BugSink 2.1.0 are vulnerable and should upgrade to version 2.1.1 to remediate the issue. This poses a risk to the confidentiality, integrity, and availability of the BugSink server and the data it manages.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker obtains valid authentication token for BugSink 2.1.0 through legitimate means (e.g., compromised user credentials) or by exploiting another vulnerability.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious artifact bundle containing attacker-controlled content.\u003c/li\u003e\n\u003cli\u003eAttacker sends a request to the BugSink server to assemble an artifact bundle, including the malicious content, using the valid authentication token.\u003c/li\u003e\n\u003cli\u003eBugSink server, running version 2.1.0, processes the request without proper validation of the artifact bundle contents.\u003c/li\u003e\n\u003cli\u003eThe server writes the attacker-controlled content to a filesystem location writable by the BugSink process. This could overwrite existing files or create new ones.\u003c/li\u003e\n\u003cli\u003eIf the attacker overwrites critical configuration files or injects malicious code into executable files, they may achieve code execution.\u003c/li\u003e\n\u003cli\u003eAttacker establishes a reverse shell or uses other methods to gain remote access to the BugSink server.\u003c/li\u003e\n\u003cli\u003eAttacker performs further actions such as data exfiltration, lateral movement, or denial of service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability could allow an attacker to achieve arbitrary code execution on the BugSink server, potentially leading to complete system compromise. Attackers could exfiltrate sensitive data, modify existing data, or use the compromised server to launch attacks against other systems. The vulnerability affects any BugSink 2.1.0 installation with a user who has a valid authentication token, and it requires a upgrade to version 2.1.1 to remediate.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade BugSink to version 2.1.1 immediately to patch CVE-2026-40162, as per the vendor\u0026rsquo;s advisory.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for unusual POST requests to the artifact bundle assembly endpoints, which may indicate exploitation attempts. Deploy the Sigma rule \u003ccode\u003eDetect Suspicious BugSink File Write\u003c/code\u003e to your SIEM.\u003c/li\u003e\n\u003cli\u003eImplement strict input validation and sanitization for all user-supplied data processed by BugSink, to prevent similar file write vulnerabilities in the future.\u003c/li\u003e\n\u003cli\u003eReview and enforce least privilege access controls on the BugSink server, limiting the write access of the BugSink process to only the necessary files and directories.\u003c/li\u003e\n\u003cli\u003eMonitor file system events for unexpected file creations or modifications within the BugSink installation directory.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T12:00:00Z","date_published":"2026-04-11T12:00:00Z","id":"/briefs/2026-04-bugsink-file-write/","summary":"BugSink 2.1.0 is vulnerable to an authenticated file write vulnerability (CVE-2026-40162) allowing an attacker with a valid authentication token to write arbitrary content to the filesystem, potentially leading to code execution or data compromise.","title":"BugSink Authenticated File Write Vulnerability (CVE-2026-40162)","url":"https://feed.craftedsignal.io/briefs/2026-04-bugsink-file-write/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kcp","kubernetes","cache","authentication","authorization","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe kcp (Kubernetes Cluster Platform) cache server, responsible for replicating resources, is directly exposed by the root shard without any authentication or authorization checks. This vulnerability allows anyone with network access to the root shard to read replicated resources and potentially write to the cache server, creating a race condition. The lack of authentication in the preHandlerChainMux, specifically identified in \u003ccode\u003epkg/server/config.go\u003c/code\u003e at line 514-518, causes the cache server to be proxied before authentication or authorization can take place. This impacts kcp versions prior to v0.29.3 and between v0.30.0 and v0.30.3. This vulnerability allows unauthorized access to sensitive information, including RBAC rules, cluster topology, API surfaces, admission control policies, and tenancy configurations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains network access to the kcp root shard, typically through exposed ports or external URLs.\u003c/li\u003e\n\u003cli\u003eAttacker crafts an HTTP request targeting the \u003ccode\u003e/services/cache/*\u003c/code\u003e endpoint without any authentication headers.\u003c/li\u003e\n\u003cli\u003eThe request bypasses authentication and authorization checks due to the flawed preHandlerChainMux configuration.\u003c/li\u003e\n\u003cli\u003eThe attacker reads replicated resources from the cache, such as clusterroles, clusterrolebindings, logicalclusters, apiexports, and validatingwebhookconfigurations.\u003c/li\u003e\n\u003cli\u003e(Optional) The attacker attempts to inject a malicious ClusterRole and ClusterRoleBinding via a POST request to the cache server.\u003c/li\u003e\n\u003cli\u003eThe cache etcd watch fires, notifying the authorization informer and replication controller in parallel.\u003c/li\u003e\n\u003cli\u003eThe authorization informer updates its in-memory store, briefly granting the attacker the injected RBAC rules.\u003c/li\u003e\n\u003cli\u003eThe replication controller eventually reconciles and deletes the injected object, but a small window of opportunity exists for privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows unauthorized access to critical cluster information, potentially exposing RBAC configurations, API endpoints, and internal infrastructure details. An attacker can read replicated resources, including cluster roles, cluster role bindings, logical clusters, shards, API exports, API resource schemas, mutating webhook configurations, validating webhook configurations, validating admission policies, and workspace types. While injected objects are quickly cleaned up, a brief race condition allows for temporary privilege escalation. This affects kcp deployments where the root shard is network-reachable by untrusted clients, including Helm chart deployments, Operator deployments with external URLs set, and deployments with a reachable \u0026ndash;shard-external-url.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement network-level access control to restrict access to the \u003ccode\u003e/services/cache/*\u003c/code\u003e paths at the load balancer, reverse proxy, or firewall level as described in the \u003cstrong\u003eWorkarounds\u003c/strong\u003e section of the advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the cache server separately with its own kubeconfig (\u003ccode\u003e--cache-server-kubeconfig\u003c/code\u003e) and restrict network access to it, mitigating direct exposure to the root shard as per the \u003cstrong\u003eWorkarounds\u003c/strong\u003e section.\u003c/li\u003e\n\u003cli\u003eUpgrade to kcp version v0.29.3 or v0.30.3 or later to patch the vulnerability as per \u003cstrong\u003eCVE-2026-39429\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-08T15:04:22Z","date_published":"2026-04-08T15:04:22Z","id":"/briefs/2026-04-kcp-cache-unauth/","summary":"The kcp cache server is exposed without authentication, allowing unauthorized read access to sensitive data and a race condition for write access that could lead to temporary privilege escalation.","title":"Unauthenticated Access to kcp Cache Server","url":"https://feed.craftedsignal.io/briefs/2026-04-kcp-cache-unauth/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-33540"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["CVE-2026-33540","authentication","redirection","container"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe distribution toolkit, used for managing container content, is vulnerable to an authentication redirection attack in versions prior to 3.1.0 when operating in pull-through cache mode. The vulnerability, identified as CVE-2026-33540, stems from the toolkit\u0026rsquo;s method of discovering token authentication endpoints. It parses WWW-Authenticate challenges from upstream registries without properly validating the realm URL against the upstream registry host. This allows an attacker controlling the upstream registry or positioned as a Man-in-the-Middle to redirect authentication requests to an attacker-controlled realm URL. This results in distribution sending the configured upstream credentials via basic authentication to the malicious URL. Organizations using affected versions of the distribution toolkit are vulnerable to credential compromise if the toolkit interacts with a malicious or compromised upstream registry. Upgrading to version 3.1.0 or later resolves this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains control of or MitM position to an upstream registry server used by the distribution toolkit.\u003c/li\u003e\n\u003cli\u003eDistribution toolkit attempts to pull an image from the upstream registry.\u003c/li\u003e\n\u003cli\u003eAttacker\u0026rsquo;s registry responds with a WWW-Authenticate header, specifying a Bearer authentication scheme and an attacker-controlled realm URL.\u003c/li\u003e\n\u003cli\u003eThe distribution toolkit, vulnerable to CVE-2026-33540, parses the WWW-Authenticate header but fails to validate the realm URL against the legitimate upstream registry.\u003c/li\u003e\n\u003cli\u003eThe distribution toolkit initiates a basic authentication request to the attacker-controlled realm URL, sending the configured upstream credentials (username and password).\u003c/li\u003e\n\u003cli\u003eThe attacker captures the credentials sent via basic authentication.\u003c/li\u003e\n\u003cli\u003eAttacker uses the compromised credentials to gain unauthorized access to the legitimate upstream registry.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-33540 allows an attacker to steal credentials used by the distribution toolkit to authenticate to an upstream registry. This can lead to unauthorized access to container images stored in the upstream registry, potentially resulting in supply chain attacks, data breaches, or the deployment of malicious container images. The severity of the impact depends on the permissions associated with the compromised credentials and the sensitivity of the data stored in the upstream registry.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade the distribution toolkit to version 3.1.0 or later to remediate CVE-2026-33540.\u003c/li\u003e\n\u003cli\u003eImplement network monitoring to detect basic authentication attempts originating from the distribution toolkit to unusual or unexpected destinations (see rule: \u0026ldquo;Detect Basic Authentication to Non-Standard Ports\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for connections to unusual or suspicious realm URLs returned in WWW-Authenticate headers from container registries (see rule: \u0026ldquo;Detect Authentication Redirection\u0026rdquo;).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T15:17:10Z","date_published":"2026-04-06T15:17:10Z","id":"/briefs/2026-04-distribution-auth-redirect/","summary":"A vulnerability in the distribution toolkit prior to 3.1.0 allows a malicious upstream registry or man-in-the-middle attacker to redirect authentication requests, potentially exposing upstream credentials.","title":"Distribution Toolkit Authentication Redirection Vulnerability (CVE-2026-33540)","url":"https://feed.craftedsignal.io/briefs/2026-04-distribution-auth-redirect/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2025-59420"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["jwt","vulnerability","authentication","authorization"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe \u003ccode\u003efast-jwt\u003c/code\u003e library, versions 6.1.0 and below, exhibits a critical vulnerability where it does not properly validate the \u003ccode\u003ecrit\u003c/code\u003e (Critical) Header Parameter as defined in RFC 7515. This oversight allows JWS tokens containing unrecognized extensions within the \u003ccode\u003ecrit\u003c/code\u003e array to be accepted instead of being rejected as mandated by the RFC. The vulnerability, identified as CVE-2026-35042, can lead to significant security implications, especially in environments utilizing a mix of JWT verification libraries. This flaw enables attackers to potentially bypass security policies and token binding protections, creating a window for unauthorized access or actions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker crafts a JWT with a \u003ccode\u003ecrit\u003c/code\u003e header containing an extension (e.g., \u0026ldquo;x-custom-policy\u0026rdquo;) that \u003ccode\u003efast-jwt\u003c/code\u003e does not support.\u003c/li\u003e\n\u003cli\u003eThe attacker includes this unsupported extension header (e.g., \u003ccode\u003e\u0026quot;x-custom-policy\u0026quot;: \u0026quot;require-mfa\u0026quot;\u003c/code\u003e) in the JWT header.\u003c/li\u003e\n\u003cli\u003eThe attacker signs the JWT using a valid signing key and algorithm (e.g., HS256).\u003c/li\u003e\n\u003cli\u003eThe attacker presents the crafted JWT to a system or application using the vulnerable \u003ccode\u003efast-jwt\u003c/code\u003e library for verification.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003efast-jwt\u003c/code\u003e library incorrectly accepts the token without validating the \u003ccode\u003ecrit\u003c/code\u003e header extensions.\u003c/li\u003e\n\u003cli\u003eThe application logic proceeds based on the accepted (but invalid) JWT, potentially granting unauthorized access or privileges.\u003c/li\u003e\n\u003cli\u003eIf other JWT libraries are used in the same environment that \u003cem\u003edo\u003c/em\u003e properly validate the \u003ccode\u003ecrit\u003c/code\u003e header, a \u0026ldquo;split-brain\u0026rdquo; verification scenario can occur, with some systems rejecting the token while others accept it.\u003c/li\u003e\n\u003cli\u003eThe ultimate objective is to bypass intended security policies, such as multi-factor authentication or token binding requirements, gaining unauthorized access or control.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability (CVE-2026-35042) can lead to several critical consequences. First, in mixed-library environments, it creates a split-brain verification scenario where different systems interpret the same token differently. Second, it allows attackers to bypass security policies enforced through the \u003ccode\u003ecrit\u003c/code\u003e header, such as mandatory multi-factor authentication. Finally, it can circumvent token binding mechanisms (RFC 7800 \u003ccode\u003ecnf\u003c/code\u003e confirmation), weakening overall authentication security. The full impact analysis is described in CVE-2025-59420. This vulnerability affects applications using \u003ccode\u003efast-jwt\u003c/code\u003e version 6.1.0 and earlier.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade the \u003ccode\u003efast-jwt\u003c/code\u003e library to a version greater than 6.1.0 to remediate CVE-2026-35042.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect fast-jwt crit Header Bypass Attempt\u0026rdquo; to identify attempts to exploit this vulnerability in your environment.\u003c/li\u003e\n\u003cli\u003eIf a mixed-library JWT verification environment exists, evaluate and standardize on a single JWT library that correctly handles the \u003ccode\u003ecrit\u003c/code\u003e header parameter.\u003c/li\u003e\n\u003cli\u003eReview existing JWT usage to identify instances where the \u003ccode\u003ecrit\u003c/code\u003e header is used for security policy enforcement and ensure that appropriate validation is in place.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T22:01:25Z","date_published":"2026-04-03T22:01:25Z","id":"/briefs/2026-04-fast-jwt-crit-validation-bypass/","summary":"The fast-jwt library fails to validate the 'crit' header, allowing attackers to bypass security policies and potentially achieve split-brain verification in mixed-library environments.","title":"fast-jwt Library Vulnerability Allows crit Header Validation Bypass","url":"https://feed.craftedsignal.io/briefs/2026-04-fast-jwt-crit-validation-bypass/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.4,"id":"CVE-2026-35561"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["amazon","athena","odbc","authentication","hijacking","cve-2026-35561"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-35561 identifies a critical vulnerability within the Amazon Athena ODBC driver, specifically affecting versions prior to 2.1.0.0. This flaw resides in the browser-based authentication components, where insufficient security controls could enable attackers to intercept or hijack legitimate authentication sessions. The vulnerability stems from inadequate protection mechanisms within the authentication flows, leaving users susceptible to unauthorized access. To mitigate this risk, Amazon recommends that users immediately upgrade to version 2.1.0.0 of the Athena ODBC driver. The affected driver is used on Windows, Linux, and macOS operating systems to connect to the Amazon Athena service. Successful exploitation could lead to unauthorized data access and manipulation within the victim\u0026rsquo;s Athena environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a target using a vulnerable version of the Amazon Athena ODBC driver (prior to 2.1.0.0).\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts the browser-based authentication flow initiated by the ODBC driver. This could involve techniques such as man-in-the-middle attacks or exploiting vulnerabilities in the underlying browser or network infrastructure.\u003c/li\u003e\n\u003cli\u003eDue to insufficient security controls, the attacker is able to extract or manipulate the authentication credentials or session tokens.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to authenticate to Amazon Athena as the compromised user.\u003c/li\u003e\n\u003cli\u003eThe attacker queries sensitive data stored within Athena databases.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies data within the Athena environment, potentially injecting malicious code or altering existing records.\u003c/li\u003e\n\u003cli\u003eThe attacker pivots to other AWS services accessible with the compromised account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-35561 can result in unauthorized access to sensitive data stored in Amazon Athena. The impact includes potential data breaches, data manipulation, and lateral movement to other AWS services if the compromised user has sufficient permissions. Given that Athena is often used to analyze large datasets, the compromise could expose significant amounts of business-critical information. The CVSS score of 7.4 highlights the severity of this vulnerability, particularly the high confidentiality and integrity impact.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately upgrade the Amazon Athena ODBC driver to version 2.1.0.0 or later across all affected systems to remediate CVE-2026-35561.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious authentication patterns related to Amazon Athena, using a network intrusion detection system (IDS) or firewall logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts accessing Amazon Athena to mitigate the impact of compromised credentials.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Suspicious Athena ODBC Driver User Agent\u0026rdquo; to identify potentially vulnerable or malicious driver versions in use.\u003c/li\u003e\n\u003cli\u003eReview and enforce least privilege access controls for all IAM roles and users accessing Amazon Athena to limit the potential impact of unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T21:17:12Z","date_published":"2026-04-03T21:17:12Z","id":"/briefs/2026-04-amazon-athena-auth-bypass/","summary":"CVE-2026-35561 describes an insufficient authentication security control vulnerability in the browser-based authentication components of the Amazon Athena ODBC driver before version 2.1.0.0, potentially allowing a threat actor to intercept or hijack authentication sessions.","title":"Amazon Athena ODBC Driver Authentication Bypass Vulnerability (CVE-2026-35561)","url":"https://feed.craftedsignal.io/briefs/2026-04-amazon-athena-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["authentication","2fa","bypass","better-auth"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eBetter Auth versions prior to 1.4.9 contain a critical vulnerability that can lead to two-factor authentication (2FA) bypass. The vulnerability arises when the \u003ccode\u003esession.cookieCache\u003c/code\u003e is enabled. In this configuration, the initial session created during the login process can be prematurely cached before the 2FA verification is completed. Consequently, subsequent session lookups might use this cached session, circumventing the necessary 2FA check. This issue allows an attacker who possesses valid primary credentials to gain unauthorized access to protected application routes without completing the mandated second authentication factor. Any application leveraging \u003ccode\u003ebetter-auth\u003c/code\u003e with 2FA and session cookie caching enabled is potentially vulnerable.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eUser attempts to log in with valid username and password.\u003c/li\u003e\n\u003cli\u003eThe application, running a vulnerable version of \u003ccode\u003ebetter-auth\u003c/code\u003e with \u003ccode\u003esession.cookieCache\u003c/code\u003e enabled, creates a session.\u003c/li\u003e\n\u003cli\u003eThe session is cached due to the \u003ccode\u003esession.cookieCache\u003c/code\u003e setting, \u003cem\u003ebefore\u003c/em\u003e the 2FA challenge is presented.\u003c/li\u003e\n\u003cli\u003eThe user is prompted for their second factor (e.g., TOTP code).\u003c/li\u003e\n\u003cli\u003eInstead of providing the 2FA code, the attacker intercepts or reuses the cached session cookie.\u003c/li\u003e\n\u003cli\u003eThe attacker presents the cached session cookie to the application.\u003c/li\u003e\n\u003cli\u003eThe application retrieves the cached session, which it prematurely considers valid.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to protected resources without completing 2FA.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows attackers with valid usernames and passwords to bypass two-factor authentication, gaining unauthorized access to sensitive application resources. The number of affected applications is unknown, but all applications using \u003ccode\u003ebetter-auth\u003c/code\u003e with 2FA and session caching are potentially at risk. A successful attack could lead to data breaches, account takeovers, and other serious security incidents.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to \u003ccode\u003ebetter-auth\u003c/code\u003e version 1.4.9 or later to patch the vulnerability.\u003c/li\u003e\n\u003cli\u003eDisable \u003ccode\u003esession.cookieCache\u003c/code\u003e when using two-factor authentication as a temporary mitigation.\u003c/li\u003e\n\u003cli\u003eIf disabling \u003ccode\u003esession.cookieCache\u003c/code\u003e is not feasible, implement server-side checks to ensure 2FA is completed before granting full session validity (requires code modification).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T03:29:59Z","date_published":"2026-04-03T03:29:59Z","id":"/briefs/2024-01-02-better-auth-2fa-bypass/","summary":"Better Auth versions prior to 1.4.9 have a critical two-factor authentication bypass vulnerability; when session.cookieCache is enabled, the initial sign-in session may be improperly cached, allowing attackers with valid credentials to bypass 2FA.","title":"Better Auth Two-Factor Authentication Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-02-better-auth-2fa-bypass/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.6,"id":"CVE-2026-32173"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["azure","sre","authentication","information-disclosure"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-32173 identifies a critical improper authentication vulnerability within the Azure SRE Agent. This flaw enables an unauthenticated attacker to potentially gain unauthorized access to sensitive information traversing the network. The vulnerability was published on 2026-04-02 and has a CVSS v3.1 score of 8.6, indicating a high severity.  The vulnerability affects systems utilizing the Azure SRE Agent and could expose confidential data to unauthorized parties. Successful exploitation would allow an attacker to eavesdrop on network communications and extract sensitive information handled by the agent. Defenders should prioritize patching and monitoring systems running the Azure SRE Agent.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker identifies a vulnerable Azure SRE Agent instance.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious network request targeting the vulnerable endpoint on the agent.\u003c/li\u003e\n\u003cli\u003eDue to the improper authentication, the agent processes the request without proper authorization.\u003c/li\u003e\n\u003cli\u003eThe agent retrieves sensitive information that it is normally restricted from disclosing.\u003c/li\u003e\n\u003cli\u003eThe agent transmits the sensitive information back to the attacker over the network.\u003c/li\u003e\n\u003cli\u003eThe attacker captures and analyzes the disclosed data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the disclosed information for further reconnaissance or exploitation activities within the Azure environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-32173 allows unauthorized disclosure of sensitive information handled by the Azure SRE Agent. This can lead to data breaches, credential compromise, and lateral movement within the Azure environment. The extent of the impact depends on the type and volume of information the SRE Agent handles. Organizations using affected versions of the agent are at risk of exposing internal configurations, credentials, or other confidential data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch provided by Microsoft for CVE-2026-32173 as soon as possible to remediate the vulnerability (\u003ca href=\"https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32173)\"\u003ehttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32173)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious activity targeting Azure SRE Agent endpoints using the \u0026ldquo;Detect Azure SRE Agent Information Disclosure Attempt\u0026rdquo; Sigma rule.\u003c/li\u003e\n\u003cli\u003eReview access controls and network segmentation to limit the blast radius in case of successful exploitation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T00:16:04Z","date_published":"2026-04-03T00:16:04Z","id":"/briefs/2026-04-azure-sre-auth-bypass/","summary":"An improper authentication vulnerability (CVE-2026-32173) in the Azure SRE Agent allows an unauthorized attacker to disclose sensitive information over the network, potentially leading to data breaches or further compromise.","title":"Azure SRE Agent Improper Authentication Vulnerability (CVE-2026-32173)","url":"https://feed.craftedsignal.io/briefs/2026-04-azure-sre-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.3,"id":"CVE-2026-3872"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["keycloak","redirect-uri-bypass","cve-2026-3872","authentication","authorization"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-3872 is a security flaw found in Keycloak, a popular open-source identity and access management solution. This vulnerability allows a malicious actor who has control over another path on the same web server hosting Keycloak to circumvent the allowed path restrictions in redirect URIs that use a wildcard. By exploiting this weakness, an attacker can potentially redirect a user to a malicious site after authentication, intercept the access token, and gain unauthorized access to the user\u0026rsquo;s resources. The vulnerability could lead to the disclosure of sensitive information and potentially compromise user accounts. This was published on April 2, 2026, and has a CVSS v3.1 score of 7.3.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains control of a path on the same web server hosting the Keycloak instance. This could be achieved through various means, such as exploiting a separate vulnerability in another application hosted on the server.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL that exploits the wildcard redirect URI validation flaw in Keycloak. The crafted URL includes a redirect URI that bypasses the intended restrictions.\u003c/li\u003e\n\u003cli\u003eA legitimate user initiates an authentication request to Keycloak, potentially through a vulnerable application relying on Keycloak for authentication.\u003c/li\u003e\n\u003cli\u003eKeycloak processes the authentication request and, due to the vulnerability, accepts the attacker\u0026rsquo;s crafted redirect URI as valid.\u003c/li\u003e\n\u003cli\u003eKeycloak redirects the user to the attacker-controlled URL after successful authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s server captures the access token from the redirect URI.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen access token to impersonate the user and access protected resources.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to sensitive information or performs actions on behalf of the user, leading to information disclosure or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-3872 can lead to the theft of access tokens, enabling unauthorized access to user accounts and sensitive data. This could result in the compromise of user privacy, financial loss, or reputational damage for organizations relying on affected Keycloak instances. The impact is significant because Keycloak is used across various sectors to secure web applications and APIs.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the security patches or updates provided by Red Hat for Keycloak to address CVE-2026-3872. Refer to the Red Hat advisory linked in the references for specific instructions.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect exploitation attempts of CVE-2026-3872 based on suspicious redirect URIs in web server logs.\u003c/li\u003e\n\u003cli\u003eReview and harden the configuration of redirect URIs in Keycloak, avoiding the use of wildcards where possible and implementing stricter validation rules.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious activity related to redirect URIs, looking for unusual patterns or attempts to access unauthorized resources.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-02T13:16:26Z","date_published":"2026-04-02T13:16:26Z","id":"/briefs/2026-04-keycloak-redirect-bypass/","summary":"CVE-2026-3872 is a vulnerability in Keycloak that allows an attacker controlling a path on the same web server to bypass URI redirect validation using a wildcard, potentially leading to access token theft and information disclosure.","title":"Keycloak Redirect URI Bypass Vulnerability (CVE-2026-3872)","url":"https://feed.craftedsignal.io/briefs/2026-04-keycloak-redirect-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["gitlab","jira","authentication","authorization","cve-2026-2370"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eGitLab has addressed a critical vulnerability, CVE-2026-2370, affecting GitLab CE/EE installations with Jira Connect enabled.  This vulnerability impacts versions 14.3 up to 18.8.7, 18.9 before 18.9.3, and 18.10 before 18.10.1. The vulnerability stems from improper authorization checks, which enable an authenticated user with minimal workspace permissions within Jira to potentially obtain GitLab installation credentials. This, in turn, allows the attacker to impersonate the GitLab application…\u003c/p\u003e\n","date_modified":"2026-03-30T00:16:01Z","date_published":"2026-03-30T00:16:01Z","id":"/briefs/2026-03-gitlab-jira-connect-auth-bypass/","summary":"GitLab CE/EE versions 14.3 before 18.8.7, 18.9 before 18.9.3, and 18.10 before 18.10.1 are vulnerable to improper authorization checks in Jira Connect installations, allowing an authenticated user with minimal workspace permissions to obtain installation credentials and impersonate the GitLab application.","title":"GitLab Jira Connect Authentication Bypass Vulnerability (CVE-2026-2370)","url":"https://feed.craftedsignal.io/briefs/2026-03-gitlab-jira-connect-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kerberos","authentication","security-bypass"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability exists within MIT Kerberos that allows an unauthenticated, remote attacker to bypass security mechanisms. The specific nature of the vulnerability is not detailed in this advisory, but the potential impact is significant due to Kerberos\u0026rsquo; central role in authentication and authorization. The advisory, published by the German BSI (Bundesamt für Sicherheit in der Informationstechnik), highlights the potential for attackers to gain unauthorized access or escalate privileges within a Kerberos-protected environment. Defenders should investigate available patches and mitigations to prevent exploitation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a vulnerable MIT Kerberos implementation.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious request to exploit the Kerberos vulnerability, likely targeting a specific service or protocol weakness.\u003c/li\u003e\n\u003cli\u003eThe malicious request bypasses authentication or authorization checks due to the vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to a Kerberos-protected resource or service.\u003c/li\u003e\n\u003cli\u003eDepending on the exploited vulnerability, the attacker may impersonate a legitimate user or service.\u003c/li\u003e\n\u003cli\u003eThe attacker performs unauthorized actions, such as accessing sensitive data or executing commands.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the Kerberos realm, potentially compromising the entire authentication infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability could lead to widespread unauthorized access and privilege escalation within Kerberos-dependent environments. The number of affected organizations is currently unknown, but the potential impact is significant due to the widespread use of Kerberos for authentication in enterprise networks. A successful attack could allow an attacker to compromise critical systems, steal sensitive data, and disrupt essential services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor Kerberos authentication logs for anomalies indicative of exploitation attempts (see generic rule below).\u003c/li\u003e\n\u003cli\u003eInvestigate and apply any available patches or workarounds released by MIT Kerberos to address the vulnerability.\u003c/li\u003e\n\u003cli\u003eReview and strengthen Kerberos configuration settings to minimize the attack surface.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the impact of a potential Kerberos compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-24T10:16:06Z","date_published":"2026-03-24T10:16:06Z","id":"/briefs/2024-05-mit-kerberos-bypass/","summary":"An anonymous, remote attacker can exploit a vulnerability in MIT Kerberos to bypass security measures.","title":"MIT Kerberos Security Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-05-mit-kerberos-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Bitbucket"],"_cs_severities":["medium"],"_cs_tags":["bitbucket","authentication","brute-force","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting user login failures within Bitbucket environments. Monitoring failed login attempts is crucial as it can indicate various malicious activities, including credential stuffing, brute-force attacks, or attempts to gain unauthorized initial access. The audit logs in Bitbucket record details of these authentication failures, providing valuable data for security monitoring. The rule provided detects these events and can be used for correlation with other security events based on the \u0026ldquo;author.name\u0026rdquo; field for enhanced accuracy and context. Requires \u0026ldquo;Advance\u0026rdquo; log level to receive audit events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access Attempt:\u003c/strong\u003e An attacker attempts to gain initial access to a Bitbucket account using a compromised or guessed username.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Guessing:\u003c/strong\u003e The attacker attempts to guess the user\u0026rsquo;s password through manual attempts or automated tools.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Failure:\u003c/strong\u003e Bitbucket records a \u0026ldquo;User login failed\u0026rdquo; event due to incorrect credentials. The \u003ccode\u003eauditType.category\u003c/code\u003e is Authentication, and \u003ccode\u003eauditType.action\u003c/code\u003e is User login failed.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMultiple Failed Attempts:\u003c/strong\u003e The attacker repeats the login attempts with different password variations or using a list of compromised credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Lockout (Optional):\u003c/strong\u003e Depending on Bitbucket\u0026rsquo;s configuration, repeated failed login attempts may trigger an account lockout.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccessful Login (Potential):\u003c/strong\u003e After multiple attempts, the attacker may eventually guess the correct password or use a valid compromised credential.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation/Persistence (If Successful):\u003c/strong\u003e If successful, the attacker could escalate privileges, establish persistence, or perform other malicious actions within the Bitbucket environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to sensitive code repositories, intellectual property theft, and potential supply chain compromise. Attackers could inject malicious code, modify existing code, or exfiltrate sensitive data. Detecting these failed login attempts early can prevent significant damage. Although the number of victims cannot be determined with this specific detection, a successful attack can have far-reaching impacts.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Bitbucket User Login Failure\u0026rdquo; to your SIEM to detect suspicious authentication failures (logsource: bitbucket, service: audit). Tune for your environment by correlating on the author.name field.\u003c/li\u003e\n\u003cli\u003eInvestigate the source IP addresses associated with the failed login attempts to identify potential malicious actors.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to significantly reduce the risk of successful credential-based attacks.\u003c/li\u003e\n\u003cli\u003eMonitor for unusual activity following any successful login after a series of failures.\u003c/li\u003e\n\u003cli\u003eEnforce strong password policies to reduce the effectiveness of brute-force attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-03-08T15:00:00Z","date_published":"2024-03-08T15:00:00Z","id":"/briefs/2024-03-bitbucket-login-fail/","summary":"Detection of Bitbucket user login failures, potentially indicating credential access attempts, initial access attempts, or other malicious activity.","title":"Bitbucket User Login Failure Detection","url":"https://feed.craftedsignal.io/briefs/2024-03-bitbucket-login-fail/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azuread","authentication","geo-location","unauthorized-access","credential-compromise","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis brief addresses the risk of unauthorized access to Azure Active Directory (Azure AD) resources stemming from successful authentication events originating from unexpected geographic locations. While the source material does not attribute this activity to a specific threat actor, such access can be indicative of compromised user accounts, sophisticated phishing attacks, or insider threats. The focus is on detecting deviations from established operational norms, where user logins typically originate from known and trusted countries. By monitoring sign-in logs, security teams can identify potentially malicious activity that bypasses standard security controls and warrants further investigation. Effective detection relies on maintaining an accurate list of countries where the organization operates.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Compromise:\u003c/strong\u003e An attacker obtains valid user credentials through phishing, malware, or credential stuffing.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker leverages the compromised credentials to attempt authentication to Azure AD.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Request:\u003c/strong\u003e The attacker initiates a sign-in request to Azure AD from an IP address associated with an unexpected geographic location.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBypass MFA (if present):\u003c/strong\u003e If multi-factor authentication (MFA) is enabled, the attacker may attempt to bypass it through techniques like MFA fatigue or SIM swapping.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccessful Authentication:\u003c/strong\u003e The attacker successfully authenticates to Azure AD, gaining access to cloud resources and applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker attempts to escalate privileges within the Azure AD environment to gain broader access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally within the cloud environment, accessing sensitive data and resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration / Persistence:\u003c/strong\u003e The attacker exfiltrates sensitive data or establishes persistent access for future malicious activity.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to significant data breaches, financial loss, and reputational damage. The extent of the impact depends on the level of access gained by the attacker and the sensitivity of the compromised data. Organizations may face regulatory fines, legal action, and loss of customer trust. The absence of geographic restrictions on authentication increases the attack surface and elevates the risk of unauthorized access from malicious actors operating outside of the organization\u0026rsquo;s control.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule provided to detect successful authentications from countries outside of the organization\u0026rsquo;s operational footprint, based on the \u003ccode\u003eLocation\u003c/code\u003e field in Azure AD sign-in logs.\u003c/li\u003e\n\u003cli\u003eMaintain and regularly update a whitelist of countries where the organization operates to ensure the accuracy of the \u003ccode\u003efilter\u003c/code\u003e in the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the sign-in event and the potential compromise of the user account.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all users to mitigate the risk of credential compromise, although attackers may attempt to bypass MFA.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T18:22:00Z","date_published":"2024-01-29T18:22:00Z","id":"/briefs/2024-01-azure-auth-bypass/","summary":"Detection of successful authentications originating from geographic locations outside of an organization's expected operational footprint, potentially indicating compromised credentials or unauthorized access.","title":"Azure AD Authentication from Unexpected Geo-locations","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["auth","auth/v2"],"_cs_severities":["critical"],"_cs_tags":["authentication","oauth","id_collision","vulnerability"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eA critical vulnerability exists in the Patreon OAuth provider within the \u003ccode\u003ego-pkgz/auth\u003c/code\u003e and \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e libraries. Specifically, the \u003ccode\u003emapUser\u003c/code\u003e function incorrectly maps all authenticated Patreon accounts to the same local \u003ccode\u003euser.ID\u003c/code\u003e, instead of generating unique IDs based on the Patreon account data. This flaw, present in versions 1.18.0 through 1.25.1 of \u003ccode\u003ego-pkgz/auth\u003c/code\u003e and 2.0.0 through 2.1.1 of \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e, arises because the code hashes an uninitialized field instead of the Patreon user ID. This means that all Patreon users are effectively treated as a single identity within applications using these libraries. The vulnerability poses a significant risk to applications relying on \u003ccode\u003etoken.User.ID\u003c/code\u003e for authentication and authorization decisions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user attempts to authenticate with an application using the affected \u003ccode\u003ego-pkgz/auth\u003c/code\u003e library and the Patreon OAuth provider.\u003c/li\u003e\n\u003cli\u003eThe application redirects the user to Patreon for authentication.\u003c/li\u003e\n\u003cli\u003eThe user authenticates with Patreon and is redirected back to the application with an authorization code.\u003c/li\u003e\n\u003cli\u003eThe application exchanges the authorization code for an access token.\u003c/li\u003e\n\u003cli\u003eThe application uses the access token to retrieve the user\u0026rsquo;s Patreon profile data.\u003c/li\u003e\n\u003cli\u003eThe application calls the vulnerable \u003ccode\u003emapUser\u003c/code\u003e function within the \u003ccode\u003ego-pkgz/auth\u003c/code\u003e library to map the Patreon user to a local user. Due to the vulnerability, all users are mapped to the same local user ID: \u003ccode\u003epatreon_da39a3ee5e6b4b0d3255bfef95601890afd80709\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application stores the mapped user object in JWT claims.\u003c/li\u003e\n\u003cli\u003eSubsequent requests from different Patreon users are treated as coming from the same user, potentially leading to data leakage, privilege escalation, or account takeover.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability can lead to severe consequences for applications using the affected libraries. If successful, all Patreon-authenticated users may be collapsed into a single local account. This can result in data associated with one Patreon user being exposed to or overwritten by another. Additionally, Patreon-specific attributes like subscription status can leak across unrelated users. If the application grants elevated privileges to the local account associated with the shared Patreon ID, those privileges can effectively apply to every Patreon login.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade \u003ccode\u003ego-pkgz/auth\u003c/code\u003e to a version higher than 1.25.1 or \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e to a version higher than 2.1.1 to patch CVE-2026-42560.\u003c/li\u003e\n\u003cli\u003eReview and update any existing applications using the vulnerable Patreon provider to ensure proper user ID mapping after patching CVE-2026-42560.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Patreon Auth ID Collision Attempt\u0026rdquo; to detect potential exploitation by monitoring for the specific user ID pattern \u003ccode\u003epatreon_da39a3ee5e6b4b0d3255bfef95601890afd80709\u003c/code\u003e in authentication logs.\u003c/li\u003e\n\u003cli\u003eImplement additional logging and monitoring to track user authentication events and identify any anomalies in user ID assignments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-patreon-auth-id-collision/","summary":"The Patreon OAuth provider in go-pkgz/auth and go-pkgz/auth/v2 maps every authenticated Patreon account to the same local user ID, leading to cross-account access, privilege confusion, and subscription-state leakage.","title":"Patreon OAuth Provider ID Collision Vulnerability in go-pkgz/auth","url":"https://feed.craftedsignal.io/briefs/2024-01-patreon-auth-id-collision/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azuread","brute-force","credential-stuffing","authentication"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis brief focuses on detecting abnormal increases in failed authentication attempts within Azure Active Directory (Azure AD). An adversary attempting to gain unauthorized access to user accounts or systems often performs brute-force or credential stuffing attacks. These attacks result in a higher-than-normal number of failed sign-in attempts. Monitoring and detecting such increases can provide early warning of potential breaches or compromised accounts. Defenders should investigate any significant spikes in failed authentications as they might indicate malicious activity targeting user accounts or application access. The detection is based on analysis of Azure AD sign-in logs to identify when the number of failed sign-ins increases by 10% or greater, warranting further investigation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker attempts to gain initial access through various methods, such as phishing, compromised credentials, or exploiting vulnerabilities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Stuffing/Brute-Force:\u003c/strong\u003e The attacker uses lists of known usernames and passwords (credential stuffing) or systematically tries different password combinations (brute-force) against Azure AD accounts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Attempts:\u003c/strong\u003e Each failed authentication attempt is logged within Azure AD sign-in logs, recording details such as username, IP address, and failure reason.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThreshold Exceeded:\u003c/strong\u003e The number of failed sign-in attempts reaches a threshold, triggering the detection rule based on a 10% or greater increase.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Lockout (Potential):\u003c/strong\u003e Multiple failed authentication attempts may lead to account lockouts, disrupting legitimate user access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccessful Authentication (Potential):\u003c/strong\u003e If the attacker guesses the correct credentials, they gain unauthorized access to the target account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation/Lateral Movement:\u003c/strong\u003e After gaining access, the attacker attempts to escalate privileges or move laterally within the network to access sensitive data or systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Impact:\u003c/strong\u003e The attacker exfiltrates sensitive data or causes disruption to services depending on their objectives.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful brute-force or credential stuffing attack can lead to unauthorized access to user accounts, data breaches, and service disruptions. Depending on the compromised account\u0026rsquo;s privileges, the attacker may gain access to sensitive information, escalate privileges, or move laterally within the organization\u0026rsquo;s network. The impact could range from minor data leaks to significant financial losses and reputational damage. Early detection and mitigation are crucial to minimize the impact of such attacks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect increases in failed Azure AD sign-in attempts and tune the threshold (10%) based on your environment (\u003ccode\u003eCount: \u0026quot;\u0026lt;10%\u0026quot;\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rule to determine the source and scope of the increased failed authentications.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all users to mitigate the risk of credential-based attacks.\u003c/li\u003e\n\u003cli\u003eImplement account lockout policies to prevent attackers from repeatedly attempting to guess passwords.\u003c/li\u003e\n\u003cli\u003eMonitor sign-in logs for unusual patterns, such as sign-ins from unfamiliar locations or devices, to identify potential compromised accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T15:00:00Z","date_published":"2024-01-02T15:00:00Z","id":"/briefs/2024-01-02-azure-ad-failed-auth-increase/","summary":"Detects a significant increase (10% or greater) in failed Azure AD sign-in attempts, potentially indicating brute-force attacks, credential stuffing, or other unauthorized access attempts.","title":"Azure AD Failed Authentication Increase","url":"https://feed.craftedsignal.io/briefs/2024-01-02-azure-ad-failed-auth-increase/"}],"language":"en","title":"CraftedSignal Threat Feed — Authentication","version":"https://jsonfeed.org/version/1.1"}