Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in David Lingren Media LIbrary Assistant allows Blind SQL Injection. This issue affects Media LIbrary Assistant: from n/a through 3.35.

Unauthenticated Cross Site Scripting (XSS) in MapPress Maps for WordPress <= 2.97.3 versions.

Subscriber Privilege Escalation in Abandoned Cart Pro for WooCommerce <= 10.4.0 versions.

A new API endpoint introduced in pretix 2025 that is supposed to return all check-in events of a specific event in fact returns all check-in events belonging to the respective organizer. This allows an API consumer to access information for all other events under the same organizer, even those they should not have access to. These records contain information on the time and result of every ticket scan as well as the ID of the matched ticket. Example: { "id": 123, "successful": true, "error_reason": null, "error_explanation": null, "position": 321, "datetime": "2020-08-23T09:00:00+02:00", "list": 456, "created": "2020-08-23T09:00:00+02:00", "auto_checked_in": false, "gate": null, "device": 1, "device_id": 1, "type": "entry" } An unauthorized user usually has no way to match these IDs (position) back to individual people.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Bricksable for Bricks Builder allows Stored XSS. This issue affects Bricksable for Bricks Builder: from n/a through 1.6.83.

Contributor Privilege Escalation in Fusion Builder <= 3.15.4 versions.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in OceanWP Ocean Product Sharing allows Stored XSS. This issue affects Ocean Product Sharing: from n/a through 2.2.2.

Unauthenticated Cross Site Scripting (XSS) in H5P <= 1.17.6 versions.

Subscriber Cross Site Scripting (XSS) in WP Activity Log <= 5.6.3.1 versions.

A user with API access and "manage users" permission in any venueless world is able to trigger deletion of user accounts in other worlds.

Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java. This issue affects BC-JAVA: from 1.71 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84.

A flaw has been found in griptape-ai griptape 0.19.4. This affects an unknown part of the file griptape\tools\computer\tool.py of the component ComputerTool. Executing a manipulation of the argument filename can lead to path traversal. It is possible to launch the attack remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability exists in H.View IP cameras that could allow an authenticated user to supply unsanitized XML fields to the device's certificate generation interface, which are incorporated into a backend certificate creation command without proper input validation. This may allow for command execution with elevated privileges during certificate generation.

A vulnerability was detected in griptape-ai griptape 0.19.4. Affected by this issue is some unknown functionality of the file griptape/tools/sql/tool.py of the component SqlTool. Performing a manipulation results in sql injection. It is possible to initiate the attack remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

AES-GCM encryption/decryption with extremely large cumulative single message sizes (>64 GiB) were not properly rejected by the streaming APIs, allowing counter wrap, keystream reuse, and consequent plaintext recovery.

Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA. Intermediate CA certificates are required to have the keyCertSign key usage when a Key Usage extension is present, but chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building a certificate path were previously exempted from this check, so an intermediate asserting CA:TRUE but lacking keyCertSign was accepted as a signing CA. The check now applies to chain-supplied temporary CAs as well; only operator-loaded root certificates (WOLFSSL_USER_CA) and self-signed roots remain exempt. Per RFC 5280 an absent Key Usage extension implies all usages, so the requirement is enforced only when the extension is actually present (extKeyUsageSet). Affects the OpenSSL-compatibility certificate-path-building path (X509_verify_cert / X509_STORE, OPENSSL_EXTRA/OPENSSL_ALL), where untrusted chain intermediates are added as temporary CAs; native (non-OpenSSL-compat) certificate verification does not create temporary CAs and

TLS 1.3 post-handshake authentication (PHA) issue where a server could accept a client's Finished message without the client having sent a Certificate and CertificateVerify. The post-handshake-auth exemption that allows an empty/absent peer certificate was only intended for the initial handshake, but it was also being applied while a post-handshake CertificateRequest was still outstanding. The check is now scoped to the initial handshake only: on the server, once a post-handshake CertificateRequest has been sent (certReqCtx is set), a peer certificate and a valid CertificateVerify are required again before the Finished is accepted, with empty-certificate handling following the configured verify mode (FAIL_IF_NO_PEER_CERT) just as during first-handshake client authentication. Only affects TLS 1.3 servers built with post-handshake authentication support (WOLFSSL_POST_HANDSHAKE_AUTH / --enable-postauth, included in --enable-all) that enable WOLFSSL_VERIFY_POST_HANDSHAKE and request a clie

wolfSSL_PKCS7_verify() returning success for a degenerate (certs-only) PKCS#7 object that contains no signer. Such an object has empty signerInfos, so the underlying signed-data verification succeeds without authenticating any content. The compatibility-layer verify path now rejects the object when no signer signature has actually been verified, so a PKCS#7 carrying no valid signature is no longer reported as verified. This is enforced regardless of the PKCS7_NOVERIFY flag, which only suppresses signer certificate chain validation and was never intended to waive the requirement that a signature exist. Only affects OpenSSL compatibility builds that call the PKCS7_verify() compatibility API on potentially degenerate PKCS#7 bundles.

Un-negotiated Raw Public Key (RFC 7250) accepted in place of an X.509 certificate, bypassing chain validation. A raw public key has no chain, so ParseCertRelative() accepts it without performing any trust verification; it must therefore only be accepted when RPK was actually negotiated for that peer. The check now defaults the expected type to X.509 (per RFC 7250/8446) when no type was negotiated, comparing against the received server certificate type on the client and the selected client certificate type on the server, and rejects any mismatch, including an un-negotiated raw public key, with UNSUPPORTED_CERTIFICATE. Only affects builds with Raw Public Key support (HAVE_RPK) enabled - disabled by default in a standalone build, but included in --enable-all.

A security vulnerability has been detected in griptape-ai griptape 0.19.4. Affected by this vulnerability is the function load_files_from_disk/list_files_from_disk/save_content_to_file/save_memory_artifacts_to_disk of the component FileManagerTool. Such manipulation leads to path traversal. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.