Search
Search Results (12 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-18092 | 1 Timlegge | 1 Net::saml2 | 2026-08-03 | 8.1 High |
| Net::SAML2 versions before 0.86 for Perl allow SAML authentication bypass via XML signature wrapping because new_from_xml reads assertion identity with document-wide XPath instead of the signed subtree. new_from_xml reads the NameID, attribute values, SessionIndex, audience and other identity fields with document-wide XPath, such as //saml:Assertion/saml:AttributeStatement/saml:Attribute and //saml:Subject/saml:NameID, which select the first matching element in document order rather than the element covered by the verified signature. handle_response confirms that a signature is present and, when a cacert is configured, that it chains to the CA, but XML::Sig verifies only the element named by the signature's Reference URI, so unsigned sibling assertions in the same document are not covered. An attacker who holds any one IdP-signed assertion can add an unsigned attacker-authored assertion earlier in document order; the signature still verifies and the document-order XPath returns the attacker's NameID and attributes. Any caller that passes an untrusted Response to new_from_xml can accept identity fields from an assertion the IdP never signed, even when a cacert trust anchor is configured, so a party holding one valid IdP-signed assertion can authenticate as an arbitrary user. | ||||
| CVE-2026-9487 | 1 Timlegge | 1 Xml::sig | 2026-08-03 | 9.1 Critical |
| XML::Sig versions before 0.71 for Perl allow signature wrapping via duplicate ID. _get_signed_xml() in lib/XML/Sig.pm, called from verify(), resolves the SignedInfo Reference/@URI to a node with the XPath expression "//*[@ID='$id']" and returns the first node of the resulting node set. A document in which two elements share that ID value is accepted: the digest and signature are checked against whichever element comes first in document order, and the duplicate is not detected. Such a document verifies successfully while an application that resolves the same ID independently can read the second, attacker supplied element; in a SAML2 context this places the contents of an Assertion under attacker control. | ||||
| CVE-2026-9390 | 1 Timlegge | 1 Xml::sig | 2026-08-03 | 9.1 Critical |
| XML::Sig versions before 0.71 for Perl allow XPath injection in ID lookup. verify() and _get_signed_xml() in lib/XML/Sig.pm build XPath expressions by concatenating the SignedInfo/Reference/@URI value read from the document being verified. The value is neither escaped nor checked against the NCName grammar that XML requires of an ID, so a URI containing a single quote closes the string literal in the generated expression and appends arbitrary XPath operators. A crafted URI can make the lookup match elements the reference does not name, or every element in the document, so which node is selected for digest verification is decided by the injected expression rather than by the reference. | ||||
| CVE-2026-18108 | 1 Timlegge | 1 Net::saml2 | 2026-08-03 | 9.8 Critical |
| Net::SAML2 versions before 0.86 for Perl allow authentication bypass because _verify_encrypted_assertion accepts an EncryptedAssertion whose decrypted content carries no signature. _verify_encrypted_assertion decrypts the EncryptedAssertion and returns it as verified when it carries no signature, via "return $xml unless $xpath->exists('dsig:Signature', $assert);". The signature check and the trust anchor check that follow run only when a signature is present, so a decrypted assertion with no dsig:Signature element reaches new_from_xml unverified and its NameID and attributes are read into the assertion object. An SP's encryption certificate is published in its SAML metadata so the IdP can encrypt to it, so any party can encrypt an unsigned assertion to that certificate, wrap it in a samlp:Response, and post it to the assertion consumer service. Any caller that configures a decryption key_file, and so accepts EncryptedAssertions, takes identity fields from an assertion that no trust anchor covers, and an unauthenticated party can authenticate as an arbitrary user. Callers with no key_file configured do not decrypt and are unaffected. | ||||
| CVE-2026-18089 | 1 Timlegge | 1 Net::saml2 | 2026-08-03 | 7.5 High |
| Net::SAML2 versions before 0.86 for Perl allow SAML authentication bypass by verifying responses against the response-embedded certificate in verify_xml when no trust anchor is configured. verify_xml in Net::SAML2::Role::VerifyXML runs "return if !$anchors && !$cacert;" as soon as the XML::Sig check succeeds, and that check uses the X.509 certificate taken from the response's own dsig:KeyInfo/dsig:X509Certificate element, so an unanchored response is checked only against the key it carries. Binding::POST declares cacert as an optional Maybe[Str] with no default, so a POST binding built without one takes that path, and _verify_encrypted_assertion returns early the same way with "return $xml unless $cacert;". Any caller that constructs Binding::POST or calls Assertion->new_from_xml without a cacert, cert_text, or anchors argument accepts a response signed by an attacker generated key whose self-signed certificate is embedded in that response, authenticating an arbitrary assertion. | ||||
| CVE-2026-14570 | 1 Timlegge | 1 Crypt::dsa | 2026-07-06 | 7.5 High |
| Crypt::DSA versions before 1.22 for Perl draw the DSA signing nonce and private key from a biased random generator, leading to private-key recovery. "Crypt::DSA::Util::makerandom forces the high bit of every value it returns to obtain an exactly N-bit integer for prime search. The signing nonce and the private key are drawn from makerandom. Because the high bit is always set, the result is not uniform: its top bit is fixed, producing insecure values." An attacker who collects a modest number of signatures under an affected key, together with the public key, can recover the private key with a lattice attack. Keys used to sign with an affected version should be considered compromised and new keys should be generated. | ||||
| CVE-2026-12205 | 1 Timlegge | 1 Crypt::dsa | 2026-06-17 | 9.1 Critical |
| Crypt::DSA versions before 1.21 for Perl reused the nonce across signatures, leading to private-key recovery. Crypt::DSA::sign caches the per-signature nonce material in the Key object without ever clearing it. The first sign() on a Key object picks a nonce, and every later sign() on that same object reuses it, producing an identical "r". Keys used to sign more than once with an affected version should be considered compromised. | ||||
| CVE-2026-8704 | 1 Timlegge | 1 Crypt::dsa | 2026-05-18 | 6.5 Medium |
| Crypt::DSA versions through 1.19 for Perl use 2-args open, allowing existing files to be modified. | ||||
| CVE-2026-8700 | 1 Timlegge | 1 Crypt::dsa | 2026-05-18 | 7.3 High |
| Crypt::DSA versions before 1.20 for Perl generate seeds using rand. Seeds were generated using Perl's built-in rand function, which is predictable and unsuitable for security usage. | ||||
| CVE-2026-2588 | 1 Timlegge | 2 Crypt::nacl::sodium, Crypt\ | 2026-04-17 | 9.1 Critical |
| Crypt::NaCl::Sodium versions through 2.001 for Perl has an integer overflow flaw on 32-bit systems. Sodium.xs casts a STRLEN (size_t) to unsigned long long when passing a length pointer to libsodium functions. On 32-bit systems size_t is typically 32-bits while an unsigned long long is at least 64-bits. | ||||
| CVE-2026-30909 | 1 Timlegge | 2 Crypt::nacl::sodium, Crypt\ | 2026-04-16 | 9.8 Critical |
| Crypt::NaCl::Sodium versions through 2.002 for Perl has potential integer overflows. bin2hex, encrypt, aes256gcm_encrypt_afternm and seal functions do not check that output size will be less than SIZE_MAX, which could lead to integer wraparound causing an undersized output buffer. Encountering this issue is unlikely as the message length would need to be very large. For bin2hex() the bin_len would have to be > SIZE_MAX / 2 For encrypt() the msg_len would need to be > SIZE_MAX - 16U For aes256gcm_encrypt_afternm() the msg_len would need to be > SIZE_MAX - 16U For seal() the enc_len would need to be > SIZE_MAX - 64U | ||||
| CVE-2025-1828 | 1 Timlegge | 1 Crypt\ | 2025-09-29 | 8.8 High |
| Crypt::Random Perl package 1.05 through 1.55 may use rand() function, which is not cryptographically strong, for cryptographic functions. If the Provider is not specified and /dev/urandom or an Entropy Gathering Daemon (egd) service is not available Crypt::Random will default to use the insecure Crypt::Random::rand provider. In particular, Windows versions of perl will encounter this issue by default. | ||||
Page 1 of 1.