CVE Vulnerability Catalog

The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.0, com.rabbitmq.client.ConnectionFactory.useSslProtocol() and ConnectionFactory.useSslProtocol(String) configure com.rabbitmq.client.TrustEverythingTrustManager and leave hostname verification disabled, causing arbitrary server certificates, including self-signed certificates, to be accepted. A network attacker able to intercept a TLS connection can impersonate the RabbitMQ broker, read protected AMQP traffic, and modify traffic without certificate or hostname validation. The fix changes the production TLS helpers to use the JVM default trust store and enables hostname verification, while retaining an explicitly named development-only no-verification helper. This issue is fixed in version 5.33.0.

The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.31.0, inbound AMQP command assembly in src/main/java/com/rabbitmq/client/impl/CommandAssembler.java processes a content-bearing method and header whose remainingBodyBytes value is smaller than a following AMQP.FRAME_BODY payload. CommandAssembler.consumeBodyFrame subtracts the peer-controlled payload length before validating that it fits, drives remainingBodyBytes negative, and throws a raw UnsupportedOperationException instead of MalformedFrameException. A malicious or compromised broker peer can send this malformed sequence on an open nonzero channel to terminate frame processing and close the client connection, causing denial of service for work using that connection. This issue is fixed in version 5.31.0.

The RabbitMQ Java client library before version 5.33.0 does not consistently apply the negotiated frame_max limit when validating broker-controlled frame payload lengths. A malicious broker can send a frame larger than allowed, causing the client to allocate and decode an invalid frame instead of rejecting it, leading to connection disruption and client-side denial of service.

authentik before versions 2026.2.6 and 2026.5.5 returns every configured Remote Access Control endpoint to any authenticated user regardless of application access, and the response includes connection settings that may contain stored credentials. Any authenticated user can read all endpoints with host and credentials and open connections to endpoints belonging to other applications, exposing credentials for managed RDP, SSH, and VNC targets and granting interactive access to unauthorized systems.

authentik before versions 2026.2.6 and 2026.5.5 contains a vulnerability in SAML Source configuration with USERNAME_LINK or EMAIL_LINK user-matching mode. An attacker can inject an XML comment into NameID, leading to account takeover.

authentik is an open-source identity provider. Prior to 2026.2.6 and 2026.5.5, a diagnostic action on the LDAP Source API does not enforce the object-level read-authorization filter used by the rest of the API. Any party able to reach the API, including an unauthenticated client, can invoke the diagnostic action against a configured LDAP Source. The server then connects to the upstream directory using the source's configured bind credentials and returns a bounded set of directory entries. The response exposes the distinguished names of those entries and the names of the attributes present on them, revealing directory structure, naming conventions, and the existence of specific accounts and groups, but not attribute values. Deployments without a configured LDAP Source are not affected. This issue is fixed in versions 2026.2.6 and 2026.5.5.

authentik before versions 2026.2.6 and 2026.5.5 in enterprise Google Chrome device-trust stages advance the flow without confirming that the out-of-band device attestation actually ran. An attacker who can reach such a stage can skip the verification iframe and authenticate from a device that was never verified. Where device trust is the only additional factor, that protection is fully bypassed.

ePA 3.x Integration before version 1.3.0 contains a vulnerability in VAU server certificate validation. A network-positioned attacker can intercept the VAU handshake and impersonate the server, controlling session keys and reading or modifying encrypted traffic.

A reflected XSS vulnerability in reportico-web <= 8.1.0 allows remote attackers to execute arbitrary JavaScript in a user's browser by including a malicious payload in the loadTemplate parameter with execute_mode=PREPARE in run.php.

ePA 3.x Integration before version 1.3.0 disables TLS certificate verification for both ePA connections in app/vau/VAUProtokoll.py and Konnektor connections in app/konnektor/Konnektor.py. A network-positioned attacker can present an arbitrary certificate, terminate the TLS connection, and intercept ePA traffic. The VAU protocol does not provide an effective fallback because its application-layer certificate validation is also broken. The Konnektor session uses self.session.verify set to False, so an attacker impersonating the Konnektor can receive the client's mutual TLS certificate exchange and observe smartcard operations.

ePA 3.x Integration before version 1.3.0 leaves request_counter unchanged in app/vau/VAUProtokoll.py while constructing VAU messages. The frozen client request counter causes the server side to reuse AES-GCM nonce and key combinations across responses. A network attacker who collects repeated ciphertexts can recover the XOR of plaintexts and use predictable inner HTTP headers and JSON fields to recover sensitive data, including patient health records. Repeated nonces can also enable recovery of the GHASH authentication key, allowing forged AES-GCM messages and injection of malicious responses.

ePA 3.x Integration implements the authorization workflow and writes Medical Information Objects to Germany's electronic patient record. Prior to 1.3.0, ePA 3.x Integration does not neutralize CRLF characters in values used by app/vau/VAUProtokoll.py to construct VAU inner HTTP requests. The build_inner_header function interpolates the uri, host, accept_type, content_type, content_length, USER_AGENT, and insurant_id values into request lines and headers, including x-useragent and x-insurantid. An authenticated attacker who controls a value can inject additional headers into the inner request. Depending on ePA server handling, an injected x-insurantid header can expose another patient's records, and injected Authorization headers can bypass the intended authentication or authorization context. Session-derived USER_AGENT input can also poison requests across the session. This issue is fixed in version 1.3.0.

Adaguc-server before version 7.2.2 contains a vulnerability causing a crash with a memory-safety fault when parsing a GeoJSON document with a malformed coordinate. The parser indexes array values without validating the JSON node type or coordinate length, leading to an out-of-bounds read or NULL pointer dereference. The issue affects the Polygon, LineString, MultiLineString, and MultiPolygon geometry branches.

Vvveb before version 1.0.8.4 allows a low-privileged Vendor to access products owned by another Vendor. The product controller does not verify ownership for duplicate and delete actions, enabling reading, duplicating, and deleting products and related data.

Vvveb before version 1.0.8.4 allows a low-privileged Vendor to access revisions for products owned by another Vendor. SQL queries do not verify product ownership for revision reads, restores, and deletes.

Vvveb before version 1.0.8.4 allows a low-privileged Author to access revisions for posts owned by another Author. SQL queries do not verify post ownership for revision lists, reads, restores, and deletes.

Vvveb before version 1.0.8.4 allows a low-privileged Vendor to manage reviews under another Vendor's products. SQL queries do not verify product ownership for reviews.

Vvveb before version 1.0.8.4 allows a low-privileged Vendor to manage questions under another Vendor's products. SQL queries do not verify product ownership for questions.

Saleor versions from 3.14.67 to 3.21.67, 3.22.63, and 3.23.22 have a broken authorization check in saleor/permission/utils.py that can incorrectly authorize unauthenticated GraphQL requests. This allows anonymous callers to use the channelUpdate() mutation to change channel order settings such as allowUnpaidOrders even when the response reports PermissionDenied. The same permission utility can expose hidden objects through pageType() and translation() queries, including attributes with visibleInStorefront set to false.

Cross-site scripting vulnerability in the user documentation field in Beta Systems Software AG ANOW! Automate v.3.3.1.90 allows a remote attacker to execute arbitrary code.