CVE-2026-7557 is a critical vulnerability in Progress Software Corporation's MarkLogic Server affecting versions 11.0.0 and 12.0.0. It involves improper verification of cryptographic signatures in the SAML authentication module, allowing unauthenticated remote attackers to bypass authentication and impersonate any user, including administrators. This vulnerability only affects deployments with SAML single sign-on enabled.
Misskey versions 12.37.0 up to but not including 2026.5.4 contain a vulnerability in the JSON-LD signature validation and compaction process. This flaw allows spoofed activities to be accepted as valid due to improper verification of cryptographic signatures. The issue is fixed in version 2026.5.4. The vulnerability has a high severity with a CVSS 4.0 score of 9.2, indicating critical impact if exploited.
XML::Sig versions from 0.29 before 0.72 for Perl allow signature verification bypass because verify returns true when every signature was skipped before any cryptographic check.
verify in lib/XML/Sig.pm counts the `//dsig:Signature` elements into `$numsigs` and iterates over them, but two paths reach `next` before any digest or key check runs: a `SignedInfo/Reference/@URI` that resolves to no element while `$numsigs` is greater than 1, and, when `id_attr` is set, a reference that does not match the requested ID. The loop records nothing about what it checked, so when every signature takes one of those paths control reaches the unconditional `return 1` that ends verify. Two `Signature` elements whose Reference URI names an ID that no element carries is enough, as is one such element combined with `id_attr`.
Any caller that passes untrusted XML to verify can receive a true return for a document in which no digest and no signature value was checked; a `cert` or `cert_text` trust anchor does not change this, because no key check runs. Versions up to 0.28 use an XML::XPath based verify that has no such skip and are not affected.
Net::SAML2 versions before 0.86 for Perl contain a vulnerability that allows SAML authentication bypass via XML signature wrapping. The issue arises because the new_from_xml function reads identity fields using document-wide XPath expressions rather than restricting to the signed subtree, enabling attackers to inject unsigned assertions that appear valid. This flaw allows an attacker with a valid IdP-signed assertion to authenticate as any arbitrary user.
XML::Sig versions before 0.71 for Perl contain a critical vulnerability that allows signature wrapping via duplicate ID values. The _get_signed_xml() function resolves SignedInfo Reference/@URI by selecting the first node with a matching ID, but does not detect if multiple elements share that ID. This can cause a document with duplicate IDs to verify successfully while an attacker controls the second element, potentially compromising SAML2 assertions.
Net::SAML2 versions before 0.86 for Perl contain a critical vulnerability that allows authentication bypass. The vulnerability arises because the _verify_encrypted_assertion function accepts encrypted assertions without verifying cryptographic signatures if no signature element is present. This allows unauthenticated attackers to forge assertions encrypted to a service provider's encryption certificate and authenticate as arbitrary users. Systems that do not configure a decryption key_file are not affected.
Net::SAML2 versions before 0.86 for Perl contain a vulnerability that allows SAML authentication bypass. The verify_xml function verifies responses against a certificate embedded within the response itself when no trust anchor is configured, enabling attackers to authenticate arbitrary assertions using self-signed certificates. This occurs because the code returns early if no trust anchors or CA certificates are provided, trusting the embedded certificate without external validation.
eParakstītājs 3.0 for Windows before version
1.10.0 retrieves and executes its automatic updates over a channel that is not
authenticated or integrity-protected. On each launch the application fetches an
update descriptor (XML) over TLS but accepts any TLS certificate (a permissive
TrustManager and a HostnameVerifier that always returns true), does not verify
any digital signature on the update descriptor, and does not verify the
Authenticode signature or a checksum of the downloaded installer before running
it. A man-in-the-middle attacker able to redirect www.eparaksts.lv can serve a
crafted update descriptor pointing to an attacker-controlled executable, which
the client downloads and executes, resulting in arbitrary code execution on the
victim host.
CVE-2026-12860 is a high-severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library affecting versions before 1.85 and LTS versions before 2.73.12. The flaw involves improper verification of RSA PKCS#1 cryptographic signatures, where the last two hash bytes are skipped in the NULL-omitted verification path. This can lead to incorrect signature validation.
CVE-2026-59639 is a high severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library. The issue occurs in versions before 1.85 and certain 2.73.x versions, where the CMS verifySignatures method incorrectly returns true for SignedData objects that have zero signers. This improper verification of cryptographic signatures can undermine the trustworthiness of signature validation in affected versions.
CVE-2026-59643 is a high-severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library affecting versions 1.81 through before 1.85. The issue involves improper verification of cryptographic signatures, specifically OpenPGP inline-signature policy failures that are silently ignored. This flaw also impacts the Bouncy Castle for Java FIPS (BC-FJA) before version bcpg-fips 2.0.13. The vulnerability could allow attackers to bypass signature verification checks, undermining cryptographic assurances.
Improper Verification of Cryptographic Signature in ueberauth guardian allows an unauthenticated attacker to revoke a victim's session with a forged token.
Guardian.revoke/3 in lib/guardian.ex decodes the supplied token with peek/1, which performs no signature verification (it only base64-decodes the JWT header and payload). The resulting unverified claims are forwarded directly to the configured token module's revoke callback and the implementation's on_revoke callback, a state-mutating sink. The sibling operations refresh/2 and exchange/4 both call decode_and_verify first, so the signature is checked before anything acts on the claims; revoke/3 is the only state-mutating path that acts on claims without verifying the signature.
An attacker who knows or guesses a victim's identifying claim values (jti, sub) can forge a JWT carrying those claims, sign it with an arbitrary key, and submit it to any endpoint that funnels a caller-supplied token into Guardian.revoke/3 (the standard logout / session-revocation pattern). When the token module mutates state keyed by the claims (whitelist deletion or blacklist insertion, for example a GuardianDb-style store), the victim's legitimate session is evicted. This is an unauthenticated session-revocation denial of service; the attacker never needs the signing secret.
This issue affects guardian: from 1.0.0 before 2.4.1.
The firmware update process for the basemodule of the charging controller only validates the
CRC32 checksum without cryptographic signature verification. This allows an unauthenticated remote attacker to install a modified firmware, resulting in full system compromise.
CVE-2026-13305 is a vulnerability in the Autel MaxiCharger AC Elite Home EV charger software update process. It involves improper verification of cryptographic signatures on software update images, allowing a physically present attacker to execute arbitrary code without authentication. The flaw affects version 1.39.51 of the product and has a CVSS 3.0 base score of 6.4, indicating medium severity.
The FAB auth manager's Azure AD OAuth login defaulted `verify_signature=False` when decoding the ID token, so an attacker able to present a forged or unsigned (`alg:none`) ID token to the OAuth callback could bypass authentication and log in as an arbitrary user, including one holding the Admin role (CWE-347). Deployments running the FAB auth manager with the Azure AD OAuth login path under its default configuration are affected; the Authentik path already defaulted to `True`. This issue affects `apache-airflow-providers-fab` before 3.7.3. Users are advised to upgrade to `apache-airflow-providers-fab` 3.7.3, which defaults `verify_signature=True`.
Multiple Lenze products are affected by an improper signature verification vulnerability in the SSH enablement mechanism. A low-privileged local attacker can bypass verification of the SSH enable file signature and enable SSH access on the device. Successful exploitation may result in unauthorized administrative access and complete system compromise.
In epa4all, prior to version 2026-05-20, an attacker who can intercept the TLS connection between epa4all and the ePA backend can complete the VAU handshake with attacker-controlled keys and obtain the session encryption keys. All inner HTTP traffic (patient consent decisions, medication data, document operations, authorization tokens, and entitlement queries) becomes readable and modifiable. The attacker can also inject arbitrary requests through the hijacked channel. This issue has been patched in version 2026-05-20.
OIDC::Lite versions through 0.12.1 for Perl allow ID Token signature verification bypass via a token-controlled algorithm allowlist in verify.
When the caller does not pin an algorithm, OIDC::Lite::Model::IDToken::verify sets $self->alg($self->header->{alg}) from the token's own header and then calls decode_jwt(token, key, 1, [$self->alg]), handing JSON::WebToken an accepted-algorithm allowlist taken from the untrusted token. A token with alg=none yields ['none'], so decode_jwt returns the claims with no signature check, and a token with alg=HS256 is verified with the RP's RSA public key as the HMAC secret (RS to HS confusion).
The ID Token is the OpenID Connect authentication assertion delivered to the Relying Party. Any caller that verifies an ID Token through the unpinned load(token)->verify path, or load(token, key) with only the key pinned, accepts a forged token carrying attacker-chosen claims such as sub and is authenticated as any user. Passing an explicit algorithm so $self->alg is already set bypasses the header-derived allowlist and is not affected.
Note that the latest version uploaded to CPAN is 0.10. Later versions are available in the git repository.
BIND may accept incorrect child-zone NSEC3 records as valid, which could allow an attacker to forge authenticated NXDOMAIN responses.
This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.