CVE Vulnerability Catalog

Jivejdon through 5.0 contains a stored cross-site scripting vulnerability that allows authenticated attackers to inject script into private short messages because receiveshortmessage.jsp renders unfiltered message bodies. Attackers can send a short message containing script, which ToolsUtil.convertURL() passes through unchanged, to execute code in the recipient's browser when opened.

Jivejdon through 5.0 contains a stored cross-site scripting vulnerability that allows authenticated attackers to inject script by posting unsanitized forum message bodies. Message bodies are rendered by messageListBody.jsp with filter="false" and non-escaping default filters, executing script in the browser of every user viewing the thread.

jivejdon from commit 595d8d22 through commit ee67a65e contains a stored cross-site scripting vulnerability in the default-enabled TextStyle filter that inserts unvalidated URLs into anchor href attributes. Authenticated attackers can post messages with javascript: links or quote-breaking URLs to execute JavaScript when other users click or hover over rendered links.

Jivejdon through 5.0 contains a reflected cross-site scripting vulnerability in application/message/postThread.jsp that allows attackers to inject script via the to and tag parameters. Attackers can send crafted links to authenticated users, breaking out of unencoded inline JavaScript string literals to execute arbitrary JavaScript in the victim's session.

Jivejdon from commit 5489372d through commit ee67a65e contains a reflected cross-site scripting vulnerability in application/query/taggedThreadList.jsp that allows unauthenticated attackers to inject script via unencoded tagID and count parameters. Attackers can craft a link with a script-closing payload in tagID or count, triggered when start exceeds zero, to execute JavaScript in victims' browsers.

Jivejdon through 5.0 contains an authorization bypass vulnerability in SubscriptionServiceImp.deleteSubscription that allows authenticated users to delete other users' subscriptions by ID. Attackers can submit a delete action to /account/protected/sub/subSaveAction with another user's subscriptionId to remove their thread, forum, tag or account subscriptions.

Jivejdon from commit d58a36b0 through commit ee67a65e contains a missing authorization vulnerability in UpdateThreadToForumAction that allows authenticated users to move other users' threads. Attackers can send crafted threadId and forumId values to /message/threadToForum/save to relocate any reply-less thread into an arbitrary forum.

Hazelcast prior to 5.4.5, 5.5.10, and 5.6.1 contains improper validation of data supplied by a malicious client able to connect to a cluster, allowing arbitrary reads from a cluster member's Java heap, off-heap data, and JVM process address space. The same flaw can crash cluster members and, in some Hazelcast Enterprise Edition configurations, corrupt memory with possible arbitrary code execution. This issue is fixed in versions 5.4.5, 5.5.10, 5.6.1, and 5.7.0.

Hazelcast is a unified real-time data platform. Prior to 5.4.5, 5.5.10, and 5.6.1, missing authorization checks in the IMap Predicates API allow a malicious client with limited privileges to execute arbitrary code on a Hazelcast cluster member.

fast-jwt is a fast JSON Web Token implementation. In 6.2.4, it can misclassify raw serialized public JWK or JWKS JSON as an HMAC secret because performDetectPublicKeyAlgorithms treats non-PEM strings as symmetric key material. If HS256 is explicitly allowed or inferred, an attacker who knows the exact serialized public-key bytes can use them as an HMAC key and create a token with arbitrary claims.

fast-jwt is a fast JSON Web Token implementation. Prior to 6.3.0, createVerifier accepts a validly signed JWT whose payload is a JSON array because the decoder does not reject arrays, causing the claim validator loop to silently skip configured checks. An attacker who can produce or influence a validly signed token may bypass expiry, issuer, audience, subject, revocation, and replay protections.

fast-jwt from 6.2.0 until 6.3.0 can misclassify RSA public-key text as an HMAC secret when the key has non-whitespace content before its PEM header. In src/crypto.js, performDetectPublicKeyAlgorithms trims whitespace but publicKeyPemMatcher remains start-anchored, so comments, control characters, zero-width characters, or wrapper text can prevent PEM detection and reach the HMAC fallback. An attacker who knows the public key bytes can sign arbitrary HS256 claims with that public material when HS256 is inferred or allowed, resulting in authentication or authorization bypass. An asymmetric-only algorithm allowlist prevents the attack. This issue is fixed in version 6.3.0.

fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts Infinity for clockTolerance because its option validation checks type and negativity but not finiteness. In validateClaimDateValue, infinite positive and negative modifiers make exp and nbf comparisons always pass, allowing expired or not-yet-active tokens to be accepted. The verifier cache also derives infinite bounds, so entries created under this configuration can remain valid until eviction. Exploitation requires an application administrator or equivalent configuration path to set clockTolerance to Infinity. This issue is fixed in version 6.3.0.

fast-jwt is a fast JSON Web Token implementation. Prior to 6.3.1, createVerifier accepts an unsigned JWT when key is an empty string or null and algorithms is a non-empty allowlist. Falsy synchronous keys bypass prepareKeyOrSecret and the empty signature avoids the verifySignature gate, allowing an attacker to submit a token with arbitrary claims without possessing a signing key.

fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.4, the fast-jwt createVerifier cache can continue accepting a previously valid, signed JWT after its exp time when caching is enabled and the token has exp but no iat. In src/verifier.js, cacheSet derives the exp cache deadline only when iat is present, so the cache falls back to cacheTTL, and a later cache hit returns the saved payload before verifyToken rechecks expiration. An attacker who can replay the same cached bearer token can extend access until the cache entry expires, but cannot forge a token through this issue. This issue is fixed in version 6.3.4.

AdonisJS HTTP Server is a package for handling HTTP requests in the AdonisJS framework. Prior to 8.2.3 and 9.3.0, AdonisJS HTTP Server inserts route parameter values into URLs without encodeURIComponent in the shared createURL() helper used by Router.makeUrl() and Response.redirect().toRoute(). If an application places attacker-controlled data in a dynamic first path segment and uses the generated route URL as a redirect destination, a value beginning with a slash can produce a scheme-relative external URL. Wildcard parameters are affected by the same missing encoding, while APIs intentionally accepting complete redirect URLs are not affected. An attacker can redirect users from a trusted application to an attacker-controlled site, facilitating phishing or abuse of authentication and OAuth flows. This issue is fixed in versions 8.2.3 and 9.3.0.

Banks generates meaningful LLM prompts using a simple template language. Prior to 2.5.0, Banks Prompt.chat_messages() attempts to parse every line of rendered template output as ChatMessage JSON. When an application renders untrusted data and passes the returned ChatMessage objects to an LLM provider, attacker-controlled JSON can cross the prompt boundary and become a system, assistant, or tool message because ChatMessage.role accepts arbitrary strings. This can override application instructions, alter the intended prompt structure, or confuse downstream tool and message handling. This issue is fixed in version 2.5.0.

Banks generates meaningful LLM prompts using a simple template language. Prior to 2.5.1, DirectoryPromptRegistry does not reject symbolic links for index.json or .jinja prompt files, so in applications where untrusted users can influence a prompt directory, it can follow a link outside the registry root and disclose, read, or overwrite external files.

The Mechanize library is used for automating interaction with websites. Prior to 2.14.1, Mechanize sends caller-supplied credential headers to a different host after an HTTP redirect. Mechanize#request_headers= is reapplied by Mechanize::HTTP::Agent#request_add_headers even after Mechanize::HTTP::Agent#response_redirect strips per-request headers, and the protected header lists omit Proxy-Authorization and Cookie2. An attacker who controls a redirect target can capture bearer tokens or session cookies supplied through request_headers= or the per-request headers argument, while Mechanize#cookie_jar and Mechanize::HTTP::AuthStore are not affected. This issue is fixed in version 2.14.1.

The Mechanize library before version 2.14.1 incorrectly treats redirects as same-origin when the host matches without consistently comparing scheme and port. A same-host HTTPS-to-HTTP redirect can send Authorization and Cookie headers over cleartext, while a same-host redirect to another port can send a caller-supplied Cookie header to a different service. The issue affects caller-supplied headers and can disclose credentials.