Export limit exceeded: 16528 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (104 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-88816 | 1 Perl | 1 Dbi | 2026-09-30 | 7.5 High |
| DBI versions before 1.654 for Perl incorrectly treat numeric values as strings in FetchHashKeyName. fetchrow_hashref uses the string pointer of the FetchHashKeyName attribute as the key name without stringifying it first. When FetchHashKeyName has been set to an integer (IV) or floating-point (NV) value, that pointer is invalid, so reading the key name triggers a segmentation fault. This can be triggered with the following code: my $dbh = DBI->connect( "dbi:ExampleP:", "", "", { RaiseError => 0, PrintError => 0 } ); $dbh->{FetchHashKeyName} = 42; my $sth = $dbh->prepare("select mode, size, name from ."); $sth->execute; $sth->fetchrow_hashref; | ||||
| CVE-2026-85644 | 1 Perl | 1 Xs::parse::infix | 2026-09-30 | 7.5 High |
| XS::Parse::Infix versions from 0.40 through 0.49 for Perl treat a number as an array reference. The wrapper function XS::Parse::Infix generates for a list-associative infix operator checks whether arguments are array references, but it tests using SvRV() rather than SvROK(). SvRV() reads a union slot that only holds a referent once SvROK(sv) is true, so the guard never validates that it is a reference. For an IV or NV that slot holds the number itself, SvRV() returns the caller's value and SvTYPE() dereferences it at offset 12. This will generally result in a segmentation fault. An application that hands the wrapper a list built from decoded input (for example, from JSON) lets whoever supplies a number in that list choose the address that the interpreter dereferences. An ordinary string's byte 12 is rarely SVt_PVAV so the guard croaks by luck, but an attacker-crafted string carrying 0x0b there passes, and the buffer is then used as an AV head, with AvARRAY taken from bytes 16-23 and its entries pushed onto the Perl stack as live SVs. A simple proof-of-concept uses the zip operator: use Syntax::Operator::Zip 'zip'; my @args = ([1], 2); zip(@args); | ||||
| CVE-2026-82560 | 1 Perl | 1 Pod::text | 2026-09-29 | 7.5 High |
| Pod::Text versions before 6.1.1 for Perl allow CPU and memory exhaustion formatting a POD document whose =over nesting drives the margin to the output width. Each =over adds its indent to the margin, which wrap() subtracts from the output width to get the space available for text. When that space reaches zero, the line-splitting substitution matches the empty string, and the loop consumes no input while appending the margin padding on every pass. Formatting an attacker-supplied POD document never returns, and the output grows until memory is exhausted. | ||||
| CVE-2016-15059 | 1 Perl | 1 Net::idn::punycode | 2026-09-29 | 9.8 Critical |
| Net::IDN::Punycode versions before 2.301 for Perl allow a heap buffer overflow via unchecked writes past the output buffer in encode_punycode. The XS backend builds the encoded label in the string buffer of the scalar it returns, sized from the input length. The loop that emits the digits of each code point checks for room before every write, but the write of the last digit of each round and the write of the terminating NUL do not, so an input whose encoded form fills the buffer writes past its end. Only the XS backend is affected. Encoding an attacker-supplied string corrupts the heap. | ||||
| CVE-2026-74765 | 1 Perl | 1 Net::idn::punycode | 2026-09-29 | 6.5 Medium |
| Net::IDN::Punycode versions before 2.590 for Perl allow an out-of-bounds read via integer overflow of the delta accumulator in encode_punycode. The XS backend keeps the punycode delta, and the digit index derived from it, in a signed int. The accumulation `delta += (m-n) * (h+1)` has no overflow check, so a large enough code point wraps the delta and the digit index leaves the range of the 36-entry digit table. The bound before the final table access tests only for an index above 36, so a negative index passes it, as does 36 itself. Perl strings hold code points beyond the Unicode range, and one such code point overflows the accumulation on its own. Valid input wraps it as well, for example 1927 ASCII letters followed by U+10FFFF. The conversion functions encode a label before they check its length, so a long label reaches the encoder through the documented API. Only the XS backend is affected. Encoding an attacker-supplied string copies a byte from outside the digit table into the encoded result or crashes the process. | ||||
| CVE-2026-74766 | 1 Perl | 1 Net::idn::punycode | 2026-09-29 | 8.4 High |
| Net::IDN::Punycode versions from 2.301 before 2.590 for Perl allow a heap use-after-free via a decoded code point that reallocates the output buffer in decode_punycode. The XS backend inserts each decoded code point into the string buffer of the scalar it returns. decode_punycode computes the insertion pointer first and only then grows the buffer when the code point does not fit. The growth reallocates the buffer and updates every pointer except the insertion pointer, so the move that follows and the write of the code point go through a freed pointer. The buffer starts at twice the label length, and a code point above U+FFFF takes four bytes in the output, so a label of such code points outgrows it and forces the reallocation. Version 2.301, the fix for CVE-2016-15059, introduced the defect. Only the XS backend is affected. Decoding an attacker-supplied punycode label reads and writes freed heap memory. | ||||
| CVE-2026-87078 | 1 Perl | 1 Net::idn::punycode | 2026-09-29 | 9.1 Critical |
| Net::IDN::Punycode versions from 2.302 before 2.590 for Perl leak the output buffer on every rejected label in decode_punycode. The XS backend allocates the scalar it returns before it validates the input, sizing the buffer at twice the input length. The scalar is released only on the success path, so each of the three croaks that reject a label leaves the scalar and its buffer allocated. Nothing bounds the label length in the to-Unicode direction, since the 63-byte DNS limit is checked only when converting to ASCII. Only the XS backend is affected. A sender who supplies invalid labels grows the process by twice the label length per rejected call, with no successful call needed. | ||||
| CVE-2026-87079 | 1 Perl | 1 Net::idn::punycode | 2026-09-29 | 7.5 High |
| Net::IDN::Punycode versions before 2.590 for Perl allow CPU exhaustion via quadratic insertion cost when decoding a long label in decode_punycode. The XS backend inserts each decoded code point into a UTF-8 buffer and finds the insertion point by scanning that buffer from the start, one character at a time. The scan runs once per code point over the output built so far, so the cost is quadratic in the label length. The pure-Perl backend downgrades its input to bytes so that substr can index it directly, but takes its working copy before the downgrade, so when the input carries the UTF-8 flag every substr on the copy scans from the start, with the same quadratic cost. Nothing bounds the label length in the to-Unicode direction. The 63-byte DNS limit is checked only when converting to ASCII, so domain_to_unicode and uts46_to_unicode pass an attacker-supplied label of any length to the decoder. | ||||
| CVE-2026-87080 | 1 Perl | 1 Net::idn::punycode | 2026-09-29 | 9.1 Critical |
| Net::IDN::Punycode::PP versions before 2.590 for Perl decode a truncated label to a name containing a character it never encoded in decode_punycode. The pure-Perl decoder reads one digit at a time with four-argument substr and tests the result with defined to detect the end of the input. substr on an exhausted string returns the empty string rather than undef, so decoding continues past the end. The empty string converts to a digit value below the range, reducing the accumulator, and the decoder derives one extra code point and its position from it. The result is deterministic. The XS backend rejects the same label. Net::IDN::Punycode uses this backend wherever the XS does not build. The two backends disagree about what such a label means, so a sender can pick a label that one installation resolves to a name and another rejects. | ||||
| CVE-2026-87081 | 1 Perl | 1 Net::idn::uts46 | 2026-09-29 | 7.5 High |
| Net::IDN::UTS46 versions before 2.590 for Perl allow CPU exhaustion via quadratic punycode encoding of an overlong label before the length check in to_ascii. to_ascii punycode encodes each label and only then applies the 63-byte DNS limit. encode_punycode in both backends follows the sample implementation in RFC 3492, whose outer loop runs once per distinct non-ASCII code point and scans the whole input each round, so a label of distinct non-ASCII characters costs the square of its length before the limit rejects it. Every ASCII conversion in the distribution, including domain_to_ascii and email_to_ascii, goes through to_ascii. | ||||
| CVE-2026-87082 | 1 Perl | 1 Net::idn::punycode | 2026-09-29 | 7.5 High |
| Net::IDN::Punycode versions before 2.590 for Perl hang, crash or return a wrong label via unvalidated malformed UTF-8 in encode_punycode. Neither backend checks that its input is well-formed UTF-8, so a string with the UTF-8 flag set over malformed bytes, as the :utf8 PerlIO layer produces from any malformed input, reaches the encoder unchecked. On perl 5.32 and later the XS backend reports a malformed sequence with a length of `(STRLEN)-1`, so the scan steps back one byte instead of forward and never ends. On earlier perls the XS returns a valid label for a different name. The pure-Perl backend runs a regex over the flagged string. Depending on the bytes, it aborts with SIGBUS on perl 5.28 and later, dies with a panic, or returns a wrong label. The documented conversion functions match the label against Unicode properties first and that match dies on such a string, so only a direct call to encode_punycode reaches the defect. The decoder is not affected. A direct caller encoding attacker-supplied bytes hangs, crashes or gets a label for a name the input never held. | ||||
| CVE-2026-85491 | 1 Perl | 1 Catalyst::seal | 2026-09-28 | 8.8 High |
| Catalyst::Seal versions before 0.03 for Perl allow one request to disable a path or route a later one past an authorization check via a dispatch memo keyed on the request path alone. Catalyst::Seal replaces the dispatcher's prepare_action with a version that memoises how a path resolved: which dispatch type matched, at which level, and what was left over as arguments. The key is the request path and nothing else. Action roles that match on the method, content type, scheme or query make that resolution depend on state the key does not carry, so the memo answers for a request it was not built from. A path that resolves to no action is memoised as well, and replaying that entry returns without consulting any dispatch type, so no action is set and the request fails. A GET of a path whose action is declared POST-only therefore disables that path for every later request, the correct POST included. An entry that did resolve replays the level the earlier descent reached. Where a POST-only action sits below a shallower action on the same path, a GET memoises the shallow route, and a later POST is dispatched there with an auto() guarding the deeper controller never running. The memo is cleared only when an action is registered, which happens at setup, so an entry lasts for the life of the process, and its cap of 2048 entries bounds how many paths one caller can disable. In the configuration measured, the misroute lands on the less privileged action, so it is an authorization check not running rather than a privilege gain. | ||||
| CVE-2026-97230 | 1 Perl | 1 Io::socket::ssl::selfcertificate | 2026-09-28 | 9.8 Critical |
| IO::Socket::SSL::SelfCertificate versions 1.00 for Perl contains malware which executes Python code from an obfuscated URL. The generate_certificate runs a Python script saved as a certificate file. The pyhton script attempts to retrieve code from a hardcoded http URL that is obfuscated with base64 encoding and run the response body directly. The impact is that arbitrary code can be invoked as the user, without a dropped script being saved on the affected host. The releases have no test scripts nor build hooks. The intention may have been to trigger the payload after installation. The dropper script is in lib/Crypt/SelfCertificate/sample/cert.pem. This is similar to CVE-2026-95831 for the module Crypt::SelfCertificate. The SHA-256 digests of the files are ba24ee8ec3b7f47f65bed62e16fb413ace50653cf44bd8ea90914390922831e0 IO-Socket-SSL-SelfCertificate-1.00.tar.gz 821d38830e5eb8607738421c25ac25f59fff02a6ab67daa32fbd020429454dac IO-Socket-SSL-SelfCertificate-1.00/lib/IO/Socket/SSL/SelfCertificate/sample/cert.pem d483cb7b23b7271cb11cf242bff4a2e1c02df0b9525eb0429abeea8961c399d5 IO-Socket-SSL-SelfCertificate-1.00-upload.tar.gz | ||||
| CVE-2026-95831 | 1 Perl | 1 Crypt::selfcertificate | 2026-09-23 | 7.8 High |
| Crypt::SelfCertificate versions from 1.01 through 1.05 for Perl contains malware which executes Python code from an obfuscated URL. The generate_certificate runs a Python script saved as a certificate file. The pyhton script attempts to retrieve code from a hardcoded http URL that is obfuscated with base64 encoding and run the response body directly. The impact is that arbitrary code can be invoked as the user, without a dropped script being saved on the affected host. The releases have no test scripts nor build hooks. The intention may have been to trigger the payload after installation. For version 1.01, the dropper script is in lib/Crypt/SelfCertificate/sample/validate.p12. For version 1.05, the dropper script is in lib/Crypt/SelfCertificate/sample/cert7.pem. The SHA-256 digests of the files are fbff21f45ff748365062a5e36fb2d72558cad82a507a6f357f320b4fcdf07760 Crypt-SelfCertificate-1.01.tar.gz 27b2d2d3174ad771474fff2521f5084ec231e9218ea8c832515aef1cbd5897bc lib/Crypt/SelfCertificate/sample/validate.p12 9fdfa7d69b034b77d4510cda567e8da1e486ca81c7daaadc5732a45c41d71991 Crypt-SelfCertificate-1.05.tar.gz 27b2d2d3174ad771474fff2521f5084ec231e9218ea8c832515aef1cbd5897bc lib/Crypt/SelfCertificate/sample/cert7.pem | ||||
| CVE-2026-8376 | 2 Perl, Shay | 2 Perl, Perl | 2026-09-08 | 7.3 High |
| Perl versions before 5.40.5-RC1, from 5.41.0 before 5.42.3-RC1, from 5.43.0 before 5.43.11 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time. | ||||
| CVE-2026-57432 | 2 Perl, Shay | 2 Perl, Perl | 2026-09-08 | 8.4 High |
| Perl versions before 5.40.5-RC1, from 5.41.0 before 5.42.3-RC1, from 5.43.0 before 5.43.11 have an integer overflow in S_measure_struct leading to an out-of-bounds heap read in pack and unpack. S_measure_struct adds each item's size times its repeat count to a running total with no overflow check, so a large repeat count in a pack or unpack template wraps the signed SSize_t total negative. The @, X, and x position codes then guard their moves with a signed length comparison that passes when the length is negative, advancing the buffer pointer out of bounds. A template derived from untrusted input can read heap memory past the buffer and return it to the caller. | ||||
| CVE-2026-13221 | 2 Perl, Shay | 2 Perl, Perl | 2026-09-08 | 9.1 Critical |
| Perl versions before 5.40.5-RC1, from 5.41.0 before 5.42.3-RC1, from 5.43.0 before 5.43.10 produce silently incorrect regular expression matches when an alternation of more than 65535 fixed string branches is compiled into a trie in Perl_study_chunk. When such branches are combined into a trie, the delta between the first branch and the shared tail is stored in a 16-bit field. A branch count above 65535 overflows the field, and the trie's match decision table is truncated with no warning or error. A pattern of this shape produces false positive matches (matching strings it should not) and false negative matches (failing to match strings it should). When such a pattern gates an access or filtering decision, the result is wrong. | ||||
| CVE-2026-86304 | 1 Perl | 1 Mojox::authentication | 2026-09-08 | 9.8 Critical |
| MojoX::Authentication versions before 0.006 for Perl allow SAML authentication bypass because parse_assertion builds Net::SAML2::Binding::POST without a trust anchor. parse_assertion in MojoX::Authentication::Model::SAML2 calls Net::SAML2::Binding::POST->new with no cacert, cert_text or anchors argument, then passes the returned XML to Net::SAML2::Protocol::Assertion->new_from_xml with the IdP signing certificate as cacert. In Net::SAML2 before 0.86 that certificate guards only encrypted assertions, so the signature on an unencrypted assertion is checked against the certificate the response itself carries. An attacker starts a SAML login, then posts a response signed with a certificate of their own. The audience, InResponseTo and timestamp checks that follow are all satisfiable by the attacker, so the response authenticates any NameID it carries. | ||||
| CVE-2026-86219 | 1 Perl | 1 Authen::sasl::perl::digest Md5 | 2026-09-08 | 9.8 Critical |
| Authen::SASL::Perl::DIGEST_MD5 versions before 2.2100 for Perl accept replayed authentication responses via unverified nonce in server_step. server_start generates a fresh nonce and sends it in the challenge, and nothing later compares that value against the nonce the client returns. server_step derives the expected digest from the client's own parameters, so a response verifies whenever its digest matches the nonce it carries. The count table it also checks is keyed on the client-supplied nonce and starts empty in each new server object, so a captured first response, carrying `nc=00000001`, passes that too. RFC 2831 defines the nonce in the response as the value the server sent in the preceding challenge. An attacker who observes one successful `qop=auth` exchange can replay the captured response against a later session for the same service, host, realm and user, and authenticate as that user without knowing the password. | ||||
| CVE-2026-82309 | 1 Perl | 1 Robots::validate | 2026-09-08 | 4.3 Medium |
| Robots::Validate versions from 0.3.2 before 0.3.11 for Perl allow unbounded outbound DNS queries per validation via a forward-confirmation loop that does not bound the names it queries. _check_dns issues one PTR query for the client address, keeps the returned names matching the rule's domain, and issues a forward query for each until one resolves back to that address. Nothing bounds that list, and a client controls the reverse zone for its own address, so it chooses how many names the PTR answer holds. Net::DNS refetches a truncated answer over TCP by default, so the 512-byte UDP payload does not cap it either. Any client whose User-Agent matches a rule with a domain reaches _check_dns. Each forward name is distinct and client-chosen, so every query misses the local cache and is resolved against the authoritative servers for that domain. The queries are synchronous, so the caller is held until all of them answer or time out. | ||||