Vulnerabilidades

*** Pendiente de traducción *** A vulnerability was identified in liketrek TREK up to 3.0.22. The impacted element is the function findOrCreateUser of the file server/src/services/oidcService.ts of the component OIDC Service. Such manipulation leads to improper authentication. It is possible to launch the attack remotely. The attack requires a high level of complexity. The exploitability is regarded as difficult. Upgrading to version 3.1.0 is sufficient to resolve this issue. Upgrading the affected component is advised.

*** Pendiente de traducción *** Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana can lead to unauthorized data modification via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Under certain conditions, an authenticated user could reference another user's AI Assistant conversation identifier to access or modify a conversation they do not own. Successful exploitation requires knowledge of a hard-to-guess identifier.

*** Pendiente de traducción *** Joomla Extension - miniorange.com - Unauthenticated Authentication Bypass via SAMLResponse Parameter in miniOrange SAML SSO

*** Pendiente de traducción *** Issue summary: ChaCha20-Poly1305 and AES-OCB decryption with an empty<br /> ciphertext can report success without verifying the supplied authentication<br /> tag when the operation is finalized by calling the EVP_Cipher() function.<br /> <br /> Impact summary: Applications calling EVP_Cipher() on an empty ciphertext and<br /> expecting the call to check the AEAD tag may accept forged messages.<br /> <br /> CWE: CWE-354 (Improper Validation of Integrity Check Value)<br /> <br /> Description: The EVP_Cipher() API call for AEAD ciphers behaves like a one<br /> shot encryption and decryption call. It also verifies the AEAD tag after the<br /> decryption operation. However for AES-OCB and ChaCha20-Poly1305 ciphers<br /> it skipped the AEAD tag verification when an empty ciphertext was passed to<br /> the function. The callers of this function might believe that a successful<br /> return indicates a valid AEAD tag for these ciphers, even when that has not<br /> truly been validated in this case.<br /> <br /> FIPS impact: no<br /> The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this CVE<br /> as the affected algorithms are not FIPS approved and thus not implemented<br /> in the FIPS module.

*** Pendiente de traducción *** Issue summary: OpenSSL CMP response validation passed an unexpected response<br /> sender distinguished name directly as the format string to `ERR_raise_data()`.<br /> <br /> Impact summary: A malicious or intercepted CMP endpoint can crash a CMP client<br /> that enforces an expected sender or uses a pinned server certificate whose<br /> subject becomes the default expected sender.<br /> <br /> CWE: CWE-134 (Use of Externally-Controlled Format String)<br /> <br /> Description: When validating a received CMP message, ossl_cmp_msg_check_update()<br /> converts the peer-supplied sender distinguished name with X509_NAME_oneline()<br /> and passes it directly as the format argument to ERR_raise_data(). Percent<br /> characters survive the conversion, so a sender DN such as "CN=%s%n" reaches<br /> BIO_vsnprintf() as an attacker-controlled format string with no matching variadic<br /> arguments. This path is only reached when the caller configures an expected<br /> sender or pins a server certificate, which is the normal configuration for a<br /> CMP client validating server responses.<br /> <br /> Since the attacker controls the format string but none of the variadic<br /> arguments, such specifiers as %s and %n dereference or write through unrelated<br /> stack contents and crash the client. The reliable consequence is a denial of<br /> service, when the response comes from a malicious or intercepted CMP endpoint.<br /> There is no controlled memory write, arbitrary-address read, or reliable path<br /> to remote code execution.<br /> <br /> FIPS impact: no<br /> <br /> No FIPS modules are affected by this issue, as the CMP protocol<br /> implementation is outside the OpenSSL FIPS module boundary.

*** Pendiente de traducción *** Issue summary: OpenSSL CMS decryption sizes the key-unwrap output buffer based<br /> on querying the unwrapped key size, but the AES-WRAP-PAD unwrap primitive<br /> can write and cleanse more bytes than that query reports, causing an 8-byte<br /> out-of-bounds heap write.<br /> <br /> Impact summary: An attacker who supplies a crafted CMS message can trigger a<br /> deterministic 8-byte out-of-bounds heap write when the victim decrypts it<br /> with CMS_decrypt(), corrupting the heap and typically resulting in a Denial<br /> of Service.<br /> <br /> CWE: CWE-787: Out-of-bounds Write<br /> <br /> Description: The key-wrap OID is potentially attacker-controlled on the wire.<br /> CMS unwrapping allows both id-aesNNN-wrap-pad and id-aesNNN-wrap ciphers.<br /> An attacker can take a legitimate message and change a single OID byte to<br /> select the padded variant while leaving the message otherwise valid. Since<br /> the unwrap key is derived from the recipient&amp;#39;s private operation (ECDH key<br /> agreement or ML-KEM decapsulation), the RFC 5649 integrity check cannot<br /> pass, and the decryption fails with integrity failure.<br /> <br /> The write is a fixed-size (8-byte), fixed-value (zero) heap overflow<br /> immediately past the allocation, requires no special configuration, and is<br /> reachable from the public CMS_decrypt() function. The consequence is<br /> a heap corruption leading to a Denial of Service. The fix in the CMS code<br /> sizes the unwrap output buffer for the worst case so a failed unwrap cannot<br /> write past the allocation.<br /> <br /> FIPS impact: no<br /> <br /> As the CMS code lives outside the FIPS module boundary, no FIPS<br /> modules are affected by this CVE.

*** Pendiente de traducción *** Issue summary: The OpenSSL Certificate Management Protocol (CMP) caches<br /> additional certificates (extraCerts) sent in a CMP message, but never expunges<br /> them (for instance if they are invalid). If a server reuses an OSSL_CMP_CTX<br /> frequently, this cache of extraCerts may grow unboundedly, and a malicious<br /> client may flood a CMP server with requests driving this growth.<br /> <br /> Impact summary: Users utilizing a CMP server that reuses a single OSSL_CMP_CTX<br /> for the lifetime of a server process may observe unbounded memory growth in the<br /> event a malicious client repeatedly sends requests containing unique extra<br /> certificates, which may lead to OOM conditions.<br /> <br /> CWE: CWE-770: Allocation of Resources Without Limits or Throttling<br /> <br /> Description: If a remote user sends CMP messages to a server with a list of<br /> extraCerts and the message is rejected, the extraCerts from the message remains<br /> in the server contexts untrusted certificate stack. This exposes servers with<br /> long lived ctx objects to Denial of Service attacks in which an attacker sends<br /> messages intending to be rejected with a large list of additional certificates<br /> repeatedly, forcing the server to store them indefinitely.<br /> <br /> The issue was fixed by removing the added extra certs if the message is<br /> rejected, using the same method as when the context is configured to not do<br /> caching at all.<br /> <br /> FIPS impact: no<br /> As the CMP code lives outside the FIPS module boundary, no FIPS<br /> modules are affected by this CVE.

*** Pendiente de traducción *** Issue summary: When OpenSSL processes QUIC traffic from a peer that repeatedly<br /> sends ack-eliciting packets while not acknowledging ACK-only responses, the<br /> QUIC stack can retain ACK-only packet metadata for the lifetime of the<br /> connection.<br /> <br /> Impact summary: A remote peer that can complete a QUIC handshake can<br /> cause connection-scoped memory growth which may lead to Denial of Service<br /> through memory exhaustion, especially with sustained traffic or many concurrent<br /> QUIC connections.<br /> <br /> CWE: CWE-770: Allocation of Resources Without Limits or Throttling<br /> <br /> Description: When the OpenSSL QUIC stack sends an ACK-only packet,<br /> there is no requirement by the QUIC protocol that the peer will acknowledge<br /> that ACK-only packet (i.e. it is itself not ack-eliciting). However, the OpenSSL<br /> implementation stores the metadata about the ACK frames regardless.<br /> In and of itself that&amp;#39;s ok, but if a malicious peer establishes a connection, and<br /> then drives the connection such that ACK-only packets are forced from the <br /> OpenSSL implementation peer (i.e., by sending numerous PING frames),<br /> and then withholding any subsequent acks for ack-eliciting data, like<br /> legitimate data, said malicious peer can force inappropriate memory growth<br /> on the OpenSSL peer, potentially leading to a Denial of Service.<br /> <br /> The fix is to ensure that we account for the transmission of the ACK-only<br /> packet in the packet histories high and low watermark without actually storing<br /> the ACK-only packet metadata itself.<br /> <br /> FIPS impact: no<br /> The OpenSSL FIPS module is not affected as the QUIC code is<br /> outside the FIPS module boundary.

*** Pendiente de traducción *** Issue summary: OpenSSL CMP password based protection verification only<br /> checks whether the protectionAlg parameter was not NULL and not its<br /> ASN.1 type, before treating it as a PBMParameter. A crafted message can<br /> contain a parameter of a different type, which is then dereferenced as an<br /> invalid pointer.<br /> <br /> Impact summary: A remote, unauthenticated attacker can crash an application<br /> acting as a CMP server that accepts PBM-protected messages, or a CMP client<br /> talking to a malicious or intercepted CMP server, resulting in a Denial of<br /> Service.<br /> <br /> CWE: CWE-476: NULL Pointer Dereference<br /> <br /> Description: When verifying the password-based MAC protection of a CMP<br /> message, OpenSSL library reads the protectionAlg algorithm parameter with<br /> X509_ALGOR_get0(), which returns both the parameter type and its value<br /> pointer. The value is then cast to an ASN1_STRING and treated as the<br /> expected PBMParameter after only checking that pointer is not NULL. The<br /> parameter type returned by X509_ALGOR_get0() was never consulted.<br /> <br /> This happens during protection verification, before any MAC is computed, so<br /> no knowledge of the PBM shared secret is required; the only precondition is<br /> that PBM verification is reachable. On the server side this is reached from<br /> OSSL_CMP_SRV_process_request() for any application that stands up a CMP<br /> server accepting PBM-protected messages, and on the client side from CMP<br /> response validation against a malicious or on-path (MITM) server. The<br /> reliable consequence is a denial of service; there is no memory disclosure,<br /> no controlled memory write, and no path to code execution. CMP is a<br /> specialized feature that an application must explicitly enable.<br /> <br /> FIPS impact: no<br /> As the CMP code lives outside the FIPS module boundary, no FIPS modules<br /> are affected by this CVE.

*** Pendiente de traducción *** Issue summary: Receiving a DTLS record for a future epoch while a handshake<br /> is in progress causes OpenSSL to buffer far more memory than the record<br /> itself requires.<br /> <br /> Impact summary: A peer can use a small amount of network traffic to make an<br /> OpenSSL DTLS endpoint retain a disproportionately large amount of memory,<br /> which may lead to a Denial of Service.<br /> <br /> CWE: CWE-405: Asymmetric Resource Consumption (Amplification)<br /> <br /> Description: While a DTLS handshake is in progress, a peer may legitimately<br /> have already moved on to the next epoch (for example, having sent its<br /> ChangeCipherSpec and Finished messages) before the local endpoint has<br /> processed the same transition, typically because of reordering on the<br /> underlying UDP transport. OpenSSL buffers such early records so that they<br /> can be processed once the local endpoint catches up.<br /> <br /> Buffering a record currently retains the entire read buffer it arrived in,<br /> which is sized to hold the largest possible DTLS record (around 16<br /> kilobytes), rather than just the bytes that make up the record itself. Up<br /> to 100 such records may be buffered per connection. As a result, a peer<br /> that sends a stream of small forged records claiming to belong to the next<br /> epoch can cause an OpenSSL DTLS endpoint to retain around 1.7 megabytes of<br /> memory, despite sending only a small fraction of that amount of data over<br /> the network.<br /> <br /> An attacker therefore gains a memory amplification factor of around 1200,<br /> and can multiply the effect across as many associations as it is able to<br /> open, making this a remote memory exhaustion Denial of Service risk for<br /> DTLS servers. Since the memory retained per connection remains bounded,<br /> and any limit an application already places on the number of concurrent<br /> associations also bounds the total exposure, this issue has been assessed<br /> as Low severity.<br /> <br /> FIPS impact: no<br /> <br /> No FIPS modules are affected by this issue as the affected code is outside<br /> the OpenSSL FIPS module boundary.<br /> <br /> OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are vulnerable to this<br /> issue.<br /> <br /> OpenSSL 4.0 users should upgrade to OpenSSL 4.0.2.<br /> OpenSSL 3.6 users should upgrade to OpenSSL 3.6.4.<br /> OpenSSL 3.5 users should upgrade to OpenSSL 3.5.8.<br /> OpenSSL 3.4 users should upgrade to OpenSSL 3.4.7.<br /> OpenSSL 3.0 users should upgrade to OpenSSL 3.0.22.<br /> <br /> Premium support customers only:<br /> OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zi<br /> OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zr<br /> <br /> This issue was reported on 18 May 2026 by Amazon Web Services.<br /> The fix has been developed by Matt Caswell.<br /> <br /> -- cut (non-publishing metadata for internal use) --<br /> Reported by: Amazon Web Services<br /> Fixed by: Matt Caswell

*** Pendiente de traducción *** Crater Invoice through 6.0.6 contains a path traversal vulnerability in the self-update API that allows authenticated company owners to write arbitrary files outside the intended extraction directory by supplying crafted ZIP archives with ../ sequences to the unzip endpoint. Attackers can exploit unsanitized ZIP entry names passed to PHP&amp;#39;s ZipArchive::extractTo() to write arbitrary PHP files into the web-accessible public directory and achieve remote code execution on the server.

*** Pendiente de traducción *** Issue summary: In a server or client configuration with RFC7250 Raw Public Keys (RPKs)<br /> enabled, and only the private key (with no associated certificate) configured locally,<br /> a NULL pointer dereference may occur when the remote peer solicits raw public keys and<br /> also sends the typically omitted "signature_algorithms_cert" TLS extension.<br /> <br /> Impact summary: The impact is limited to a possible Denial of Service as a result of<br /> an application abort, no data disclosure or remote command execution are possible.<br /> <br /> CWE: CWE-476: NULL Pointer Dereference<br /> <br /> Description: While a passing comment in sample code in the documentation suggests<br /> that key-only RPK configurations are supported, the best-practice RPK configuration<br /> is to always configure a corresponding certificate (possibly self-signed or<br /> signed by any convenient CA).<br /> <br /> When the private key is configured along with a matching certificate, the<br /> "signature_algorithms_cert" extension is handled reliably even without the<br /> fix, and peer clients or servers that don&amp;#39;t support raw public keys may be<br /> able to complete a TLS connection by pinning or verifying the corresponding<br /> certificate or its public key.<br /> <br /> Deployments that prefer to configure just a private key with no certificate<br /> need to upgrade to an updated release as noted below.<br /> <br /> FIPS impact: no<br /> <br /> No FIPS modules are affected by this issue, as the SSL protocol implementation<br /> is outside the OpenSSL FIPS module boundary.