Authentication — CraftedSignal Threat Feed

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.

Admidio SAML Signature Validation Bypass Allows Forged AuthnRequests and LogoutRequests

hello@craftedsignal.io — Wed, 29 Apr 2026 21:56:13 +0000

Admidio, a free web-based content management system for organizations and groups, contains a critical vulnerability in its SAML Single Sign-On (SSO) implementation. The validateSignature() method within the SAMLService class returns error strings upon signature validation failure, rather than throwing exceptions. The calling functions, handleSSORequest() and handleSLORequest(), incorrectly assume that the method throws an exception, and therefore, do not check the return value. This oversight renders the smc_require_auth_signed 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.

Attack Chain

An attacker crafts a malicious SAML AuthnRequest or LogoutRequest without a valid signature, impersonating a legitimate Service Provider (SP).
The attacker sends the forged SAML request to the Admidio instance via HTTP GET or POST to modules/sso/index.php.
The receiveMessage() function parses the SAML binding directly from the HTTP request, requiring no prior authentication.
The Entity ID is extracted from the forged request’s Issuer element, and the corresponding client configuration is loaded.
The validateSignature() function is called, but its return value (indicating signature validity) is discarded.
For AuthnRequests, if the targeted user has an active session ($gValidLogin is true), the login form is skipped.
Admidio builds a SAML Response containing the user’s attributes (login, name, email, roles) and sends it to the attacker-controlled AssertionConsumerServiceURL.
For LogoutRequests, the user’s session is immediately terminated in the database, triggering a cascading single logout across all registered SPs.

Impact

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

Recommendation

Apply the recommended fix in the Admidio codebase to check the return value of validateSignature() and throw an exception on failure, as outlined in the advisory (https://github.com/advisories/GHSA-25cw-98hg-g3cg).
Deploy the Sigma rule “Admidio Forged SAML AuthnRequest Detection” to detect potentially malicious SAML AuthnRequests lacking a valid signature via webserver logs.
Deploy the Sigma rule “Admidio Forged SAML LogoutRequest Detection” to detect potentially malicious SAML LogoutRequests lacking a valid signature via webserver logs.
Monitor webserver logs for requests to /adm_program/modules/sso/index.php/saml/sso and /adm_program/modules/sso/index.php/saml/slo without proper signature validation to detect potential exploitation attempts.
Upgrade to a patched version of Admidio to address CVE-2026-41669.

OpenClaw Privilege Escalation via Trusted Proxy Authentication (CVE-2026-41404)

hello@craftedsignal.io — Wed, 29 Apr 2026 12:00:00 +0000

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

Attack Chain

Attacker identifies an OpenClaw instance using trusted-proxy authentication mode.
The attacker crafts a request to a non-Control-UI client, declaring operator scopes within the authentication header.
OpenClaw’s incomplete scope clearing mechanism fails to remove the attacker-declared operator scopes.
The attacker authenticates through an identity-bearing authentication path.
Due to the persisted operator scopes, the attacker is granted elevated privileges.
The attacker leverages the escalated operator.admin privileges to perform unauthorized actions. This could include modifying configurations, accessing sensitive data, or disrupting services.
The attacker maintains persistent access by creating new administrator accounts.

Impact

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

Recommendation

Upgrade OpenClaw to version 2026.3.31 or later to patch CVE-2026-41404.
Implement strict input validation on authentication headers to prevent the declaration of unauthorized scopes.
Deploy the Sigma rule Detect OpenClaw Unauthorized Scope Declaration to monitor for suspicious authentication requests.
Review and audit existing OpenClaw configurations to identify and remove any unauthorized operator scopes.
Monitor logs for successful logins with unexpected admin privileges.

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.

BugSink Authenticated File Write Vulnerability (CVE-2026-40162)

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

BugSink, 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.

Attack Chain

Attacker obtains valid authentication token for BugSink 2.1.0 through legitimate means (e.g., compromised user credentials) or by exploiting another vulnerability.
Attacker crafts a malicious artifact bundle containing attacker-controlled content.
Attacker sends a request to the BugSink server to assemble an artifact bundle, including the malicious content, using the valid authentication token.
BugSink server, running version 2.1.0, processes the request without proper validation of the artifact bundle contents.
The server writes the attacker-controlled content to a filesystem location writable by the BugSink process. This could overwrite existing files or create new ones.
If the attacker overwrites critical configuration files or injects malicious code into executable files, they may achieve code execution.
Attacker establishes a reverse shell or uses other methods to gain remote access to the BugSink server.
Attacker performs further actions such as data exfiltration, lateral movement, or denial of service.

Impact

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

Recommendation

Upgrade BugSink to version 2.1.1 immediately to patch CVE-2026-40162, as per the vendor’s advisory.
Monitor web server logs for unusual POST requests to the artifact bundle assembly endpoints, which may indicate exploitation attempts. Deploy the Sigma rule Detect Suspicious BugSink File Write to your SIEM.
Implement strict input validation and sanitization for all user-supplied data processed by BugSink, to prevent similar file write vulnerabilities in the future.
Review 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.
Monitor file system events for unexpected file creations or modifications within the BugSink installation directory.

Unauthenticated Access to kcp Cache Server

hello@craftedsignal.io — Wed, 08 Apr 2026 15:04:22 +0000

The 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 pkg/server/config.go 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.

Attack Chain

Attacker gains network access to the kcp root shard, typically through exposed ports or external URLs.
Attacker crafts an HTTP request targeting the /services/cache/* endpoint without any authentication headers.
The request bypasses authentication and authorization checks due to the flawed preHandlerChainMux configuration.
The attacker reads replicated resources from the cache, such as clusterroles, clusterrolebindings, logicalclusters, apiexports, and validatingwebhookconfigurations.
(Optional) The attacker attempts to inject a malicious ClusterRole and ClusterRoleBinding via a POST request to the cache server.
The cache etcd watch fires, notifying the authorization informer and replication controller in parallel.
The authorization informer updates its in-memory store, briefly granting the attacker the injected RBAC rules.
The replication controller eventually reconciles and deletes the injected object, but a small window of opportunity exists for privilege escalation.

Impact

Successful 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 –shard-external-url.

Recommendation

Implement network-level access control to restrict access to the /services/cache/* paths at the load balancer, reverse proxy, or firewall level as described in the Workarounds section of the advisory.
Deploy the cache server separately with its own kubeconfig (--cache-server-kubeconfig) and restrict network access to it, mitigating direct exposure to the root shard as per the Workarounds section.
Upgrade to kcp version v0.29.3 or v0.30.3 or later to patch the vulnerability as per CVE-2026-39429.

Distribution Toolkit Authentication Redirection Vulnerability (CVE-2026-33540)

hello@craftedsignal.io — Mon, 06 Apr 2026 15:17:10 +0000

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

Attack Chain

Attacker gains control of or MitM position to an upstream registry server used by the distribution toolkit.
Distribution toolkit attempts to pull an image from the upstream registry.
Attacker’s registry responds with a WWW-Authenticate header, specifying a Bearer authentication scheme and an attacker-controlled realm URL.
The distribution toolkit, vulnerable to CVE-2026-33540, parses the WWW-Authenticate header but fails to validate the realm URL against the legitimate upstream registry.
The distribution toolkit initiates a basic authentication request to the attacker-controlled realm URL, sending the configured upstream credentials (username and password).
The attacker captures the credentials sent via basic authentication.
Attacker uses the compromised credentials to gain unauthorized access to the legitimate upstream registry.

Impact

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

Recommendation

Upgrade the distribution toolkit to version 3.1.0 or later to remediate CVE-2026-33540.
Implement network monitoring to detect basic authentication attempts originating from the distribution toolkit to unusual or unexpected destinations (see rule: “Detect Basic Authentication to Non-Standard Ports”).
Monitor network traffic for connections to unusual or suspicious realm URLs returned in WWW-Authenticate headers from container registries (see rule: “Detect Authentication Redirection”).

fast-jwt Library Vulnerability Allows crit Header Validation Bypass

hello@craftedsignal.io — Fri, 03 Apr 2026 22:01:25 +0000

The fast-jwt library, versions 6.1.0 and below, exhibits a critical vulnerability where it does not properly validate the crit (Critical) Header Parameter as defined in RFC 7515. This oversight allows JWS tokens containing unrecognized extensions within the crit 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.

Attack Chain

The attacker crafts a JWT with a crit header containing an extension (e.g., “x-custom-policy”) that fast-jwt does not support.
The attacker includes this unsupported extension header (e.g., "x-custom-policy": "require-mfa") in the JWT header.
The attacker signs the JWT using a valid signing key and algorithm (e.g., HS256).
The attacker presents the crafted JWT to a system or application using the vulnerable fast-jwt library for verification.
The fast-jwt library incorrectly accepts the token without validating the crit header extensions.
The application logic proceeds based on the accepted (but invalid) JWT, potentially granting unauthorized access or privileges.
If other JWT libraries are used in the same environment that do properly validate the crit header, a “split-brain” verification scenario can occur, with some systems rejecting the token while others accept it.
The ultimate objective is to bypass intended security policies, such as multi-factor authentication or token binding requirements, gaining unauthorized access or control.

Impact

Successful 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 crit header, such as mandatory multi-factor authentication. Finally, it can circumvent token binding mechanisms (RFC 7800 cnf confirmation), weakening overall authentication security. The full impact analysis is described in CVE-2025-59420. This vulnerability affects applications using fast-jwt version 6.1.0 and earlier.

Recommendation

Upgrade the fast-jwt library to a version greater than 6.1.0 to remediate CVE-2026-35042.
Deploy the Sigma rule “Detect fast-jwt crit Header Bypass Attempt” to identify attempts to exploit this vulnerability in your environment.
If a mixed-library JWT verification environment exists, evaluate and standardize on a single JWT library that correctly handles the crit header parameter.
Review existing JWT usage to identify instances where the crit header is used for security policy enforcement and ensure that appropriate validation is in place.

Amazon Athena ODBC Driver Authentication Bypass Vulnerability (CVE-2026-35561)

hello@craftedsignal.io — Fri, 03 Apr 2026 21:17:12 +0000

CVE-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’s Athena environment.

Attack Chain

The attacker identifies a target using a vulnerable version of the Amazon Athena ODBC driver (prior to 2.1.0.0).
The 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.
Due to insufficient security controls, the attacker is able to extract or manipulate the authentication credentials or session tokens.
The attacker uses the stolen credentials to authenticate to Amazon Athena as the compromised user.
The attacker queries sensitive data stored within Athena databases.
The attacker modifies data within the Athena environment, potentially injecting malicious code or altering existing records.
The attacker pivots to other AWS services accessible with the compromised account.

Impact

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

Recommendation

Immediately upgrade the Amazon Athena ODBC driver to version 2.1.0.0 or later across all affected systems to remediate CVE-2026-35561.
Monitor network traffic for suspicious authentication patterns related to Amazon Athena, using a network intrusion detection system (IDS) or firewall logs.
Implement multi-factor authentication (MFA) for all AWS accounts accessing Amazon Athena to mitigate the impact of compromised credentials.
Deploy the Sigma rule “Detect Suspicious Athena ODBC Driver User Agent” to identify potentially vulnerable or malicious driver versions in use.
Review and enforce least privilege access controls for all IAM roles and users accessing Amazon Athena to limit the potential impact of unauthorized access.

Better Auth Two-Factor Authentication Bypass Vulnerability

hello@craftedsignal.io — Fri, 03 Apr 2026 03:29:59 +0000

Better 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 session.cookieCache 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 better-auth with 2FA and session cookie caching enabled is potentially vulnerable.

Attack Chain

User attempts to log in with valid username and password.
The application, running a vulnerable version of better-auth with session.cookieCache enabled, creates a session.
The session is cached due to the session.cookieCache setting, before the 2FA challenge is presented.
The user is prompted for their second factor (e.g., TOTP code).
Instead of providing the 2FA code, the attacker intercepts or reuses the cached session cookie.
The attacker presents the cached session cookie to the application.
The application retrieves the cached session, which it prematurely considers valid.
The attacker gains access to protected resources without completing 2FA.

Impact

Successful 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 better-auth with 2FA and session caching are potentially at risk. A successful attack could lead to data breaches, account takeovers, and other serious security incidents.

Recommendation

Upgrade to better-auth version 1.4.9 or later to patch the vulnerability.
Disable session.cookieCache when using two-factor authentication as a temporary mitigation.
If disabling session.cookieCache is not feasible, implement server-side checks to ensure 2FA is completed before granting full session validity (requires code modification).

Azure SRE Agent Improper Authentication Vulnerability (CVE-2026-32173)

hello@craftedsignal.io — Fri, 03 Apr 2026 00:16:04 +0000

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

Attack Chain

An unauthenticated attacker identifies a vulnerable Azure SRE Agent instance.
The attacker crafts a malicious network request targeting the vulnerable endpoint on the agent.
Due to the improper authentication, the agent processes the request without proper authorization.
The agent retrieves sensitive information that it is normally restricted from disclosing.
The agent transmits the sensitive information back to the attacker over the network.
The attacker captures and analyzes the disclosed data.
The attacker uses the disclosed information for further reconnaissance or exploitation activities within the Azure environment.

Impact

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

Recommendation

Apply the patch provided by Microsoft for CVE-2026-32173 as soon as possible to remediate the vulnerability (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32173).
Monitor network traffic for suspicious activity targeting Azure SRE Agent endpoints using the “Detect Azure SRE Agent Information Disclosure Attempt” Sigma rule.
Review access controls and network segmentation to limit the blast radius in case of successful exploitation.

Keycloak Redirect URI Bypass Vulnerability (CVE-2026-3872)

hello@craftedsignal.io — Thu, 02 Apr 2026 13:16:26 +0000

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

Attack Chain

The 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.
The 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.
A legitimate user initiates an authentication request to Keycloak, potentially through a vulnerable application relying on Keycloak for authentication.
Keycloak processes the authentication request and, due to the vulnerability, accepts the attacker’s crafted redirect URI as valid.
Keycloak redirects the user to the attacker-controlled URL after successful authentication.
The attacker’s server captures the access token from the redirect URI.
The attacker uses the stolen access token to impersonate the user and access protected resources.
The attacker gains unauthorized access to sensitive information or performs actions on behalf of the user, leading to information disclosure or other malicious activities.

Impact

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

Recommendation

Apply 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.
Deploy the provided Sigma rule to detect exploitation attempts of CVE-2026-3872 based on suspicious redirect URIs in web server logs.
Review and harden the configuration of redirect URIs in Keycloak, avoiding the use of wildcards where possible and implementing stricter validation rules.
Monitor web server logs for suspicious activity related to redirect URIs, looking for unusual patterns or attempts to access unauthorized resources.

GitLab Jira Connect Authentication Bypass Vulnerability (CVE-2026-2370)

hello@craftedsignal.io — Mon, 30 Mar 2026 00:16:01 +0000

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

MIT Kerberos Security Bypass Vulnerability

hello@craftedsignal.io — Tue, 24 Mar 2026 10:16:06 +0000

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

Attack Chain

The attacker identifies a vulnerable MIT Kerberos implementation.
The attacker crafts a malicious request to exploit the Kerberos vulnerability, likely targeting a specific service or protocol weakness.
The malicious request bypasses authentication or authorization checks due to the vulnerability.
The attacker gains unauthorized access to a Kerberos-protected resource or service.
Depending on the exploited vulnerability, the attacker may impersonate a legitimate user or service.
The attacker performs unauthorized actions, such as accessing sensitive data or executing commands.
The attacker escalates privileges within the Kerberos realm, potentially compromising the entire authentication infrastructure.

Impact

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

Recommendation

Monitor Kerberos authentication logs for anomalies indicative of exploitation attempts (see generic rule below).
Investigate and apply any available patches or workarounds released by MIT Kerberos to address the vulnerability.
Review and strengthen Kerberos configuration settings to minimize the attack surface.
Implement network segmentation to limit the impact of a potential Kerberos compromise.

Bitbucket User Login Failure Detection

hello@craftedsignal.io — Fri, 08 Mar 2024 15:00:00 +0000

This 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 “author.name” field for enhanced accuracy and context. Requires “Advance” log level to receive audit events.

Attack Chain

Initial Access Attempt: An attacker attempts to gain initial access to a Bitbucket account using a compromised or guessed username.
Credential Guessing: The attacker attempts to guess the user’s password through manual attempts or automated tools.
Authentication Failure: Bitbucket records a “User login failed” event due to incorrect credentials. The auditType.category is Authentication, and auditType.action is User login failed.
Multiple Failed Attempts: The attacker repeats the login attempts with different password variations or using a list of compromised credentials.
Account Lockout (Optional): Depending on Bitbucket’s configuration, repeated failed login attempts may trigger an account lockout.
Successful Login (Potential): After multiple attempts, the attacker may eventually guess the correct password or use a valid compromised credential.
Privilege Escalation/Persistence (If Successful): If successful, the attacker could escalate privileges, establish persistence, or perform other malicious actions within the Bitbucket environment.

Impact

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

Recommendation

Deploy the Sigma rule “Bitbucket User Login Failure” to your SIEM to detect suspicious authentication failures (logsource: bitbucket, service: audit). Tune for your environment by correlating on the author.name field.
Investigate the source IP addresses associated with the failed login attempts to identify potential malicious actors.
Implement multi-factor authentication (MFA) to significantly reduce the risk of successful credential-based attacks.
Monitor for unusual activity following any successful login after a series of failures.
Enforce strong password policies to reduce the effectiveness of brute-force attacks.

Azure AD Authentication from Unexpected Geo-locations

hello@craftedsignal.io — Mon, 29 Jan 2024 18:22:00 +0000

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

Attack Chain

Credential Compromise: An attacker obtains valid user credentials through phishing, malware, or credential stuffing.
Initial Access: The attacker leverages the compromised credentials to attempt authentication to Azure AD.
Authentication Request: The attacker initiates a sign-in request to Azure AD from an IP address associated with an unexpected geographic location.
Bypass MFA (if present): If multi-factor authentication (MFA) is enabled, the attacker may attempt to bypass it through techniques like MFA fatigue or SIM swapping.
Successful Authentication: The attacker successfully authenticates to Azure AD, gaining access to cloud resources and applications.
Privilege Escalation: The attacker attempts to escalate privileges within the Azure AD environment to gain broader access.
Lateral Movement: The attacker moves laterally within the cloud environment, accessing sensitive data and resources.
Data Exfiltration / Persistence: The attacker exfiltrates sensitive data or establishes persistent access for future malicious activity.

Impact

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

Recommendation

Deploy the Sigma rule provided to detect successful authentications from countries outside of the organization’s operational footprint, based on the Location field in Azure AD sign-in logs.
Maintain and regularly update a whitelist of countries where the organization operates to ensure the accuracy of the filter in the Sigma rule.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the sign-in event and the potential compromise of the user account.
Enforce multi-factor authentication (MFA) for all users to mitigate the risk of credential compromise, although attackers may attempt to bypass MFA.

Patreon OAuth Provider ID Collision Vulnerability in go-pkgz/auth

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

A critical vulnerability exists in the Patreon OAuth provider within the go-pkgz/auth and go-pkgz/auth/v2 libraries. Specifically, the mapUser function incorrectly maps all authenticated Patreon accounts to the same local user.ID, instead of generating unique IDs based on the Patreon account data. This flaw, present in versions 1.18.0 through 1.25.1 of go-pkgz/auth and 2.0.0 through 2.1.1 of go-pkgz/auth/v2, 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 token.User.ID for authentication and authorization decisions.

Attack Chain

A user attempts to authenticate with an application using the affected go-pkgz/auth library and the Patreon OAuth provider.
The application redirects the user to Patreon for authentication.
The user authenticates with Patreon and is redirected back to the application with an authorization code.
The application exchanges the authorization code for an access token.
The application uses the access token to retrieve the user’s Patreon profile data.
The application calls the vulnerable mapUser function within the go-pkgz/auth library to map the Patreon user to a local user. Due to the vulnerability, all users are mapped to the same local user ID: patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709.
The application stores the mapped user object in JWT claims.
Subsequent requests from different Patreon users are treated as coming from the same user, potentially leading to data leakage, privilege escalation, or account takeover.

Impact

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

Recommendation

Upgrade go-pkgz/auth to a version higher than 1.25.1 or go-pkgz/auth/v2 to a version higher than 2.1.1 to patch CVE-2026-42560.
Review and update any existing applications using the vulnerable Patreon provider to ensure proper user ID mapping after patching CVE-2026-42560.
Deploy the Sigma rule “Patreon Auth ID Collision Attempt” to detect potential exploitation by monitoring for the specific user ID pattern patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709 in authentication logs.
Implement additional logging and monitoring to track user authentication events and identify any anomalies in user ID assignments.

Azure AD Failed Authentication Increase

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

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

Attack Chain

Initial Access: The attacker attempts to gain initial access through various methods, such as phishing, compromised credentials, or exploiting vulnerabilities.
Credential Stuffing/Brute-Force: The attacker uses lists of known usernames and passwords (credential stuffing) or systematically tries different password combinations (brute-force) against Azure AD accounts.
Authentication Attempts: Each failed authentication attempt is logged within Azure AD sign-in logs, recording details such as username, IP address, and failure reason.
Threshold Exceeded: The number of failed sign-in attempts reaches a threshold, triggering the detection rule based on a 10% or greater increase.
Account Lockout (Potential): Multiple failed authentication attempts may lead to account lockouts, disrupting legitimate user access.
Successful Authentication (Potential): If the attacker guesses the correct credentials, they gain unauthorized access to the target account.
Privilege Escalation/Lateral Movement: After gaining access, the attacker attempts to escalate privileges or move laterally within the network to access sensitive data or systems.
Data Exfiltration/Impact: The attacker exfiltrates sensitive data or causes disruption to services depending on their objectives.

Impact

A 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’s privileges, the attacker may gain access to sensitive information, escalate privileges, or move laterally within the organization’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.

Recommendation

Deploy 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 (Count: "<10%").
Investigate alerts generated by the Sigma rule to determine the source and scope of the increased failed authentications.
Enforce multi-factor authentication (MFA) for all users to mitigate the risk of credential-based attacks.
Implement account lockout policies to prevent attackers from repeatedly attempting to guess passwords.
Monitor sign-in logs for unusual patterns, such as sign-ins from unfamiliar locations or devices, to identify potential compromised accounts.