Signature-Bypass — CraftedSignal Threat Feed

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.

Stripe Webhook Signature Bypass via Empty Secret Enables Unlimited Quota Fraud

hello@craftedsignal.io — Fri, 24 Apr 2026 15:43:25 +0000

A critical vulnerability exists in the Stripe webhook handler that allows an unauthenticated attacker to forge webhook events and credit arbitrary quota to their account without making any payment. Disclosed on 2025-04-15 and patched the same day in v0.12.10, the vulnerability stems from three compounding flaws: the Stripe webhook endpoint does not reject requests when StripeWebhookSecret is empty (the default), any attacker can compute valid webhook signatures when the HMAC secret is empty, and the Recharge function does not validate that the order’s PaymentMethod matches the callback source. This enables cross-gateway exploitation where orders created via any payment method can be fulfilled through a forged Stripe webhook. This vulnerability allows for financial fraud through unlimited API quota acquisition without payment.

Attack Chain

Attacker registers a user account on the target platform.
Attacker calls POST /api/user/pay to create an Epay top-up order, setting the amount. The order is stored with a pending status.
Attacker queries GET /api/user/topup/self to retrieve the trade_no of the pending order.
Attacker computes an HMAC-SHA256 signature with an empty key over a crafted checkout.session.completed payload. This payload contains the stolen trade_no as the client_reference_id.
Attacker sends a POST request to /api/stripe/webhook with the forged payload and a crafted Stripe-Signature header.
The server verifies the signature, which passes because the StripeWebhookSecret is empty.
The server calls the Recharge() function, which finds the Epay order by trade_no, marks the order as success, and credits the attacker’s account with the full quota.
The attacker repeats steps 2-6 indefinitely to accumulate unlimited credits, leading to financial fraud.

Impact

This vulnerability allows attackers to obtain unlimited API quota without payment, leading to financial fraud. The operator of the vulnerable system faces financial losses due to fraudulent quota consumption against upstream AI providers such as OpenAI, Anthropic, and Google. The fraudulent top-ups can appear as normal transactions in system logs, making detection challenging. Due to the default insecure configuration, virtually all deployments with any payment method enabled are vulnerable, creating a wide exposure.

Recommendation

Set StripeWebhookSecret to a non-empty value to prevent empty-key HMAC forgery, mitigating the primary attack vector (Flaw 1).
Apply a reverse proxy (Nginx, Caddy, etc.) to deny access to /api/stripe/webhook if Stripe is not configured, as a temporary workaround.
Deploy the Sigma rule Detect Forged Stripe Webhook Request to identify potential exploitation attempts by monitoring requests to the webhook endpoint with empty secrets or invalid signatures.
Upgrade to v0.12.10 immediately, as it addresses all three flaws completely.

ASP.NET Core Improper Signature Verification Vulnerability (CVE-2026-40372)

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

CVE-2026-40372 describes a critical vulnerability affecting ASP.NET Core applications. This flaw arises from the improper verification of cryptographic signatures, creating an avenue for unauthorized attackers to elevate their privileges within a network. Successful exploitation of this vulnerability could grant attackers significant control over affected systems. According to the NVD, the CVE was published on April 21, 2026. Given the severity of privilege escalation and the potential for widespread impact on ASP.NET Core deployments, this vulnerability poses a significant risk and demands immediate attention from security teams. The vulnerability is referenced by Microsoft in their advisory related to CVE-2026-40372.

Attack Chain

Attacker identifies an ASP.NET Core application vulnerable to CVE-2026-40372.
The attacker crafts a malicious request containing a tampered cryptographic signature.
The vulnerable ASP.NET Core application fails to properly verify the cryptographic signature due to the flaw described in CVE-2026-40372.
The application processes the malicious request as if it were legitimate, bypassing authentication or authorization checks.
The attacker leverages the bypassed checks to gain access to sensitive functions or data.
Attacker escalates privileges within the ASP.NET Core application context.
The attacker leverages the elevated privileges to perform unauthorized actions, such as modifying data, executing code, or accessing restricted resources.
The attacker achieves full control of the compromised ASP.NET Core application and potentially the underlying server, depending on application permissions and configuration.

Impact

Successful exploitation of CVE-2026-40372 can lead to complete compromise of affected ASP.NET Core applications. An attacker gaining elevated privileges can modify sensitive data, execute arbitrary code, or disrupt services. Given the widespread use of ASP.NET Core in web applications across various sectors, the potential impact is substantial. The vulnerability’s critical severity (CVSS 9.1) highlights the high risk it poses to organizations relying on ASP.NET Core.

Recommendation

Apply the security update provided by Microsoft to address CVE-2026-40372 as detailed in the Microsoft advisory [https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-40372].
Deploy the Sigma rule “Detect Suspicious ASP.NET Core Request” to identify potential exploitation attempts in web server logs.
Review ASP.NET Core application configurations to minimize the potential impact of privilege escalation.
Enable web server logging to capture detailed information about incoming requests, aiding in the detection and investigation of exploitation attempts (webserver category).

Jsrsasign < 11.1.1 Incorrect Conversion Vulnerability (CVE-2026-4602)

hello@craftedsignal.io — Mon, 23 Mar 2026 06:16:22 +0000

Jsrsasign is a free open source cryptography library for JavaScript. Versions before 11.1.1 contain an incorrect conversion between numeric types due to improper handling of negative exponents in the ext/jsbn2.js file. This vulnerability, identified as CVE-2026-4602, allows an attacker to force the computation of incorrect modular inverses, leading to the potential breakage of signature verification. The vulnerability was reported and patched in March 2026. This could allow an attacker to…