Authorization — CraftedSignal Threat Feed

Kirby CMS Missing Authorization Vulnerability

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

Kirby CMS versions prior to 4.9.0 and between 5.0.0 and 5.3.3 are vulnerable to a missing authorization flaw. This vulnerability impacts Kirby sites where user roles are intentionally configured with restricted access to pages or files through disabled pages.access, pages.list, files.access, or files.list permissions. The issue stems from inconsistent permission checks within the Kirby Panel and REST API, allowing authenticated users to access resources they should not be able to. Updating to versions 4.9.0, 5.4.0, or later resolves this vulnerability by implementing consistent permission checks. The vulnerability is identified as CVE-2026-42137.

Attack Chain

An authenticated user logs into the Kirby CMS Panel or REST API.
The user attempts to access a page or file for which their role lacks the necessary pages.access/files.access or pages.list/files.list permissions.
Due to inconsistent permission checks, the user can view the page or file details via the “changes” dialog in the Panel, even if listing is disabled.
The user accesses the REST API, which, despite direct access checks, fails to properly filter collections or related models (children, drafts, files, etc.).
The attacker views images associated with restricted site, pages, or user resources in lists within the Panel.
The user exploits the incorrect permission check (using pages.access instead of pages.list or files.access instead of files.list in specific API routes).
The user traverses to previous or next files using direct links in the files view, even if those files should not be listable.
The attacker gains unauthorized access to sensitive information or modifies content due to the bypassed permission checks.

Impact

This vulnerability allows authenticated users to bypass intended access restrictions within Kirby CMS, leading to potential unauthorized access to sensitive information and/or unauthorized content modification. The inconsistent permission checks in the Panel and REST API could result in unintended disclosure of data restricted by role-based access controls. Successful exploitation could compromise the confidentiality and integrity of the affected Kirby CMS instance. While the advisory does not list the number of victims, this flaw impacts any Kirby site with restricted roles.

Recommendation

Upgrade to Kirby CMS version 4.9.0 or 5.4.0 (or later) to patch the vulnerability as recommended in the advisory.
Review user role permissions and blueprint configurations to ensure appropriate access controls are in place after patching, as described in the overview.
Monitor web server logs for unusual API requests to resources that should be restricted, using the rules below, to identify potential exploitation attempts.
Implement rate limiting on API endpoints to mitigate potential brute-force attacks attempting to exploit this or other vulnerabilities.

Clerk Authorization Bypass Vulnerability

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

A critical authorization bypass vulnerability has been identified in Clerk’s authorization predicates (has() and auth.protect()) across multiple SDKs, including @clerk/shared, @clerk/nextjs, and @clerk/backend. This flaw, reported on April 18, 2026, and patched on April 22, 2026, can lead to incorrect authorization decisions when combining multiple authorization dimensions (e.g., reverification with role). Specifically, the predicates may return true even if the user does not satisfy all required conditions, potentially allowing unauthorized access to gated actions. A secondary bypass exists in @clerk/nextjs, where auth.protect() silently discards authorization parameters under certain conditions. The vulnerability affects applications using specific combinations of authorization checks, emphasizing the need for immediate patching.

Attack Chain

An attacker identifies an application utilizing affected Clerk packages and vulnerable authorization checks.
The attacker targets an endpoint protected by a combined authorization check (e.g., requiring a specific role and reverification).
The attacker crafts a request that satisfies one, but not all, of the authorization conditions.
Due to the bypass vulnerability, the has() or auth.protect() predicate incorrectly returns true.
The application grants the attacker access to the protected resource or functionality.
In the case of the @clerk/nextjs bypass, the attacker might exploit the silent discarding of authorization parameters when unauthenticatedUrl, unauthorizedUrl, or token are also present in the auth.protect() call, effectively bypassing authorization.
The attacker performs unauthorized actions, such as modifying data or accessing restricted areas of the application.

Impact

Successful exploitation of this vulnerability could lead to unauthorized access to sensitive resources and functionalities within applications using Clerk for authentication and authorization. This could result in data breaches, privilege escalation, and other security incidents. The vulnerability affects a wide range of Clerk packages, potentially impacting a significant number of applications relying on Clerk for access control. Immediate patching is crucial to mitigate the risk of exploitation.

Recommendation

Upgrade to the latest patch release of the consuming app’s framework package as specified in the advisory to remediate CVE-2026-42349.
If immediate upgrade is not feasible, implement the suggested workaround of splitting combined has() or auth.protect() calls into sequential single-condition checks as described in the advisory.
Deploy the Sigma rule ClerkAuthProtectBypass to detect potential exploitation attempts by monitoring for calls to auth.protect that include unauthenticatedUrl, unauthorizedUrl, or token parameters.
Deploy the Sigma rule ClerkCombinedAuthCheckBypass to identify suspicious process creation events that may indicate unauthorized access due to the authorization bypass.

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.

vanna-ai vanna Improper Authorization Vulnerability (CVE-2026-6977)

hello@craftedsignal.io — Sat, 25 Apr 2026 11:16:19 +0000

A security vulnerability, identified as CVE-2026-6977, has been discovered in vanna-ai vanna versions up to 2.0.2. The vulnerability resides within an unspecified function of the Legacy Flask API component. Successful exploitation of this flaw leads to improper authorization, potentially granting unauthorized access to sensitive resources or functionalities. The vulnerability is remotely exploitable and a proof-of-concept exploit is publicly available. The vendor was contacted but did not respond. This vulnerability poses a risk to systems utilizing the affected versions of vanna-ai vanna, as attackers could leverage it to bypass intended access controls.

Attack Chain

Attacker identifies a vulnerable vanna-ai vanna instance running version 2.0.2 or earlier.
Attacker crafts a malicious HTTP request targeting the Legacy Flask API. The specific endpoint and parameters involved are not defined in the source material.
The crafted request exploits the improper authorization vulnerability (CVE-2026-6977) within the Legacy Flask API.
Due to the improper authorization flaw, the attacker’s request bypasses the intended access controls.
The vulnerable application grants the attacker unauthorized access to resources or functionalities that should be restricted.
Depending on the accessed resources, the attacker may gain access to sensitive data, modify system settings, or perform other unauthorized actions.
The attacker may escalate privileges or move laterally within the affected system if further vulnerabilities exist or if the compromised application has elevated permissions.

Impact

Successful exploitation of CVE-2026-6977 allows a remote attacker to bypass authorization checks in vanna-ai vanna, potentially leading to unauthorized access to sensitive data or functionality. Given that a public exploit exists, organizations utilizing affected versions of vanna-ai vanna are at increased risk. The lack of vendor response further exacerbates the risk, as no official patch or mitigation guidance is available.

Recommendation

Monitor web server logs for suspicious activity targeting the Legacy Flask API in vanna-ai vanna, using a webserver category Sigma rule focused on unusual HTTP requests.
Apply generic hardening and input validation techniques to mitigate the impact of potential exploits targeting web applications.
Investigate and validate the activity from the VulDB references provided in this brief.

FreeScout Incorrect Authorization Vulnerability via Save Draft

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

FreeScout is a self-hosted help desk and shared mailbox platform. Prior to version 1.8.215, a vulnerability exists related to authorization controls when the APP_SHOW_ONLY_ASSIGNED_CONVERSATIONS setting is enabled. Specifically, the save_draft AJAX endpoint lacks proper authorization checks. This allows an attacker to potentially bypass intended access restrictions and create drafts within conversations that they should not be able to access, leading to unauthorized modification or viewing of conversation data. This vulnerability was addressed in version 1.8.215.

Attack Chain

Attacker identifies a FreeScout instance running a version prior to 1.8.215 with APP_SHOW_ONLY_ASSIGNED_CONVERSATIONS enabled.
Attacker authenticates to the FreeScout instance with a valid, but unauthorized user account.
Attacker identifies the conversation ID of a conversation they are not assigned to and cannot normally access via the UI.
Attacker crafts a POST request to the /index.php?m=conversations&a=save_draft endpoint, including the conversation ID and the draft content they wish to create.
The server, lacking proper authorization checks on the save_draft endpoint, accepts the POST request.
A draft is created within the targeted conversation, associated with the attacker’s user account.
The attacker, or potentially other unauthorized users who later gain access to the attacker’s account, can view or modify the drafted content, potentially exfiltrating sensitive information.

Impact

Successful exploitation of this vulnerability allows unauthorized users to create drafts within conversations they are not assigned to. This could lead to the unauthorized viewing or modification of sensitive information contained within the conversations, potentially leading to data breaches or compliance violations. The vulnerability affects FreeScout instances running versions prior to 1.8.215 with the specific APP_SHOW_ONLY_ASSIGNED_CONVERSATIONS setting enabled.

Recommendation

Upgrade FreeScout to version 1.8.215 or later to remediate the vulnerability (references: https://github.com/freescout-help-desk/freescout/releases/tag/1.8.215).
Monitor web server logs for POST requests to the /index.php?m=conversations&a=save_draft endpoint originating from unusual IP addresses or user agents using the Sigma rule provided below.
Implement web application firewall (WAF) rules to filter or block unauthorized POST requests to the vulnerable endpoint.

FreeScout Incorrect Authorization Vulnerability (CVE-2026-41189)

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

FreeScout, a self-hosted help desk and shared mailbox platform, is affected by an authorization bypass vulnerability. Specifically, versions prior to 1.8.215 fail to properly restrict access to customer threads within conversations. The vulnerability resides in the ThreadPolicy::edit() function, which checks mailbox access but neglects to enforce the ConversationPolicy’s assigned-only restriction. This allows a user who should not have access to a conversation to still load and modify customer-authored threads contained within that conversation. Upgrading to version 1.8.215 resolves this vulnerability. This allows unauthorized modification of customer communications, potentially leading to data breaches or manipulated customer service interactions.

Attack Chain

Attacker gains access to a FreeScout user account with limited privileges.
Attacker attempts to access a conversation thread for which they lack explicit authorization.
The application’s ThreadPolicy::edit() function is invoked to authorize the edit action.
The ThreadPolicy::edit() function incorrectly authorizes the action by only checking mailbox access, bypassing the ConversationPolicy’s assigned-only restriction.
The attacker successfully loads the customer-authored thread, gaining unauthorized access.
Attacker modifies the content of the customer-authored thread.
The modified thread is saved, altering the conversation history.
The change impacts communications with the customer.

Impact

This vulnerability (CVE-2026-41189) allows unauthorized users to modify customer communications within the FreeScout help desk platform. Successful exploitation can lead to data integrity issues, potentially impacting all customer conversations within the affected FreeScout instance. The severity is heightened by the potential for attackers to manipulate sensitive information, leading to reputational damage, legal ramifications, and loss of customer trust.

Recommendation

Upgrade FreeScout to version 1.8.215 or later to patch CVE-2026-41189.
Monitor FreeScout web server logs for unauthorized access attempts using the provided Sigma rule.
Review user access controls and ensure that the principle of least privilege is enforced to limit the impact of potential compromises.
Implement the provided Sigma rule to detect potential unauthorized thread editing attempts based on HTTP request patterns.

Better Auth OAuth Provider Authorization Bypass Vulnerability

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

An authorization bypass vulnerability affects the OAuth provider component of Better Auth, specifically versions 1.4.8-beta.7 through 1.6.4 and 1.7.0-beta.0 through 1.7.0-beta.1. This flaw allows any authenticated, low-privilege user to create OAuth clients, bypassing the intended restrictions set by the clientPrivileges configuration. The vulnerability stems from the client creation endpoints (adminCreateOAuthClient and createOAuthClient) not enforcing the clientPrivileges check before creating new OAuth clients. This bypass allows attackers to register OAuth clients with attacker-controlled redirect URIs and metadata, potentially leading to phishing attacks and abuse of trust assumptions in OAuth/OIDC flows. Defenders should implement detections to identify unauthorized OAuth client creation attempts.

Attack Chain

An attacker authenticates to the Better Auth application with a low-privilege account.
The attacker crafts a POST request to either /api/auth/oauth2/create-client or a custom endpoint that routes to adminCreateOAuthClient.
The attacker includes parameters for client_name, redirect_uris, and other client metadata within the POST request body.
The createOAuthClientEndpoint function is called without first performing a clientPrivileges authorization check.
A new OAuth client is created and persisted in the system.
The attacker now controls a registered OAuth client with attacker-defined redirect URIs.
The attacker can potentially use this client for phishing attacks or to bypass consent flows if skip_consent is enabled (if adminCreateOAuthClient is exposed).
The attacker exploits the newly created OAuth client to gain unauthorized access to resources or user data.

Impact

This vulnerability allows unauthorized users to create OAuth clients, potentially leading to several negative consequences. Attackers can register clients with malicious redirect URIs, which can be used in phishing campaigns to steal user credentials or OAuth tokens. In scenarios where the adminCreateOAuthClient endpoint is exposed, attackers can create clients that bypass user consent, further increasing the risk of successful attacks. The impact is significant because it breaks the intended access control mechanism of the clientPrivileges configuration, affecting applications that rely on it to restrict client registration. Successful exploitation can lead to unauthorized access to user data, compromised accounts, and damaged trust in the application.

Recommendation

Monitor web server logs for POST requests to the /api/auth/oauth2/create-client endpoint, especially from users who should not have client creation privileges. Implement the “Detect Unauthorized OAuth Client Creation Attempt” Sigma rule below, using webserver logs (category: “webserver”, product: “linux”).
Apply the necessary patches to upgrade @better-auth/oauth-provider to a version that addresses this vulnerability (>= 1.6.5 or >= 1.7.0-beta.2).
Audit your application’s OAuth client registration process to ensure that the clientPrivileges check is enforced correctly.
If using adminCreateOAuthClient, ensure it is not exposed to low-privilege authenticated users to prevent the skip_consent bypass.
Deploy the “Detect OAuth Client Creation with Skip Consent” Sigma rule if your deployment exposes the admin client creation endpoint.

Vault Token Leak via Authorization Header Forwarding

hello@craftedsignal.io — Fri, 17 Apr 2026 04:16:09 +0000

CVE-2026-4525 describes a vulnerability in HashiCorp Vault where an improperly sanitized “Authorization” header can lead to token exposure. Specifically, if a Vault auth mount is configured to pass through the “Authorization” header, and that header is used to authenticate with Vault, the Vault token itself is inadvertently forwarded to the auth plugin backend. This unintended token forwarding could allow malicious actors to gain unauthorized access if they can intercept or control the auth plugin backend. This issue affects Vault versions prior to 2.0.0, 1.21.5, 1.20.10, and 1.19.16 and was reported by HashiCorp. The vulnerability was patched in the aforementioned versions. Exploitation would require specific Vault configuration and the ability to influence the authentication process via the Authorization header.

Attack Chain

An attacker identifies a Vault instance with an auth mount configured to pass through the “Authorization” header.
The attacker crafts a malicious request to Vault, including a valid “Authorization” header for authentication purposes.
Vault processes the request and, due to the vulnerability, forwards the Vault token contained in the “Authorization” header to the configured auth plugin backend.
The attacker intercepts the forwarded Vault token, either by compromising the auth plugin backend or through network monitoring.
The attacker uses the stolen Vault token to authenticate directly to Vault, bypassing normal authentication procedures.
The attacker gains unauthorized access to sensitive data and secrets stored within Vault.
The attacker escalates privileges within the Vault environment by leveraging the compromised token’s permissions.

Impact

Successful exploitation of CVE-2026-4525 allows an attacker to steal Vault tokens, potentially granting them complete control over the Vault instance and access to all stored secrets. The severity is high due to the potential for complete compromise of sensitive data. The impact depends on the scope of secrets managed by the compromised Vault instance; in some cases, this could lead to a complete breach of the affected organization’s infrastructure. The vulnerability affects all organizations using vulnerable versions of Vault with auth mounts configured to pass through the “Authorization” header.

Recommendation

Upgrade Vault instances to versions 2.0.0, 1.21.5, 1.20.10, or 1.19.16 or later to remediate CVE-2026-4525.
Review Vault auth mount configurations to ensure that the “Authorization” header is not being passed through unnecessarily.
Monitor network traffic for unauthorized access attempts using stolen Vault tokens after applying the patch.
Implement the provided Sigma rule targeting the usage of specific auth paths after a potential compromise.

Juju CloudSpec API Authorization Bypass (CVE-2026-5412)

hello@craftedsignal.io — Fri, 10 Apr 2026 13:16:45 +0000

CVE-2026-5412 identifies an authorization bypass vulnerability affecting Juju, an open-source service orchestration tool. Specifically, versions prior to 2.9.57 and 3.6.21 are susceptible. An authenticated user with low privileges can exploit this vulnerability by invoking the CloudSpec API method. This method, intended for controller bootstrapping, inadvertently exposes sensitive cloud credentials when accessed by unauthorized users. Successful exploitation grants access to the credentials used to manage the cloud environment where Juju is deployed. This poses a significant risk, potentially allowing attackers to compromise the entire cloud infrastructure managed by the vulnerable Juju controller. Defenders should prioritize patching vulnerable Juju deployments.

Attack Chain

Attacker authenticates to the Juju controller with a low-privileged account.
The attacker crafts a malicious API request to the CloudSpec method.
The Juju controller, lacking proper authorization checks, processes the request.
The CloudSpec method retrieves the cloud credentials used for bootstrapping.
The controller returns the cloud credentials to the attacker.
Attacker obtains the sensitive cloud credentials, such as AWS access keys or Azure service principal secrets.
The attacker uses the stolen cloud credentials to access and control cloud resources.
Attacker achieves complete compromise of the cloud environment.

Impact

Successful exploitation of CVE-2026-5412 allows a low-privileged, authenticated attacker to steal cloud credentials. This can lead to complete compromise of the cloud infrastructure managed by the vulnerable Juju controller. The impact includes unauthorized access to data, potential data breaches, denial of service, and the ability to deploy malicious workloads within the cloud environment. The severity is heightened by the ease of exploitation and the high value of the exposed cloud credentials.

Recommendation

Upgrade Juju controllers to versions 2.9.57 or 3.6.21 to remediate CVE-2026-5412.
Implement the Sigma rule “Detect Juju CloudSpec API Access” to detect unauthorized calls to the CloudSpec API method in Juju environments.
Monitor Juju controller logs for suspicious API requests originating from low-privileged accounts.
Review and enforce strict access control policies within the cloud environment to limit the impact of compromised credentials.

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.

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.

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.

Keycloak Authorization Code Forging Vulnerability (CVE-2026-4282)

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

CVE-2026-4282 identifies a critical vulnerability within the Keycloak authentication server, specifically affecting the SingleUseObjectProvider. This component, responsible for managing single-use key-value pairs, suffers from a lack of sufficient type and namespace isolation. The absence of proper isolation mechanisms allows a remote, unauthenticated attacker to manipulate the system by forging authorization codes. Successful exploitation allows for the creation of access tokens with administrative privileges. The vulnerability was published on April 2, 2026.

Attack Chain

The attacker sends a crafted request to the Keycloak server to initiate the authorization flow.
The attacker leverages the lack of type and namespace isolation in the SingleUseObjectProvider.
The attacker forges a valid authorization code using the vulnerability.
The attacker presents the forged authorization code to the token endpoint.
Keycloak validates the forged code due to the flawed SingleUseObjectProvider logic.
The attacker receives an access token with elevated (admin) privileges.
The attacker uses the admin-capable access token to perform administrative actions.
The attacker gains full control over Keycloak resources and user data.

Impact

Successful exploitation of CVE-2026-4282 allows a remote attacker to gain full administrative control over a Keycloak instance. This can lead to the compromise of all applications and services relying on Keycloak for authentication and authorization. The impact includes data breaches, account takeovers, and the potential for widespread service disruption. Given Keycloak’s prevalence in securing web applications and APIs, the vulnerability poses a significant risk to organizations using affected versions.

Recommendation

Apply the patch or upgrade to a version of Keycloak that resolves CVE-2026-4282 as soon as it becomes available from Red Hat.
Monitor Keycloak logs (webserver category, linux product) for suspicious requests to the authorization and token endpoints indicative of authorization code forging attempts.
Implement stricter input validation and sanitization on the authorization code parameter to mitigate the vulnerability.

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…

OpenClaw Gateway Plugin Subagent Admin Scope Vulnerability

hello@craftedsignal.io — Sun, 29 Mar 2026 15:50:41 +0000

The openclaw package, specifically versions up to and including 2026.3.24, contains a vulnerability within the gateway plugin subagent fallback mechanism. The deleteSession function, when invoked without a request-scoped client, incorrectly dispatched sessions.delete utilizing a synthetic operator.admin runtime scope. This means that under certain conditions, session deletion operations were being performed with elevated privileges, potentially leading to unauthorized session management. This vulnerability was present in the code up to version 2026.3.24 and has been patched in version 2026.3.25. Defenders should ensure they are running version 2026.3.25 or later to mitigate this risk.

Attack Chain

A request is made to the gateway plugin that triggers the deleteSession function.
The deleteSession function checks for a request-scoped client.
If no request-scoped client exists, the code falls back to a default mechanism.
The vulnerable code path then incorrectly creates a synthetic operator.admin runtime scope.
The sessions.delete function is dispatched with the elevated operator.admin scope.
Session deletion occurs with the privileges of the synthetic admin operator.
An attacker could potentially trigger this code path to delete sessions they should not have access to.

Impact

Successful exploitation of this vulnerability could lead to unauthorized session deletion within the openclaw application. While the exact impact depends on the specific deployment and usage of openclaw, the ability to delete arbitrary sessions could disrupt service availability or allow an attacker to invalidate legitimate user sessions. If an attacker can reliably trigger this vulnerability, it could lead to denial-of-service or other forms of service disruption.

Recommendation

Upgrade the openclaw package to version 2026.3.25 or later to remediate the vulnerability described in the overview.
Review the openclaw codebase and audit the usage of deleteSession to identify any potential misuse or unexpected invocations.

OpenClaw Session Sandbox Escape Vulnerability (CVE-2026-32918)

hello@craftedsignal.io — Sun, 29 Mar 2026 13:17:00 +0000

CVE-2026-32918 affects OpenClaw versions prior to 2026.3.11. The vulnerability resides in the session_status tool, which is intended to manage sandboxed subagents. However, a flaw allows these sandboxed agents to bypass their intended restrictions and access session data belonging to parent or sibling sessions. An attacker can exploit this by supplying arbitrary sessionKey values, enabling them to read and modify sensitive session data, including persisted model overrides, far beyond the…

Moby Authorization Plugin Bypass via Oversized Request Bodies

hello@craftedsignal.io — Fri, 27 Mar 2026 17:44:58 +0000

A vulnerability exists in Moby (Docker) that can be exploited to bypass authorization plugins (AuthZ) when processing API requests. This vulnerability occurs because the Docker daemon may forward a request to an authorization plugin without the request body if the body is oversized. This incomplete fix for CVE-2024-41110 allows an attacker to craft a specific API request that triggers this behavior. This could lead to an AuthZ plugin making incorrect authorization decisions, potentially allowing unauthorized actions to be performed. This affects deployments that rely on AuthZ plugins that inspect the request body for access control. The vulnerable packages include go/github.com/moby/moby (versions prior to 29.3.1), go/github.com/docker/docker (versions prior to 29.3.1), and go/github.com/moby/moby/v2 (versions prior to 2.0.0-beta.8).

Attack Chain

Attacker identifies a Docker environment utilizing an AuthZ plugin that relies on request body inspection for authorization.
Attacker crafts a malicious Docker API request targeting a sensitive resource or action.
The attacker inflates the request body to exceed a size threshold that triggers the bypass behavior.
The Docker daemon receives the oversized API request.
Due to the vulnerability, the Docker daemon forwards the request to the AuthZ plugin without the request body.
The AuthZ plugin, lacking the request body, makes an authorization decision based on incomplete information.
The AuthZ plugin, unable to properly validate the request, grants access to the sensitive resource or action.
The attacker successfully executes the unauthorized action, bypassing the intended security controls.

Impact

This vulnerability primarily impacts Docker environments that utilize authorization plugins and rely on request body inspection for access control decisions. If exploited successfully, an attacker can bypass the intended authorization mechanisms, potentially leading to unauthorized access to sensitive resources, data breaches, or other malicious activities within the containerized environment. The severity is high for affected installations, however, the base likelihood of exploitation is low, and only impacts those using AuthZ plugins.

Recommendation

Upgrade to Moby version 29.3.1 or later to address the vulnerability. This resolves the incomplete fix for CVE-2024-41110 and prevents the AuthZ bypass.
For environments where immediate upgrades are not possible, avoid using AuthZ plugins that rely on request body inspection for security decisions as described in the overview.
Restrict access to the Docker API to trusted parties following the principle of least privilege to reduce the attack surface.

Unscoped API Keys in AI Agent Frameworks

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

A recent audit of 30 popular AI agent frameworks, including OpenClaw, AutoGen, CrewAI, LangGraph, MetaGPT, and AutoGPT, reveals a widespread lack of robust authorization mechanisms. The report, published in March 2026, highlights that 93% of these frameworks rely solely on unscoped API keys for authentication. This means that any agent with access to the API key has full privileges, creating significant security risks. Furthermore, none of the frameworks provide per-agent cryptographic identity or revocation capabilities. In multi-agent systems, child agents inherit the full credentials of their parent agents, with no option for scope narrowing. This lack of granular control and isolation can lead to significant security breaches, including credential exposure and privilege escalation, as demonstrated by the 21,000 exposed OpenClaw instances leaking credentials and the 1.5 million API tokens exposed in the Moltbook breach.

Attack Chain

Attacker gains access to an unscoped API key, either through exposed instances like the 21,000 OpenClaw instances or breaches like the Moltbook incident affecting 1.5 million tokens.
The attacker leverages the unscoped API key to authenticate to the AI agent framework.
The attacker uses the API key to control an AI agent, potentially injecting malicious goals or code.
In multi-agent systems, the attacker exploits the inherited privileges of child agents to gain broader access.
The attacker leverages the agent’s capabilities to access sensitive data or perform unauthorized actions.
The attacker escalates privileges by exploiting vulnerabilities within the agent framework or underlying system.
The attacker uses the compromised agent to move laterally within the system or network.
The attacker achieves their objective, which could include data theft, system disruption, or further compromise of the environment.

Impact

The widespread use of unscoped API keys and lack of proper authorization in AI agent frameworks creates a significant security risk. Successful exploitation can lead to data breaches, system compromise, and reputational damage. The report cites real-world incidents, including 21,000 exposed OpenClaw instances leaking credentials and 1.5 million API tokens exposed in the Moltbook breach, demonstrating the potential for widespread impact. The lack of per-agent revocation means that if one agent is compromised, the API key for all agents must be rotated, causing significant disruption.

Recommendation

Implement network monitoring to detect unusual traffic patterns originating from AI agent servers. Analyze outbound connections for connections to unusual or malicious domains (grantex.dev).
Audit the configuration of AI agent frameworks to identify instances using unscoped API keys. Prioritize upgrading or replacing frameworks that lack proper authorization controls.
Deploy the Sigma rule for detecting API key usage in command-line arguments or environment variables to identify potential credential exposure.
Monitor for access to sensitive data or resources by AI agents and implement least-privilege access controls.
Implement regular security audits and penetration testing of AI agent frameworks to identify and address vulnerabilities.

Argo Workflows ConfigMap Sync Service Missing Authorization Vulnerability

hello@craftedsignal.io — Fri, 03 May 2024 16:23:00 +0000

Argo Workflows, a Kubernetes-native workflow engine, is vulnerable to an authorization bypass in its Sync Service’s ConfigMap-backed provider. This vulnerability, present in versions 4.0.0 through 4.0.4, stems from a lack of authorization checks on CRUD operations performed on ConfigMaps. This means that any authenticated user, even with a fake Bearer token, can create, read, update, and delete Kubernetes ConfigMaps used for synchronization limits. This flaw allows attackers to potentially disrupt workflow execution, access sensitive configuration data, or even manipulate ConfigMaps in namespaces accessible to the server’s service account. The vulnerability was reported on May 4, 2026, and poses a significant risk to Argo Workflows deployments.

Attack Chain

Attacker gains network access to the Argo Server.
Attacker authenticates to the Argo Server using any valid or even a “fake” Bearer token (e.g., fake-token).
Attacker crafts a POST request to the /api/v1/sync/default endpoint to create a new Sync Limit ConfigMap with specified parameters like namespace, ConfigMap name, key, and limit.
The Argo Server’s configMapSyncProvider.createSyncLimit function executes without performing any authorization checks.
The function uses the Kubernetes client to create a ConfigMap in the specified namespace based on the attacker’s input.
Attacker can subsequently send GET, PUT, or DELETE requests to /api/v1/sync/default/{key} to read, update, or delete existing Sync Limit ConfigMaps without authorization.
The Argo Server processes these requests, modifying the ConfigMaps accordingly, due to the missing auth.CanI checks.
The attacker disrupts workflow execution, gains access to sensitive configuration data, or manipulates ConfigMaps, leading to denial of service or other malicious outcomes.

Impact

Successful exploitation of this vulnerability allows an attacker with network access to the Argo Server and valid or fake authentication credentials to perform several malicious actions. They can cause a denial of service by setting sync limits to zero or a very low number, effectively blocking parallel workflow execution. Attackers can also disrupt running workflows by modifying existing sync limits. Furthermore, they can gain access to sensitive information by reading ConfigMap data or manipulate ConfigMaps in any namespace accessible to the server’s service account. This could lead to complete compromise of the Argo Workflows environment.

Recommendation

Upgrade to Argo Workflows version 4.0.5 or later to patch CVE-2026-42297 and mitigate the missing authorization checks.
Monitor access logs on the Argo Server for unexpected API calls to the /api/v1/sync endpoints, especially POST, PUT, and DELETE requests, which could indicate unauthorized ConfigMap manipulation. Use the rule Argo Workflows ConfigMap Sync Service Modification to detect unauthorized modifications.
Implement network segmentation and access controls to limit network access to the Argo Server, reducing the attack surface.

Kirby CMS Missing Authorization Vulnerability

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

Kirby CMS, a file-based content management system, has a missing authorization flaw that allows authenticated users to access sensitive site, user, and role information without the necessary permissions. This vulnerability affects installations where there are potentially untrusted authenticated users. The issue stems from the lack of permission settings controlling access to the site model, users, and user roles. Specifically, the permissions site.access, user.access, users.access, user.list, and users.list were missing. This vulnerability was reported by @HuajiHD and patched in Kirby versions 4.9.0 and 5.4.0. Sites that explicitly intend all authenticated users to have read access to all site, user, and role information are not affected.

Attack Chain

An attacker obtains valid credentials for a user account with access to the Kirby Panel.
The attacker authenticates to the Kirby Panel using their credentials.
The attacker crafts a request to access the site model data. This could involve accessing specific API endpoints related to site configuration.
The attacker sends a request to list all users within the Kirby CMS.
The system, lacking proper authorization checks, returns the requested site model and user list data to the attacker.
The attacker sends a request to list existing roles, their names, descriptions, and configured permissions.
The system returns the requested role information, again bypassing intended permission restrictions.
The attacker gains unauthorized knowledge of the site structure, user accounts, and role permissions, which can be used to escalate privileges or further compromise the system.

Impact

Successful exploitation of this vulnerability allows an attacker with low-privilege Panel access to enumerate users, roles, and site configurations. This information can be used to identify privileged accounts, understand the site’s structure, and potentially escalate privileges by exploiting other vulnerabilities or misconfigurations. This impacts all Kirby sites using versions <= 4.8.0 and versions >= 5.0.0 and <= 5.3.3 where authenticated users are not fully trusted.

Recommendation

Upgrade to Kirby version 4.9.0 or 5.4.0 or later to patch the vulnerability as described in the advisory.
Review user roles and permissions after upgrading to ensure appropriate access controls are in place.
Monitor web server logs for suspicious requests targeting user and role enumeration endpoints after deploying the below rules.

ChatGPTNextWeb NextChat Improper Authorization Vulnerability (CVE-2026-7644)

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

A vulnerability, CVE-2026-7644, affects ChatGPTNextWeb NextChat up to version 2.16.1. The flaw exists within the addMcpServer function located in the app/mcp/actions.ts file. This vulnerability allows for improper authorization, potentially enabling unauthorized actions. The exploit has been publicly disclosed, increasing the risk of exploitation. The vendor was notified, but there has been no response as of the time of this writing. This vulnerability allows for remote exploitation, meaning an attacker does not need local access to the system to exploit it. Defenders should prioritize patching or mitigating this vulnerability to prevent unauthorized access and potential data breaches.

Attack Chain

Attacker identifies a ChatGPTNextWeb NextChat instance running version 2.16.1 or earlier.
Attacker sends a crafted request to the addMcpServer function in app/mcp/actions.ts.
The application fails to properly authorize the request due to the vulnerability in addMcpServer.
The attacker bypasses authorization checks.
The attacker successfully adds a malicious MCP server configuration.
The application uses the malicious MCP server configuration, potentially leading to further unauthorized actions.
Attacker gains unauthorized access to sensitive data or functionality.

Impact

Successful exploitation of CVE-2026-7644 could lead to unauthorized access to a NextChat instance. An attacker could potentially manipulate MCP server configurations, leading to further compromise of the application and associated data. Since the exploit is publicly available, the risk of exploitation is significantly elevated, potentially affecting all unpatched instances of NextChat version 2.16.1 or earlier.

Recommendation

Upgrade ChatGPTNextWeb NextChat to a version higher than 2.16.1 to patch CVE-2026-7644.
Monitor web server logs for suspicious requests targeting the addMcpServer function in app/mcp/actions.ts.
Deploy the Sigma rule to detect unauthorized calls to the addMcpServer function.