Java
Monthly
Improper authorization in TaleLin lin-cms-spring-boot 0.2.1 and earlier lets remote unauthenticated attackers read book records they are not entitled to by manipulating the ID argument supplied to the BookController.getBook endpoint (CWE-285, an object-level authorization gap equivalent to an IDOR). Exploitation requires no authentication, no user interaction and no non-default configuration, and publicly available exploit code exists, though the impact ceiling is low - read-only disclosure of book data with no integrity or availability effect. The issue is not listed in CISA KEV, and the maintainer did not respond to the VulDB disclosure, so no patched version has been identified.
Stored cross-site scripting in huanzi-qch base-admin lets a low-privileged authenticated user inject script through the Username argument of the Add User handler (CommonController.java Save), which then executes in the browser of any user - typically an administrator - who later views the tainted page. Exploitation requires a valid low-privileged account plus victim interaction (viewing the rendered username), and publicly available exploit code exists; no confirmed active exploitation is indicated (no CISA KEV listing). Because the project ships via continuous rolling releases, no fixed version has been published and the vendor did not respond to the disclosure.
SQL injection in java110 MicroCommunity (through version 2.0) allows remote attackers to inject arbitrary SQL through the fallBackSql argument of the fallBack API endpoint implemented in BusinessApi.java / QueryServiceSMOImpl.fallBack. Publicly available exploit code exists (published as a Gitee issue), and because CVSS 4.0 carries PR:N, exploitation is claimed to need no authentication - though an independent assessment notes the endpoint may in practice sit behind application authentication, which would narrow real-world exposure. The project has not responded to the report, so no vendor fix is identified, and the CVE is not listed in CISA KEV, meaning confirmed active exploitation has not been established.
Path traversal in weiqingwen spring-boot-forum lets an authenticated forum user escape the intended avatar storage path by manipulating the Username argument processed in NewUserFormValidator.validate during avatar upload. The issue is remotely reachable and, per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), requires a valid forum account while yielding only Low confidentiality and integrity impact because the traversal is scoped to the avatar file-handling path. Publicly available exploit code exists, the maintainer did not respond to the disclosure, and because the project ships rolling releases with no tagged versions there is no known fixed release to migrate to.
Unsalted MD5 password hashing in sfturing hosp_order (code through commit 627f426331da8086ce8fff2017d65b1ddef384f8) leaves stored user credentials cheaply crackable if the hash store is ever exposed. The defect is not a remotely reachable primitive: per the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N) an attacker with low privileges must first obtain the password digests - through a separate vulnerability, a database compromise, or a backup leak - before the missing salt provides any advantage, which is why impact is limited and complexity is high. Publicly available exploit code exists that demonstrates the weak hashing, but there is no confirmed active exploitation (no CISA KEV listing), and the project has not responded to the issue report, so no vendor-released patch is identified at time of analysis.
Atom-table exhaustion in RabbitMQ's x-jms-topic exchange lets an authenticated low-privilege AMQP user crash an entire broker node in fewer than 100 binding declarations, turning a vhost-confined account into a cross-tenant denial of service. The flaw is reachable only when the bundled rabbitmq_jms_topic_exchange plugin is enabled - standard in any JMS deployment - and the attacker holds read permission on an x-jms-topic exchange plus write permission on a queue, or configure rights to declare both; it also requires a raw AMQP client, because the broker does not enforce the client-side selector compilation that the Java JMS client performs. Fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0; no public exploit identified at time of analysis and no CISA KEV listing, though the attack needs no user interaction and is network-reachable, with an assessed CVSS 3.1 score of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
Cross-site request forgery in the sfturing hosp_order Java application allows an attacker to forge state-changing requests through CommonUserController.java while a logged-in user holds an active session, yielding a limited integrity impact. Publicly available exploit code exists and has been disclosed via upstream issue #122, but there is no KEV listing and no evidence of confirmed active exploitation; EPSS data was not provided. With a CVSS 4.0 base score of 2.1 and a very small deployment base for this obscure, unversioned project, this is a low real-world priority.
Cleartext SMTP email transmission in sfturing hosp_order (MailUtil.getProperties) can expose sensitive email-related data to an attacker who already holds a network interception position between the application server and the mail server. Publicly available exploit code exists, but there is no confirmed active exploitation; the issue requires an unencrypted SMTP configuration and high-complexity adversary-in-the-middle access, and it produces only limited confidentiality impact. This is assessed as a low-real-risk issue despite the nominal CVSS 4.0 score of 6.3.
sfturing hosp_order stores sensitive information in cleartext in CommonUserServiceImpl.java, allowing a local attacker with a low-privilege authenticated account to read exposed data without user interaction. The issue is a low-severity local confidentiality-only flaw (CVSS 4.0 base score 1.9; independent CVSS 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) affecting all versions tracked by CPE cpe:2.3:a:sfturing:hosp_order:*:*:*:*:*:*:*:*; because the project uses rolling releases and has not responded, no fixed version is available. Publicly available exploit code exists, but there is no CISA KEV confirmation.
Hard-coded database credentials in sfturing hosp_order (file ssm_pro/src/main/resources/jdbc.properties) enable unauthenticated attackers who obtain the credentials from the public source repository to directly access the backing database, potentially reading and modifying data, provided the credentials remain unchanged and the database is network-reachable. Publicly available exploit code exists (GitHub issue #119), but the CVSS 4.0 base score is 2.9 and the independent assessment rates this as a low real-world priority because high attack complexity (AC:H) and deployment prerequisites-such as credential rotation or database network restrictions-neutralize the flaw. No confirmed active exploitation (CISA KEV) has been reported, and no vendor-released patch is identified.
Catastrophic regex backtracking in the JLine3 `nano` editor's regex search mode allows an authenticated user to hang the editor session thread at high CPU, producing a denial of service. The flaw affects applications that embed `org.jline:jline-builtins` and expose the nano editor: `jline-builtins` 3.0.0 through 3.30.14 and 4.0.0 through 4.3.0 are impacted (CWE-1333, CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). A proof-of-concept reproduction, using a buffer of repeated 'a' characters and the pattern `(a+)+b`, is documented in the vendor advisory, and vendor-released patches exist in 3.30.15 and 4.3.1; no confirmed active exploitation (CISA KEV) or public exploit code beyond the advisory PoC has been reported. Practical severity depends on deployment: in a single-user local terminal the user only hangs their own session, whereas remote multi-user services that share worker threads can lose a server thread indefinitely.
A crafted HISTORY_IGNORE value can hang a JLine reader session (org.jline:jline-reader) via catastrophic regular-expression backtracking, pinning the reader thread at high CPU each time a command line is written to history. Applications that embed JLine 3.x (>= 3.0.0, < 3.30.15) or 4.x (>= 4.0.0, < 4.3.1) and let HISTORY_IGNORE be set from user configuration or application settings are affected; the impact is limited to denial of service with no confidentiality or integrity effect. The attacker must already be able to control configuration (CVSS vector PR:L, AV:L), so this is a low-to-moderate real-world priority; no public exploit code was identified at time of analysis, although the vendor advisory documents deterministic reproduction steps, and vendor patches shipping the fix are available in 3.30.15 and 4.3.1.
GoCD versions 20.2.0 through 26.0.x disclose the complete list of configured usernames and role names to any authenticated user through the internal pipeline-structure autocompletion API, even when that user has no administrator privileges. The endpoint is reached remotely over HTTP (AV:N) and requires only a valid low-privileged account (PR:L), so a regular GoCD user can enumerate tenant user and role identifiers to support follow-on credential-stuffing, phishing, or targeted attacks, though the response never maps users to roles and cannot modify any data. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the disclosure is limited to names, which is why the independently assessed severity remains low. GoCD 26.1.0 contains the vendor fix.
GoCD 20.2.0 through pre-26.1.0 allows any authenticated user to retrieve inter-pipeline dependency hierarchy details and user-defined pipeline, stage, job, and artifact plugin reference names via the internal fetch-artifact auto-suggestion API at /go/api/internal/pipelines/**/upstream, bypassing per-pipeline view authorization. The endpoint is read-only, so impact is limited to information disclosure that matters primarily where pipeline visibility is restricted per user or team; single-team installations expose little extra. No public exploit code was identified at time of analysis, and the issue is fixed in version 26.1.0.
HTTP request desynchronization in Apache Tomcat allows an unauthenticated remote attacker to cause a single request belonging to another user to fail when Tomcat is deployed behind a reverse proxy. The flaw (CWE-444) arises because Tomcat processes the Transfer-Encoding header on HTTP/1.0 requests, and when a fronting proxy interprets that header differently, the two sides disagree about request boundaries on a shared upstream connection. Affected releases are 11.0.0-M1 through 11.0.25, 10.1.0-M1 through 10.1.59, 9.0.47 through 9.0.121, and the end-of-life 8.5.67 through 8.5.100; standalone Tomcat with no fronting proxy is not affected. The assessed impact is availability-only (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) - no persistence, data exposure, or code execution is described - and no public exploit code was identified at time of analysis.
Apache Tomcat's OpenSSL and OpenSSL-FFM TLS connectors ignore certificate revocation lists when the certificate is loaded from a keystore, so a client certificate that has already been revoked can still be accepted for mutual-TLS authentication. Affected releases are 11.0.0-M1 through 11.0.25, 10.1.0-M1 through 10.1.58, and 9.0.0-M1 through 9.0.121, with end-of-life 8.5.0 through 8.5.100 also known to be affected; fixed versions are 11.0.26, 10.1.59, and 9.0.122. No vendor CVSS score, EPSS value, CISA KEV entry, or public proof-of-concept was supplied, and our internal assessment rates the issue CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, reachable unauthenticated but only in the non-default combination of an OpenSSL or OpenSSL-FFM TLS connector, keystore-based certificates, mutual-TLS client-certificate authentication, and CRL-based revocation checking; no public exploit identified at time of analysis.
Content-Disposition enforcement bypass in Apache Sling Security Bundle before 1.3.12 allows remote attackers to circumvent the ContentDispositionFilter by accessing attacker-influenced resources through an alternate URL/API shape not mediated by the filter, potentially causing resources to be served inline rather than as attachments. This protection-mechanism failure (CWE-693) can lead to low confidentiality and integrity impacts, such as information disclosure or client-side script execution, and requires user interaction to open a crafted link. Deployments that rely on this filter for content-disposition protection are affected; no public exploit identified at time of analysis.
Cross-site scripting in the Apache Sling XSS Protection API before version 2.4.12 allows unauthenticated remote attackers to have attacker-supplied script execute in a victim's browser session when an application built on the library routes untrusted, attacker-influenced input through the flawed sanitization/encoding routines and reflects it into an HTML response. Because the affected artifact is a shared library rather than a standalone server, exposure depends entirely on the consuming application - most commonly Apache Sling-based sites and Adobe Experience Manager - and exploitation requires the victim to load the crafted page or click a malicious link (user interaction). Neither NVD nor Apache published a CVSS score for this issue, so severity must be inferred from the library-level flaw and the deployed context; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N (unauthenticated, user-interaction dependent, scoped impact affecting the embedding application), and no public exploit identified at time of analysis.
Remote code execution on the Apache Doris Frontend (FE) is achievable when a privileged, already-authenticated user supplies a crafted JDBC driver URL that the FE loads without sufficient validation, a case of inclusion of functionality from an untrusted control sphere (CWE-829). The assessed vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) shows the flaw is network-reachable but gated behind high privileges, meaning only accounts that can define or modify JDBC catalogs or external resources can reach the vulnerable code path; anonymous or low-privilege actors are out of scope, and no user interaction or default-configuration vector exists for an external unauthenticated attacker. No CVSS score, EPSS value, KEV entry, or proof-of-concept was supplied in the source data, so there is no confirmation of active exploitation and no public exploit identified at time of analysis, leaving quantitative prioritization signals absent.
Cross-site scripting in Apache Sling XSS before 2.4.12 allows remote attackers to inject script that executes in a victim's browser when an application relying on the library's output encoding and sanitization renders attacker-influenced input through a code path where neutralization is incomplete. Exploitation is conditional: it requires a reflected or stored injection point in the consuming application and victim interaction (loading the affected page) for script execution, and applications that apply their own independent output encoding are not exposed. The vendor-released fix is version 2.4.12; no public exploit code identified at time of analysis, no EPSS data was supplied, and no public CVSS score or vector (Apache and NVD both N/A) exists, so severity must be inferred from the independently assessed vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.
Denial of service in Apache Sling XSS (before 2.4.12) allows remote unauthenticated attackers to exhaust server resources by passing XML content with recursively defined DTD entities through the Sling XSS protection module, which expands them without bound. This CWE-776 XML entity expansion flaw only affects availability (no data compromise) and requires the application to route attacker-controlled XML to the vulnerable parser. No public exploit code or active exploitation has been identified, and the vendor recommends upgrading to 2.4.12.
Reflected cross-site scripting in the Apache Sling XSS library 2.4.10 and earlier arises because the XSSAPI.getValidHref() helper fails to properly neutralize certain attacker-supplied values, returning an href that a consuming application may then render into a page. Remote, unauthenticated attackers can exploit this only where a downstream application actually uses getValidHref() as its sanitizer for attacker-influenced link values and reflects that value back to users, and a victim must click a crafted link for the script to execute (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N). No public exploit code and no confirmed active exploitation were identified at time of analysis, and overall risk is low because reachability depends entirely on how an embedding application wires up this method.
Server-side request forgery (SSRF) in iFlytek astron-agent through version 1.0.6 lets an authenticated console user steer server-side HTTP requests to internal or otherwise restricted destinations by supplying a crafted endPoint argument to the debugToolV2 API, which reaches UrlCheckTool.checkUrl. The weakness is a redirect-handling gap: the pre-patch validator followed only a single 301/302/303 hop and ignored 307/308, so a URL that passes the initial blacklist/whitelist check can still bounce the request to an internal target; the vendor fixed this in release reward-1575 with a bounded 5-hop chain that revalidates every hop and detects loops. Impact is limited (CVSS 4.0 score 5.3; independent assessment CVSS 3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), requiring valid console credentials, and no public exploit identified at time of analysis.
SQL injection in the console component of iFlytek astron-agent (versions up to and including 1.0.7) lets an authenticated low-privilege user inject arbitrary SQL via the `sortDirection` parameter of the getBotList API, which is concatenated directly into the ORDER BY clause of ChatBotMarketMapper.xml. Because the vulnerable ORDER BY sink cannot return query results to the caller, exploitation is blind (time- or boolean-based), so an attacker with a valid console account and network access to the endpoint could progressively extract backend data - the independent assessment rates confidentiality impact as high (CVSS:3.1 C:H, PR:L, AV:N) with no integrity or availability effect. No public exploit code has been identified at time of analysis, the issue is not listed in CISA KEV, and EPSS data was not supplied; the vendor addressed it in release reward-1575 by whitelisting the sort direction.
A local denial-of-service condition affects Ghidra versions before 12.1.4, where the software-suite's OptionsDB.createUnregisteredOption() routine fails to validate the TYPE_COL byte of an imported program database, triggering an ArrayIndexOutOfBoundsException. The exception path skips the lock-release logic in AbstractTransactionManager, leaving domain objects permanently locked so the application stalls and cannot clean up resources or shut down gracefully. Exploitation is not remote: it requires a Ghidra operator to be socially engineered into importing a maliciously crafted program database file (CVSS 4.0 base 6.8, AV:L/UI:P, availability-only impact), and no authentication or special configuration is needed. At time of analysis there is no public exploit code identified and no evidence of active exploitation, so this is best treated as a genuine but low-priority availability bug rather than a critical flaw.
SQL injection in TDuckCloud tduck-platform through version 5.3 lets an authenticated user inject arbitrary SQL through the orders[0].column sort parameter of paginated listing endpoints, which MyBatis-Plus concatenates directly into the ORDER BY clause. Successful exploitation primarily enables inferential (blind) reading of database contents, consistent with the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N profile and the vendor's CVSS 4.0 score of 5.3 with PR:L and uniformly Low impacts. Proof-of-concept exploitation is publicly available (E:P, matching VulDB's 'exploit publicly available' note), but there is no CISA KEV entry, so confirmed active exploitation in the wild has not been established; no EPSS score was supplied for this record.
Reflected cross-site scripting (CWE-79) in sfturing's hosp_order open-source hospital ordering project, affecting commits up to 627f426331da8086ce8fff2017d65b1ddef384f8, allows remote unauthenticated attackers to execute arbitrary script in a victim's browser by crafting a malicious 'Search' argument to Public Search Handlers in HospitalController.java. Exploitation requires the victim to open a crafted request or URL (user interaction), and publicly available exploit code exists via the project's GitHub issue #118. The project has not responded to the report, so no vendor patch is available; real-world risk is tempered by the project's near-zero deployment footprint.
Authentication bypass in the Keycloak (Red Hat Build of Keycloak) Kerberos federation provider lets an attacker on the same or adjacent network impersonate the Key Distribution Center and bypass Kerberos password authentication, potentially gaining unauthorized access to user accounts. The flaw only manifests in the specific, non-default configuration where Kerberos PASSWORD authentication is used while SPNEGO is disabled, because that mode never requests a server ticket to verify the KDC's identity. Rated CVSS 3.1 6.8 (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), exploitation requires network adjacency and an active on-path spoofing operation; no public exploit code has been identified and the CVE has not been listed as confirmed actively exploited (CISA KEV).
Stored cross-site scripting in XXL-JOB up to 3.5.0 allows an authenticated user with permission to manage job groups to inject script through the Name parameter of the /jobgroup/insert endpoint, which then executes in the browser of any admin who views the job-group listing. Publicly available exploit code exists (a GitHub proof-of-concept), but there is no evidence of active exploitation (not in CISA KEV), and no fixed version has been released because the vendor did not respond to coordination attempts. The practical risk is moderate: session or token theft, forced admin actions via the victim's browser, and defacement within the admin console, but no direct server-side code execution.
Authenticated users of lamp-cloud through 5.10.0 can read any other employee's role codes, permission codes, and full front-end router tree by supplying arbitrary employeeId values to the /anyone/visible/resource endpoint, which never verifies that the requested identifier belongs to the caller. Exploitation is trivial - any low-privilege account suffices, the identifiers appear to be enumerable integers, no user interaction or elevated privilege is required, and publicly available exploit code exists (a Python PoC targeting this exact BOLA condition). The flaw is confirmed as an object-level authorization failure (CWE-639) and is not known to be actively exploited (no CISA KEV listing); impact is limited to read-only disclosure of authorization metadata, which matches the assessed CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Authenticated tenant isolation bypass in jshERP through 3.6 allows any logged-in user to read other tenants' records from the GET /tenant/info endpoint by iterating tenant primary keys, exposing login names, validity dates, user quotas, and enabled state for every tenant on the platform. Exploitation requires only a valid account of any privilege level (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) and publicly available exploit code exists, though CISA KEV does not list this CVE as actively exploited. Impact is a bounded confidentiality leak - CVSS 5.0 with changed scope but no integrity or availability effect - and only materializes on instances that are genuinely multi-tenant with other tenants' records present; a single-tenant deployment exposes nothing beyond the caller's own data.
Authenticated low-privileged users of jshERP through 3.6 can overwrite role button-permission definitions for any role in their tenant by sending arbitrary roleId and btnStr values to the POST /userBusiness/updateBtnStr endpoint, because that handler performs no authorization check on the caller's privileges. Publicly available exploit code exists (a Python POC script is published on GitHub) and the CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L reflects moderate impact confined to the integrity and availability of permission configuration with no confidentiality exposure; the CVE is not listed in CISA KEV, so there is no confirmation of active exploitation.
Self-hosted draw.io deployments running the Docker or WAR build prior to 30.2.7 can have a victim's browser session silently bound to the attacker's own cloud-storage identity, because the OAuth callback handler skips verification of the state token against the session cookie whenever IS_GAE is false. An attacker who completes a legitimate authorization for their own account can then induce a victim to open a crafted callback URL, causing subsequent Google Drive, OneDrive, GitHub, GitLab, or Dropbox actions to be performed under the attacker's identity (CVSS 4.2, CVSS:3.1/AV:N/AC:H/PR:N/UI:R, CWE-352); the impact is session integrity loss and misattribution rather than disclosure of the victim's existing cloud files, and no public exploit identified at time of analysis. The hosted SaaS at app.diagrams.net and any Google App Engine build set IS_GAE=true and are unaffected.
Server-side request forgery in self-hosted draw.io deployments prior to 30.2.7 allows unauthenticated remote attackers to make the server fetch attacker-chosen URLs that resolve to private, link-local, or cloud-metadata addresses, returning internal HTTP responses or instance metadata through the image proxy. The flaw only exists when the server is started with ENABLE_DRAWIO_PROXY=1; the SaaS and desktop editions and default installs are unaffected. Successful exploitation depends on a DNS-rebinding timing race (the hostname must resolve to a public address during validation and to an internal address at connection time), which is why the assessed severity is 6.8 with AC:H rather than a high-severity rating; there is no public exploit code identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 30.2.7.
Path traversal in the self-hosted draw.io server (jgraph/drawio) before version 30.2.7 allows unauthenticated remote attackers to redirect the ExportProxyServlet's internal proxy request to unintended routes on the configured export backend by supplying dot segments (literal or percent-encoded) in the request path. Because the servlet copies all request headers and the request body to the traversed destination, an attacker can reach administration, debugging, health, or configuration endpoints that the export server happens to expose, and may trigger unintended internal actions, though the practical impact is bounded by how that backend is configured. Exploitation requires a deployment that has the export proxy feature enabled and pointed at an internal export service; there is no public exploit identified at time of analysis, and no EPSS score was supplied, so the vendor's modest CVSS of 3.7 is a reasonable reflection of real-world risk.
GoCD servers running versions 12.3.1 through 26.1.0 leak historical full server configuration through legacy /go/admin/restful/* routes to authenticated pipeline group administrators, who should only ever receive configuration for the pipeline groups they administer (CWE-863, incorrect authorization). Exposed data can include agent auto-registration keys, webhook invocation keys, encrypted material credentials and GoCD administrator lists, and a malicious group administrator could reuse a disclosed agent registration key to connect a rogue compatible agent, opening a higher-complexity path to receiving work or overwriting artifacts belonging to other groups. The endpoint is read-only and does not modify server configuration, normal authenticated users are explicitly not affected, and deployments that restrict pipeline editing to full administrators or to configuration repositories are not exposed; no public exploit identified at time of analysis. The issue is fixed in 26.1.0.
Authorization bypass in GoCD versions 18.7.0 through before 26.1.0 lets an authenticated user with a lower-privileged account read a pipeline template's configuration without the required view permission. The Get Template Config API selects its authorization filter through a case-sensitive comparison of the HTTP method name, so a request sent with nonstandard capitalization (for example 'Get' instead of 'GET') slips past the permission check; per the assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) exploitation requires only a valid low-privilege account and exposes read-only configuration data, with no modification of data and no exposure of encrypted secure variables. No public exploit identified at time of analysis; the vendor-released fix is GoCD 26.1.0, and deployments whose reverse proxy rejects or normalizes non-uppercase HTTP methods are not exposed.
Incorrect authorization in GoCD 13.1.0 through versions before 26.1.0 lets an authenticated internal user call the /go/api/support/process_list endpoint without the intended administrator privileges and read command-line arguments, usernames, remote material URLs, and internal material paths for materials they cannot otherwise access. Exploitation is gated by a timing race, since the endpoint only leaks this material metadata while source-control child processes are actively running, and disclosure is bounded because credentials, environment variables, and user-defined secrets remain masked or omitted. No public exploit code or confirmed active exploitation was identified, and the issue is fixed in GoCD 26.1.0.
GoCD servers running versions prior to 26.1.0 expose an authorization flaw in the internal UI /jobStatus.json endpoint that lets any authenticated user (CVSS PR:L) enumerate sequential, server-assigned job IDs and read job metadata - job names, state, progress timestamps, assigned agent IP addresses/UUIDs, and the associated stage and pipeline - for pipelines they are not permitted to view. The API fails to verify that the requested job ID actually belongs to the pipeline and stage named in the request (CWE-639), so the disclosure is bounded to metadata only: console output, artifacts, commands, variables, environment data, and configuration are not returned, and the CVSS 3.1 score is consequently 4.3 (low). The issue is fixed in GoCD 26.1.0; no public exploit code was identified and the flaw is not listed in CISA KEV, so there is no indication of active exploitation at time of analysis.
Stored cross-site scripting in XXL-JOB (xxl-job) 3.4.2 and 3.5.0 lets an authenticated operator inject script through the job 'name' or 'author' fields in the admin Task Management interface (JobInfoController); the payload is persisted and executes in the browser of any other user who later opens the affected job list or detail page. Publicly available exploit code exists, but exploitation requires an existing admin-console account with job create/edit rights plus interaction from a second user, so the practical risk is assessed as low despite the public disclosure. No confirmation of active exploitation (CISA KEV) is present in the available intelligence.
Information disclosure in ScadaBR up to and including version 1.1 allows an attacker to pull the complete project export - data sources, data points and graphical views - by invoking the unprotected EmportDwr.createExportJSON DWR method through /ScadaBR/export_project.htm. The vendor's CVSS 4.0 vector lists PR:N, but the fix adds Common.getUser() plus Permissions.ensureAdmin(), which indicates the endpoint executes inside an authenticated session, so realistic exploitation requires a valid low-privilege ScadaBR account rather than true anonymous access; impact is confined to read-only configuration disclosure with no integrity or availability effect. Publicly available exploit code exists and the issue is fixed in ScadaBR 1.2.0, though there is no confirmation of active exploitation.
Stored cross-site scripting (XSS) in Newbee Mall (newbee-ltd newbee-mall) up to version 1.0.0 allows an authenticated low-privileged user to inject arbitrary JavaScript via the goodsName parameter on the Goods Save endpoint (controller/common/UploadController.java), which can be persisted and executed when a victim views the poisoned content if user uploads are served through the /upload/** static mapping. Exploitation requires authentication (PR:L) and victim interaction (UI:P), and publicly available exploit code exists; the independent assessment rates this as low-to-moderate real-world risk given the required privileges, user interaction, and the niche demo-project deployment base.
Unauthenticated username enumeration in Dromara UJCMS through version 12.3.1 allows remote attackers to query the UserController username-existence endpoint and determine whether a given account name is registered on the target site, leaking account information without any credentials, user interaction, or special configuration. The independent assessment rates this as a low-impact confidentiality leak (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), whose practical value lies in feeding follow-on password-guessing or credential-stuffing campaigns against confirmed accounts rather than in direct compromise. No public exploit code has been identified at time of analysis and the vulnerability is not confirmed as actively exploited (no CISA KEV listing); the vendor was notified via a GitHub issue but has not responded, so no fixed release is available.
An authenticated low-privilege user of the Grimmory (BookLore) self-hosted library service can read book files belonging to other accounts by tampering with the bookId argument passed to the Kobo download endpoint handled by KoboController.streamFileToResponse, an IDOR-style authorization bypass (CWE-639) rated CVSS 5.3 with confidentiality-only impact. Publicly available exploit code exists, and although upstream issue #2431 is closed as completed, its only comment states the report 'has already been reported elsewhere' with no fixing commit or pull request identified there. No KEV listing or independent evidence of active exploitation was found, so real-world risk depends on whether the instance is network-reachable to an attacker who already holds valid credentials and whether the Kobo download feature is exposed.
An incorrect authorization check in Grimmory (grimmory-tools/grimmory, published as BookLore) up to versions 3.3.3 and 3.4.1 lets any authenticated low-privilege account read admin-scoped application settings through the Settings API endpoint GET /api/v1/settings, because AppSettingController.getAppSettings returned the full settings map without filtering entries by the caller's PermissionType (ADMIN / MANAGE_METADATA_CONFIG). The exposure is configuration data - integration flags, OIDC session/group-sync settings, Kobo/Komga/OPDS toggles and metadata-provider configuration - not credentials or write access; the case is assessed at low severity (CVSS 4.0 base 2.1; independent CVSS 3.1 assessment AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) and no KEV exploitation is recorded. Publicly available exploit code exists (referenced GitHub issue 2430) and the issue is rated low real-world risk despite the 'Authentication Bypass' tag, since the attacker must already hold a valid account and only gains read access to settings.
Error-based SQL injection in CordysCRM 1.7.0 through pre-1.7.4 lets an authenticated user holding the MODULE_SETTING_UPDATE permission inject database functions into the sort parameter of POST /account-pool/page, exposing database values through an error oracle when the query returns at least one row. No public exploit code is identified at time of analysis, and the independently assessed impact is confidentiality-only (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N). The vendor fixed the flaw in version 1.7.4.
HTTP request smuggling and header injection in Netty's HTTP/2 stack (as bundled in multiple Red Hat products) allow remote unauthenticated attackers to bypass security controls and manipulate requests when HTTP/2 traffic is translated to HTTP/1.1. Affected deployments include Red Hat AMQ Broker 7, Camel, Keycloak, Quarkus, Data Grid, Fuse, EAP, Apicurio Registry, and Debezium. Assessed as high severity (CVSS 3.1 base 7.5, AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:N); exploitation requires the specific topology of an HTTP/2-to-HTTP/1.1 translation boundary, and no public exploit was identified at time of analysis.
This is a real but moderate-priority vulnerability whose severity depends almost entirely on deployment topology rather than the raw 6.5 CVSS score. Netty's HTTP decoder lets split or duplicated Transfer-Encoding header fields slip past its final-chunked validation, so an unauthenticated, remote attacker who can send a raw crafted request to a Netty listener that sits in an HTTP chain with a second HTTP parser (reverse proxy, load balancer, CDN, WAF, or upstream/downstream server) can desynchronize the two parsers and smuggle a request (CWE-444). Impact is confined to low confidentiality and integrity loss (C:L/I:L) with no availability impact, no authentication (PR:N) or user interaction (UI:N) is required, and no public exploit identified at time of analysis.
Parameter substitution in the Elytron token-realm of Red Hat JBoss EAP 7, JBoss EAP 8 and the EAP Expansion Pack allows a remote attacker to manipulate OAuth2 token-introspection requests because parameters are assembled without URL encoding. Only deployments whose application security domain is backed by a token-realm configured with oauth2-introspection are exposed; other realm types (properties, JDBC, LDAP, or JWT validation without introspection) are unaffected, and the achievable impact is limited to Low confidentiality and Low integrity with no availability impact. Vendor scoring is 4.2 on an AC:H basis because success hinges on how the downstream introspection endpoint parses the injected parameters, and no public exploit has been identified at time of analysis.
JVM memory exhaustion in the wildfly-elytron-asn1 DERDecoder allows unauthenticated remote attackers to exhaust heap on any service that feeds untrusted DER/ASN.1 bytes into the library, notably SASL authentication flows and X.500 certificate principal parsing. The decoder reads an attacker-supplied length value and attempts a corresponding allocation without validating it against the actual remaining input, so a crafted payload can force an oversized allocation and destabilize or crash the JVM (availability impact only, CVSS 5.9, AV:N/AC:H/PR:N/UI:N/C:N/I:N/A:H, CWE-770). Exploitation is opportunistic rather than deterministic because the AC:H rating means success depends on payload size/repetition relative to the victim's configured heap, and no public exploit code has been identified at time of analysis; the issue is not listed in CISA KEV and no EPSS score was provided. Scope is limited to Red Hat products that bundle the affected elytron-asn1 library, including Red Hat Build of Keycloak, JBoss EAP 7/8 (and EAP XP), Red Hat Single Sign-On 7, Fuse 7, Quarkus, Data Grid 8, Camel, Debezium, and Cryostat.
HTTP request smuggling in Netty's HTTP/1.1 decoder (HttpObjectDecoder and the HttpRequestDecoder built on it) lets remote, unauthenticated attackers send a chunk-size line containing an embedded bare carriage return - for example `0\rX` - because strict chunk-line validation is skipped whenever the size line carries no `;` chunk extension, causing a request-boundary desync when Netty shares a connection with a second HTTP intermediary that frames the message differently. The flaw reaches every application and Red Hat product that embeds Netty, including AMQ Broker 7, AMQ Clients, Quarkus, Camel 4 for Quarkus 3, Camel for Spring Boot 4, Keycloak / Red Hat Single Sign-On, JBoss EAP 7 and 8, Fuse 7, Data Grid 8, Apicurio Registry 3 and Debezium 3, while independent assessment keeps it at CVSS 6.5 with AC:H because a standalone Netty service with no disagreeing proxy in the chain yields little practical smuggling impact. The public report includes a reproducible PoC test harness, but there is no CISA KEV listing and no evidence of active exploitation.
An authenticated, low-privilege ArcadeDB user can bypass per-type record ACLs and durably append graph edges to protected vertex types in versions before 26.9.1. The flaw is an incomplete fix of GHSA-c23x-pqcj-7hfm: the authenticated principal is bound only on the HTTP handler thread, while the async worker threads used by the parallel edge-connect phase of POST /api/v1/batch/{database} carry no current user, so LocalDatabase.checkPermissionsOnFile returns early and the CREATE_RECORD/UPDATE_RECORD checks on the target vertex type are never enforced. The attacker must already hold CREATE_RECORD on some edge type and submit an edge-load batch with parallelFlush left at its default of true; setting parallelFlush=false causes the request to be correctly rejected. Impact is confined to integrity of graph adjacency - no protected data is read and there is no denial of service - and no public exploit identified at time of analysis; a vendor patch is available in 26.9.1.
Certificate revocation checking in the OCSP client shipped with Red Hat Build of Apache Camel for Spring Boot 4 can be bypassed because the client does not verify the OCSP-signing Extended Key Usage (EKU) on the certificate that signs an OCSP response, allowing a revoked certificate that still chains to a trusted CA to be accepted as valid. The issue is remotely reachable without authentication or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9), although exploitation is conditional: the deployment must actually rely on this OCSP client for revocation checking and the attacker must already possess a revoked-but-chainable certificate. No public exploit identified at time of analysis, and this is assessed as a genuine but moderate-priority integrity flaw rather than a high-urgency issue.
A signed/unsigned type mismatch in Netty's Memcache binary protocol codec desynchronizes frame boundaries, allowing an unauthenticated, network-positioned attacker to smuggle responses across a shared or proxied memcache connection (CVSS 3.1 base 6.5, Medium). The flaw is reachable only when the Memcache binary codec is explicitly wired into a network-exposed Netty pipeline - a non-default configuration - and the affected code ships inside Red Hat Fuse 7, JBoss Enterprise Application Platform 7, Single Sign-On 7, and the Red Hat Build of Apache Camel for Spring Boot 4. No public exploit code has been identified at time of analysis, and there is no confirmation of active exploitation (not in CISA KEV); impact is limited to confidentiality and integrity (C:L/I:L) with no availability effect.
Certificate revocation validation performed by Netty's optional netty-handler-ssl-ocsp module can be silently skipped when the OCSP response omits the optional nextUpdate field, causing the application to proceed with a certificate that should have been rejected. The flaw is remote and requires no credentials or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9), but exploitation is conditional: the deployment must actually use the opt-in OCSP-stapling component, and the attacker must control or intercept the OCSP response seen by the client, typically through a man-in-the-middle position or by operating the TLS server whose certificate is being validated. There is no public exploit identified at time of analysis and no KEV listing, and the practical impact is confined to acceptance of a revoked or otherwise unvalidated certificate rather than code execution or data disclosure.
Heap memory corruption in snappy-java 1.1.10.8 and earlier allows remote attackers to write attacker-influenced bytes past the bounds of the output array when an application decompresses untrusted compressed data through the typed Snappy.uncompress*Array APIs (such as uncompressIntArray, uncompressFloatArray, or uncompressDoubleArray), which size their result array using the uncompressed length divided by element size while forwarding the undivided length to the native JNI layer. Per the assessed vector (CVSS 3.1 AV:N/AC:L/PR:N/UI:N, C:N/I:L/A:L) no authentication or user interaction is needed, but exploitation is conditional: the consuming application must expose the typed decompression path to attacker-controlled input, and applications that only use the generic byte[] uncompress path are not exposed. Impact is currently rated Low integrity and Low availability (heap corruption and crash) with no confirmed confidentiality loss or demonstrated code execution, and no public exploit was identified at time of analysis; this is a genuine memory-corruption flaw but a moderate, not top-tier, priority, and no vendor-released fixed version is identified in the available data.
Cross-site scripting in the FairEmail Android email app (versions prior to 1.2319) allows a crafted AMP email to execute arbitrary JavaScript inside the message-body WebView once the recipient manually enables the per-message AMP toggle, enabling the attacker to read the message DOM, exfiltrate message data, and draw phishing overlays within the message body. The vulnerable ActivityAMP renderer fails to strip inline script bodies, on* event-handler attributes, and javascript: URLs on non-allowlisted hosts, and the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N confirms unauthenticated remote delivery with required user interaction, scope change, and limited confidentiality/integrity impact but no availability impact. No public exploit code or active exploitation is identified at time of analysis, and practical risk is further lowered because AMP email is uncommon and AMP rendering is off by default.
Unauthenticated information disclosure in NCEAS Metacat versions prior to 3.4.2 allows remote attackers to retrieve internal Apache Solr configuration files such as solrconfig.xml through the client-controlled 'qt' parameter. Because Metacat forwards requests from search endpoints like /d1/mn/v2/query/solr/ to its privileged Solr backend via SolrJ, an attacker can force the /admin/file handler to run even against Solr 7.0+ installations configured with handleSelect=false, and the returned file contents are reflected in an XML error response. No authentication or user interaction is required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N, 5.8), but the impact is limited to configuration and infrastructure profiling rather than code execution or credential theft; no public exploit code or active exploitation has been identified at time of analysis.
Missing space-membership authorization checks in Scoold prior to 1.69.0 let any authenticated user write replies and comments into question threads belonging to private spaces they are not members of, resulting in unauthorized modification of private discussions. The flaw only manifests in the non-default configuration where scoold.is_default_space_public is set to false and private spaces are actually in use, and it requires a valid session plus knowledge (or enumeration) of a target question identifier; the attacker gains write access only, not read access, to the affected thread. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, 6.5), exploitation is authenticated and integrity-only, and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis; the vendor-released fix is version 1.69.0.
Scoold deployments prior to 1.69.0 expose replies to questions in private spaces through the answers API: a holder of a valid personal API token can call GET /api/posts/{id}/answers and receive the reply bodies of a private-space question whose own endpoint correctly denies access. The flaw affects instances configured with both scoold.api_enabled and scoold.api_user_access_enabled set to true, and exploitation additionally requires the attacker to know or enumerate the target question's identifier, so it is a confidentiality-only (C:H, no I/A) disclosure of existing private discussion content rated 6.5. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV); the vendor has released a fix in 1.69.0.
Mutual-authentication bypass in AsyncHttpClient (AHC) 3.0.8 through 3.0.11 allows a man-in-the-middle who cannot prove knowledge of the shared secret to be accepted as a legitimate server when SCRAM-SHA-256 or Digest mutual authentication is used over a non-TLS or already-compromised transport. The affected interceptor methods computed the SCRAM ServerSignature or Digest rspauth verification value but only logged a mismatch and still delivered the response to the application as authenticated, so the client silently loses its only signal that the peer is an impostor. Over TLS the flaw is inert because a genuine server always returns a valid verification value; exploitation requires a MITM position (AC:H), the impact is limited to authentication-assurance loss (C:N/I:L/A:N), and no public exploit code or active exploitation has been identified at time of analysis. Fixed in version 3.0.12.
Cleartext exposure of origin credentials in AsyncHttpClient (AHC) 2.0.0-2.16.0 and 3.0.0-3.0.11 occurs when a Java application reaches an HTTPS origin through an HTTP CONNECT proxy while using preemptive origin authentication: the library attaches the origin's Authorization header - Basic or Digest credentials, plus per-connection NTLM/Kerberos/SPNEGO tokens - to the plaintext CONNECT request before any TLS tunnel exists, so the proxy and any observer on the client-to-proxy hop can read credentials meant only for the origin. The vulnerability is rated CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) with high confidentiality impact but a high attack-complexity qualifier, because exploitation requires the specific non-default combination of a CONNECT proxy, preemptive origin authentication, and an adversary positioned on that network segment; authentication requirements are not confirmed from the supplied vector beyond PR:N, and there is no public exploit identified at time of analysis. Vendor-released patches are 2.16.1 and 3.0.12, and because 3.0.12 is itself affected by a separate Digest-to-Basic downgrade flaw (GHSA-rqf5-2wxv-rjf4), 3.0.13 is the recommended target on the 3.x line.
Connection-permit leakage in the AsyncHttpClient (AHC) Java library versions 3.0.8 through 3.0.11 can permanently exhaust a configured connection pool and deny service to subsequent HTTP requests. Applications are exposed only if they set maxConnections or maxConnectionsPerHost above zero; each TLS connection attempt that aborts before the handshake completes strands one permit, because NettyConnectListener removes the partitionKeyLock permit from NettyResponseFuture before every failure path is bound to the channel's closeFuture. Repeated pre-handshake TLS failures can lock out a single host under a per-host limit or drain the shared pool under a global limit even when no connection remains open; the default unlimited setting is not affected, no public exploit code was identified at time of analysis, and the issue is fixed in 3.0.12.
Credential disclosure in AsyncHttpClient (Java) allows a client configured with a client-wide Realm via config.setRealm(...) and with redirect following enabled to leak Basic, Digest, Negotiate, or NTLM credentials to an attacker-controlled origin. When a cross-origin or scheme-downgrade redirect clears the per-exchange realm, the authentication interceptor in Interceptors.java falls back to config.getRealm() and re-attaches the client-wide credentials; if the attacker's target then answers HTTP 401, the client sends those credentials or tokens to that foreign origin. Affected releases are 2.14.5 through 2.16.0 and 3.0.9 through 3.0.11, fixed in 2.16.1 and 3.0.12; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the flaw is conditional on the specific client-wide Realm configuration, redirect following, attacker-influenced redirect, and a 401 response (AC:H per the assessed vector).
MariaDB Connector/J versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9 can be tricked into transmitting a locally selected file to a rogue or man-in-the-middle database server even when the allowLocalInfile option is explicitly set to false, because the connector processes a server-initiated LOCAL INFILE packet (0xfb) without honoring that setting. The exposure is narrow: the attacker can only receive the exact file the application already chose to load via a LOAD DATA LOCAL INFILE COM_QUERY, cannot redirect the request to an arbitrary path, and gains nothing unless the application organically loads sensitive data over an untrusted connection - so this is a low-severity (CVSS 3.7), highly conditional information-disclosure issue rather than a widespread threat. The vulnerability is unauthenticated at the network layer per the vector (PR:N) but requires high attack complexity (AC:H) and control of the server or the connection path; no public exploit code has been identified at time of analysis, and the flaw is fixed in the four versions listed above.
Path traversal in SmallRye JWT's AwsAlbKeyResolver lets an unauthenticated remote attacker force the application server to issue GET requests to arbitrary paths on the same origin as the configured AWS ALB key endpoint, because the attacker-controlled 'kid' header is concatenated into the key-fetch URL without sanitizing path traversal characters or query-string separators. Only applications that explicitly enable the non-default AWS_ALB key provider (used to verify JWTs signed by AWS Application Load Balancers) are affected; installations using other key resolvers are unaffected. The impact is confidentiality-only and limited to non-public endpoints or internal data reachable on that same origin, since the rogue request fires before JWT signature verification. No public exploit code or active exploitation was identified at time of analysis, and no EPSS score was supplied; Red Hat (secalert@redhat.com) tracks the issue as a moderate-severity path traversal.
Password cracking in admin3 3.0.0 and earlier allows anyone who obtains the application's credential database to recover user plaintext passwords offline, because stored credentials use single-round MD5 salted only with the username and no key-derivation function. The flaw does not grant database access by itself - it requires a prior compromise (database breach, SQL injection, exposed backup, or insider/privileged access, reflected by the CVSS PR:H prerequisite), but once that precondition is met, cracking is trivial on commodity hardware; publicly available exploit code exists. With a vendor score of 4.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N) and no confirmed active exploitation, this is a genuine but conditional, low-to-moderate risk that amplifies the impact of an upstream data exposure rather than creating one.
Disabling or locking a user account in admin3 through 3.0.0 does not invalidate that user's existing bearer tokens, so a previously authenticated user retains full access with their original permissions after the account is disabled. The root cause is twofold: the AuthInterceptor never re-checks the user's locked status on subsequent requests, and LocalSessionManager resets session expiry on every request, so a pre-existing token never lapses through inactivity. Publicly available exploit code exists (a proof-of-concept account-lockout-bypass script), and exploitation requires that the attacker already held a valid token issued while their account was enabled (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, CVSS 5.4) - a rogue-insider or post-disable persistence scenario rather than unauthenticated compromise. Confirmed actively exploited (CISA KEV) status is not indicated by the available data, and there is no privilege escalation beyond the disabled account's original permission set.
Path traversal in junrar (the open source Java RAR archive library) prior to version 7.6.1 lets an attacker-supplied RAR archive cause LocalFolderExtractor to create directories outside the intended extraction root. The flaw exists because createFile() validates only the final canonical file path while makeFile() creates intermediate path segments with unchecked mkdir() calls, so a crafted entry whose final path resolves inside the destination can still spawn directories elsewhere - a specificity that is why the assessed vector carries AC:H. Impact is confined to directory creation and file-versus-directory squatting that can make later security-sensitive writes fail; there is no arbitrary file-content write and no confidentiality loss, unauthenticated remote attackers are the relevant threat model only when a host application extracts untrusted archives through this specific extractor, and no public exploit code has been identified at time of analysis. This is a genuinely low-priority issue, and the vendor's CVSS of 3.7 reflects that honestly rather than inflating it.
Missing authorization in the ChangeWeDer CRM UserController index endpoint allows a remote attacker with a low-privilege authenticated account to reach functionality or data that should require stronger privileges, with limited confidentiality, integrity, and availability impact. The product has no versioning scheme and the project has not responded to the issue report, so no patched release is confirmed; exploitation requires network access to the Java CRM application and a valid low-privilege session. No public exploit identified at time of analysis.
Authenticated blind SQL injection in ScadaLTS 2.8.1-release-candidate build 0 lets any logged-in user with the lowest privilege tier (ROLE_USER, ROLE_ADMIN, or ROLE_PUBLIC) extract arbitrary database contents, including password hashes for every account on the platform. The flaw lives in the JSON sortBy array accepted by POST /api/events/search, whose values are concatenated straight into the SQL ORDER BY clause with no sanitization or parameterization, forcing attackers to use slower time-based and boolean-based inference rather than in-band extraction. CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) is well calibrated: exploitation requires valid credentials but scada-lts deployments that grant ROLE_PUBLIC or self-service low-privilege accounts effectively erase that barrier, and there is no public exploit code and no confirmed active exploitation (CISA KEV) at time of analysis.
Server-side request forgery in Hippo4j through 1.5.0 allows an authenticated user of the Hippo4j server console to force the application to issue outbound HTTP GET requests to arbitrary hostnames and ports, because four ThreadPoolController endpoints accept a clientAddress parameter without validation. Affected deployments are those running the Hippo4j console with reachable internal services or cloud metadata endpoints (for example 169.254.169.254); the CVSS v3.1 score is 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting a confidentiality-only impact gated behind a valid console session (PR:L) with no user interaction. No public exploit code or confirmed active exploitation was identified at time of analysis, and the practical impact against cloud environments depends on whether the instance exposes a metadata service and on whether the affected endpoints return the fetched response body, which is not confirmed by the available source data.
Credential isolation bypass in Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier allows an authenticated user who holds Item/Configure permission on a folder to reach 'alternative GitLab API token credentials' that are scoped to a different folder and that they are not entitled to use, because the plugin caches the GitLab API client under a cache key derived solely from the credentials ID and never incorporates the folder in which the credentials were resolved. Rated CVSS 3.1 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) under CWE-522 (insufficiently protected credentials), the issue is a moderate authorization/credential-isolation flaw rather than an unauthenticated remote compromise, and it only exists on multi-tenant Jenkins controllers that actually rely on folder-scoped credentials - single-tenant installations and controllers where all credentials are global/system-scoped see no practical impact. There is no public exploit identified at time of analysis, CISA SSVC records Exploitation: none and Automatable: no, and the CVE is not KEV-listed, so it warrants scheduled patching rather than emergency response.
Information disclosure in Jenkins Gradle Plugin 2.19.1252.v15196b_5a_6e10 and earlier lets an authenticated Jenkins user who can influence the build log of a Gradle job trick the plugin into fetching build scan data from an attacker-controlled URL in preference to the Develocity server URL set in the plugin's global configuration. Because the plugin attaches the globally configured Develocity access key to that outbound request, the attacker can capture the credential; instances with no Develocity access key configured have nothing to leak, so exposure is conditional rather than universal. No public exploit code has been identified at time of analysis, and this is a genuine but moderate-severity issue: exploitation requires authenticated job-run or job-configure privileges plus a configured access key, and the resulting impact is limited to confidentiality (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).
Path traversal in the Jenkins Pipeline: Groovy Libraries Plugin (805.va_fc79344957d and earlier) lets an authenticated user who can configure Pipelines point the `library` step at a path outside the SCM checkout and follow symbolic links, giving read access to files in a resources directory and the ability to delete files in a test directory on the Jenkins controller file system. Exploitation requires the Pipeline-configuration privilege, a symlink placed inside the checkout, and successful traversal during library retrieval, which is reflected in the high attack complexity of the assessed CVSS:3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, base score 4.2). No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), so the practical risk is low-to-moderate and confined to file read and limited file deletion rather than arbitrary write or code execution.
Credential disclosure in Jenkins Pipeline: Multibranch Plugin 841.vec5b_9e1806ec and earlier allows users who already hold Item/Configure permission to capture credentials they are not entitled to by authoring or modifying a Pipeline that invokes the resolveScm step, which fails to establish the correct context for credentials lookup. The issue is an access-control scoping flaw (CWE-863) rated CVSS 3.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting the authenticated Item/Configure prerequisite, the high complexity of targeting specific credential IDs, and impact limited to confidentiality with no integrity or availability effect. It requires a Jenkins instance that actually uses Pipeline/multibranch jobs with resolveScm; at time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified, though the vendor advisory of 2026-09-16 should be reviewed for the fixed release.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to read CRM approval-workflow data through GET /admin-api/crm/flow/flow-users, disclosing approval chain topology, step ordering, approver identifiers, and personal information such as login names, nicknames, departments, email addresses, mobile numbers, and last-login IP addresses. The endpoint does enforce authentication but omits any role or permission check, so a single low-privilege admin-panel account is sufficient - no elevated privileges, user interaction, or special configuration are required. Publicly available exploit code exists for this issue, although the CVE is not listed in CISA KEV; the practical barrier to exploitation is the requirement to hold or obtain a valid back-office session.
Missing authorization in the StoreProductController onSale handler of Yshop CRM through 2.1.3 allows any authenticated back-office user (regardless of assigned role) to toggle product sale status by calling GET /admin-api/product/store-product/sale with sequential product IDs, letting them withdraw entire catalogs from sale or re-enable withdrawn products. The flaw is an integrity-only issue (CVSS 3.1 base 5.3, PR:L) - it is not reachable anonymously and causes no data disclosure or service outage. Publicly available exploit code exists (a Python PoC published alongside the request), but there is no confirmed active exploitation (not in CISA KEV); this is a genuinely low-to-moderate risk issue despite the CRITICAL-sounding CWE-862 label.
Authenticated back-office users can abuse yshop-crm through 2.1.3 to send SMS and email to arbitrary customers via POST /admin-api/crm/customer/send-sms and /send-mail, because CrmCustomerController does not enforce authorization on those actions. Publicly available exploit code exists, but exploitation requires a valid back-office account (PR:L), is remote with no user interaction, and yields only limited integrity impact; no confidentiality or availability impact is assessed. The practical risk is therefore concentrated on malicious insiders or attackers who have already obtained CRM credentials, not pre-auth compromise of default installations.
Reflected cross-site scripting in kkFileView 5.0.0 through 5.0.2 lets unauthenticated remote attackers inject JavaScript into the /onlinePreview endpoint, where the user-controlled `page` and `kkagent` query parameters are passed by OnlinePreviewController into FreeMarker templates and emitted unescaped inside raw JavaScript contexts. Because the CVSS vector is PR:N with UI:R, the attacker needs no credentials but must convince a victim to open a crafted link; successful exploitation runs script in the victim's browser origin, allowing session or token theft and actions performed as the victim, with no server-side code execution or backend data compromise. There is no confirmation of active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and EPSS is low at 0.17% (6th percentile), though the reflected, non-persistent nature of the flaw means each victim must be individually lured.
Use-after-free in zstd-jni's Dictionary Sharing component allows remote attackers to corrupt native heap memory through the ZstdCompressCtx.loadDict() and ZstdDecompressCtx.loadDict() APIs in versions up to 1.5.7-13. The defect is a logic inversion in shared-lock accounting: the code releases the reference count on the incoming dictionary parameter rather than on the previously held dictionary reference, causing the old native buffer to remain referenced after it can be freed by another thread. A public proof-of-concept exists via GitHub issue #404, and vendor released a confirmed fix in version 1.5.7-14.
Missing function-level and data-scope authorization in SmartAdmin API (Java17/SpringBoot3) 3.30.0 lets any authenticated low-privileged employee retrieve employee directory records belonging to other departments and users through a single request to the /employee/queryAll endpoint. The impact is confined to information disclosure (CVSS 4.3, confidentiality:Low, no integrity or availability effect), and exploitation requires a valid low-privileged employee session - the flaw does not allow unauthenticated access. No public exploit has been identified at time of analysis, and the EPSS score of 0.19% (9th percentile) is consistent with the low assessed severity.
Arbitrary file write in Keyfactor SignServer before 7.6.0 requires an authenticated administrator to configure a SignerStatusReportWorker output path, allowing the process to create or overwrite files as the local JBoss user. Because the path is not validated against a safe directory and can reference an existing file, a malicious or compromised admin could overwrite files accessible to the JBoss service account; the assessed impact is integrity-only with no confidentiality or availability impact, and no public exploit identified at time of analysis (EPSS 0.15%). Affected deployments are those running SignServer versions before 7.6.0.
Stored cross-site scripting in itranswarp's Markdown rendering pipeline allows authenticated users to inject arbitrary JavaScript into page content that executes in other visitors' browsers. The flaw exists in the `Markdown.toHtml()` method of `Markdown.java`, which fails to sanitize malicious HTML or script constructs embedded in Markdown input before writing rendered output to the page. All 2.x releases through 2.19 are affected, the project is officially end-of-life with no maintainer response to the vulnerability report, and exploit code has been publicly published.
Missing authorization in the A2A Java SDK (a2aproject/a2a-java) 1.2.0 allows a caller with a valid account to invoke the ListTasks operation without the list-scoped read check that guards other task operations, so task listings are returned to principals that the configured TaskAuthorizationProvider may have intended to reject entirely. The flaw lives in AuthorizationRequestHandlerDecorator.onListTasks in server-common, which delegated to the handler without first consulting the authorization provider for the list scope, leaving protection to per-task filtering inside the TaskStore. It is fixed in release 1.3.0 (tag v1.3.0.Final, commit e9a1abf9c90c02b16d17293afdc3cc2f555d63a6); CVSS 4.0 base is 5.3, there is no CISA KEV listing and no public exploit code identified at time of analysis.
HTTP response splitting in a2a-java 1.2.0 allows attackers who control push notification authentication credentials to inject arbitrary HTTP headers by embedding CR/LF characters in the Authorization header assembled by `BasePushNotificationSender.dispatchNotification()`. The root cause is direct concatenation of client-supplied `scheme` and `credentials` fields into an outbound HTTP header without CRLF sanitization. No public exploit has been identified at time of analysis; vendor-confirmed patch is available as v1.3.0.Final.
Server-side request forgery in tarzan-cms 1.0.0 allows remote attackers to force the application server to initiate arbitrary outbound HTTP connections by manipulating the `httpUrl` argument passed to the `openConnection()` method in `ThemeService.java`. The Theme Download Function passes user-supplied URL input directly to a connection handler without adequate validation, enabling internal network reconnaissance, cloud metadata endpoint access, or pivoting to backend services. A proof-of-concept has been publicly disclosed via a Gitee issue report; no vendor patch exists and the project maintainer has not responded to the disclosure.
Missing authorization in wxiaoqi Spring-Cloud-Platform's OnlineController allows authenticated low-privileged users to invoke getOnlineInfo without proper access checks, exposing session and online-user data beyond their intended permission scope. Affected versions are 1.0, 2.2, and 3.0 of the ace-admin module. A public proof-of-concept exploit (poc_vuln2_session_exposure.zip) has been released, though no vendor patch exists and the project has not responded to the coordinated disclosure via GitHub issue #65.
Missing authorization in wxiaoqi Spring-Cloud-Platform 3.0.1 and 3.1.0 enables remote authenticated attackers to bypass permission enforcement via the `checkUserPermission` function in the Permission Service RPC component. A proof-of-concept exploit (`poc_vuln1_failopen_authz.zip`) is publicly available on GitHub, lowering the barrier to exploitation. The vendor has not responded to the issue report filed at the project repository, leaving affected deployments without an official patch.
Unconstrained memory allocation in TooTallNate Java-WebSocket 1.6.0-1.6.1 allows remote unauthenticated attackers to exhaust server heap memory by sending WebSocket frames with arbitrarily large declared payload lengths. The Draft_6455 fragmentation handler initialized maxFrameSize to Integer.MAX_VALUE (~2 GiB), so the library attempts to allocate the full declared frame size before any payload data is actually received. A publicly available proof-of-concept exists via GitHub issue #1508; the upstream fix is in PR #1509 but has not yet shipped in a tagged release.
Improper authorization in TaleLin lin-cms-spring-boot 0.2.1 and earlier lets remote unauthenticated attackers read book records they are not entitled to by manipulating the ID argument supplied to the BookController.getBook endpoint (CWE-285, an object-level authorization gap equivalent to an IDOR). Exploitation requires no authentication, no user interaction and no non-default configuration, and publicly available exploit code exists, though the impact ceiling is low - read-only disclosure of book data with no integrity or availability effect. The issue is not listed in CISA KEV, and the maintainer did not respond to the VulDB disclosure, so no patched version has been identified.
Stored cross-site scripting in huanzi-qch base-admin lets a low-privileged authenticated user inject script through the Username argument of the Add User handler (CommonController.java Save), which then executes in the browser of any user - typically an administrator - who later views the tainted page. Exploitation requires a valid low-privileged account plus victim interaction (viewing the rendered username), and publicly available exploit code exists; no confirmed active exploitation is indicated (no CISA KEV listing). Because the project ships via continuous rolling releases, no fixed version has been published and the vendor did not respond to the disclosure.
SQL injection in java110 MicroCommunity (through version 2.0) allows remote attackers to inject arbitrary SQL through the fallBackSql argument of the fallBack API endpoint implemented in BusinessApi.java / QueryServiceSMOImpl.fallBack. Publicly available exploit code exists (published as a Gitee issue), and because CVSS 4.0 carries PR:N, exploitation is claimed to need no authentication - though an independent assessment notes the endpoint may in practice sit behind application authentication, which would narrow real-world exposure. The project has not responded to the report, so no vendor fix is identified, and the CVE is not listed in CISA KEV, meaning confirmed active exploitation has not been established.
Path traversal in weiqingwen spring-boot-forum lets an authenticated forum user escape the intended avatar storage path by manipulating the Username argument processed in NewUserFormValidator.validate during avatar upload. The issue is remotely reachable and, per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), requires a valid forum account while yielding only Low confidentiality and integrity impact because the traversal is scoped to the avatar file-handling path. Publicly available exploit code exists, the maintainer did not respond to the disclosure, and because the project ships rolling releases with no tagged versions there is no known fixed release to migrate to.
Unsalted MD5 password hashing in sfturing hosp_order (code through commit 627f426331da8086ce8fff2017d65b1ddef384f8) leaves stored user credentials cheaply crackable if the hash store is ever exposed. The defect is not a remotely reachable primitive: per the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N) an attacker with low privileges must first obtain the password digests - through a separate vulnerability, a database compromise, or a backup leak - before the missing salt provides any advantage, which is why impact is limited and complexity is high. Publicly available exploit code exists that demonstrates the weak hashing, but there is no confirmed active exploitation (no CISA KEV listing), and the project has not responded to the issue report, so no vendor-released patch is identified at time of analysis.
Atom-table exhaustion in RabbitMQ's x-jms-topic exchange lets an authenticated low-privilege AMQP user crash an entire broker node in fewer than 100 binding declarations, turning a vhost-confined account into a cross-tenant denial of service. The flaw is reachable only when the bundled rabbitmq_jms_topic_exchange plugin is enabled - standard in any JMS deployment - and the attacker holds read permission on an x-jms-topic exchange plus write permission on a queue, or configure rights to declare both; it also requires a raw AMQP client, because the broker does not enforce the client-side selector compilation that the Java JMS client performs. Fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0; no public exploit identified at time of analysis and no CISA KEV listing, though the attack needs no user interaction and is network-reachable, with an assessed CVSS 3.1 score of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
Cross-site request forgery in the sfturing hosp_order Java application allows an attacker to forge state-changing requests through CommonUserController.java while a logged-in user holds an active session, yielding a limited integrity impact. Publicly available exploit code exists and has been disclosed via upstream issue #122, but there is no KEV listing and no evidence of confirmed active exploitation; EPSS data was not provided. With a CVSS 4.0 base score of 2.1 and a very small deployment base for this obscure, unversioned project, this is a low real-world priority.
Cleartext SMTP email transmission in sfturing hosp_order (MailUtil.getProperties) can expose sensitive email-related data to an attacker who already holds a network interception position between the application server and the mail server. Publicly available exploit code exists, but there is no confirmed active exploitation; the issue requires an unencrypted SMTP configuration and high-complexity adversary-in-the-middle access, and it produces only limited confidentiality impact. This is assessed as a low-real-risk issue despite the nominal CVSS 4.0 score of 6.3.
sfturing hosp_order stores sensitive information in cleartext in CommonUserServiceImpl.java, allowing a local attacker with a low-privilege authenticated account to read exposed data without user interaction. The issue is a low-severity local confidentiality-only flaw (CVSS 4.0 base score 1.9; independent CVSS 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) affecting all versions tracked by CPE cpe:2.3:a:sfturing:hosp_order:*:*:*:*:*:*:*:*; because the project uses rolling releases and has not responded, no fixed version is available. Publicly available exploit code exists, but there is no CISA KEV confirmation.
Hard-coded database credentials in sfturing hosp_order (file ssm_pro/src/main/resources/jdbc.properties) enable unauthenticated attackers who obtain the credentials from the public source repository to directly access the backing database, potentially reading and modifying data, provided the credentials remain unchanged and the database is network-reachable. Publicly available exploit code exists (GitHub issue #119), but the CVSS 4.0 base score is 2.9 and the independent assessment rates this as a low real-world priority because high attack complexity (AC:H) and deployment prerequisites-such as credential rotation or database network restrictions-neutralize the flaw. No confirmed active exploitation (CISA KEV) has been reported, and no vendor-released patch is identified.
Catastrophic regex backtracking in the JLine3 `nano` editor's regex search mode allows an authenticated user to hang the editor session thread at high CPU, producing a denial of service. The flaw affects applications that embed `org.jline:jline-builtins` and expose the nano editor: `jline-builtins` 3.0.0 through 3.30.14 and 4.0.0 through 4.3.0 are impacted (CWE-1333, CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). A proof-of-concept reproduction, using a buffer of repeated 'a' characters and the pattern `(a+)+b`, is documented in the vendor advisory, and vendor-released patches exist in 3.30.15 and 4.3.1; no confirmed active exploitation (CISA KEV) or public exploit code beyond the advisory PoC has been reported. Practical severity depends on deployment: in a single-user local terminal the user only hangs their own session, whereas remote multi-user services that share worker threads can lose a server thread indefinitely.
A crafted HISTORY_IGNORE value can hang a JLine reader session (org.jline:jline-reader) via catastrophic regular-expression backtracking, pinning the reader thread at high CPU each time a command line is written to history. Applications that embed JLine 3.x (>= 3.0.0, < 3.30.15) or 4.x (>= 4.0.0, < 4.3.1) and let HISTORY_IGNORE be set from user configuration or application settings are affected; the impact is limited to denial of service with no confidentiality or integrity effect. The attacker must already be able to control configuration (CVSS vector PR:L, AV:L), so this is a low-to-moderate real-world priority; no public exploit code was identified at time of analysis, although the vendor advisory documents deterministic reproduction steps, and vendor patches shipping the fix are available in 3.30.15 and 4.3.1.
GoCD versions 20.2.0 through 26.0.x disclose the complete list of configured usernames and role names to any authenticated user through the internal pipeline-structure autocompletion API, even when that user has no administrator privileges. The endpoint is reached remotely over HTTP (AV:N) and requires only a valid low-privileged account (PR:L), so a regular GoCD user can enumerate tenant user and role identifiers to support follow-on credential-stuffing, phishing, or targeted attacks, though the response never maps users to roles and cannot modify any data. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the disclosure is limited to names, which is why the independently assessed severity remains low. GoCD 26.1.0 contains the vendor fix.
GoCD 20.2.0 through pre-26.1.0 allows any authenticated user to retrieve inter-pipeline dependency hierarchy details and user-defined pipeline, stage, job, and artifact plugin reference names via the internal fetch-artifact auto-suggestion API at /go/api/internal/pipelines/**/upstream, bypassing per-pipeline view authorization. The endpoint is read-only, so impact is limited to information disclosure that matters primarily where pipeline visibility is restricted per user or team; single-team installations expose little extra. No public exploit code was identified at time of analysis, and the issue is fixed in version 26.1.0.
HTTP request desynchronization in Apache Tomcat allows an unauthenticated remote attacker to cause a single request belonging to another user to fail when Tomcat is deployed behind a reverse proxy. The flaw (CWE-444) arises because Tomcat processes the Transfer-Encoding header on HTTP/1.0 requests, and when a fronting proxy interprets that header differently, the two sides disagree about request boundaries on a shared upstream connection. Affected releases are 11.0.0-M1 through 11.0.25, 10.1.0-M1 through 10.1.59, 9.0.47 through 9.0.121, and the end-of-life 8.5.67 through 8.5.100; standalone Tomcat with no fronting proxy is not affected. The assessed impact is availability-only (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) - no persistence, data exposure, or code execution is described - and no public exploit code was identified at time of analysis.
Apache Tomcat's OpenSSL and OpenSSL-FFM TLS connectors ignore certificate revocation lists when the certificate is loaded from a keystore, so a client certificate that has already been revoked can still be accepted for mutual-TLS authentication. Affected releases are 11.0.0-M1 through 11.0.25, 10.1.0-M1 through 10.1.58, and 9.0.0-M1 through 9.0.121, with end-of-life 8.5.0 through 8.5.100 also known to be affected; fixed versions are 11.0.26, 10.1.59, and 9.0.122. No vendor CVSS score, EPSS value, CISA KEV entry, or public proof-of-concept was supplied, and our internal assessment rates the issue CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, reachable unauthenticated but only in the non-default combination of an OpenSSL or OpenSSL-FFM TLS connector, keystore-based certificates, mutual-TLS client-certificate authentication, and CRL-based revocation checking; no public exploit identified at time of analysis.
Content-Disposition enforcement bypass in Apache Sling Security Bundle before 1.3.12 allows remote attackers to circumvent the ContentDispositionFilter by accessing attacker-influenced resources through an alternate URL/API shape not mediated by the filter, potentially causing resources to be served inline rather than as attachments. This protection-mechanism failure (CWE-693) can lead to low confidentiality and integrity impacts, such as information disclosure or client-side script execution, and requires user interaction to open a crafted link. Deployments that rely on this filter for content-disposition protection are affected; no public exploit identified at time of analysis.
Cross-site scripting in the Apache Sling XSS Protection API before version 2.4.12 allows unauthenticated remote attackers to have attacker-supplied script execute in a victim's browser session when an application built on the library routes untrusted, attacker-influenced input through the flawed sanitization/encoding routines and reflects it into an HTML response. Because the affected artifact is a shared library rather than a standalone server, exposure depends entirely on the consuming application - most commonly Apache Sling-based sites and Adobe Experience Manager - and exploitation requires the victim to load the crafted page or click a malicious link (user interaction). Neither NVD nor Apache published a CVSS score for this issue, so severity must be inferred from the library-level flaw and the deployed context; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N (unauthenticated, user-interaction dependent, scoped impact affecting the embedding application), and no public exploit identified at time of analysis.
Remote code execution on the Apache Doris Frontend (FE) is achievable when a privileged, already-authenticated user supplies a crafted JDBC driver URL that the FE loads without sufficient validation, a case of inclusion of functionality from an untrusted control sphere (CWE-829). The assessed vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) shows the flaw is network-reachable but gated behind high privileges, meaning only accounts that can define or modify JDBC catalogs or external resources can reach the vulnerable code path; anonymous or low-privilege actors are out of scope, and no user interaction or default-configuration vector exists for an external unauthenticated attacker. No CVSS score, EPSS value, KEV entry, or proof-of-concept was supplied in the source data, so there is no confirmation of active exploitation and no public exploit identified at time of analysis, leaving quantitative prioritization signals absent.
Cross-site scripting in Apache Sling XSS before 2.4.12 allows remote attackers to inject script that executes in a victim's browser when an application relying on the library's output encoding and sanitization renders attacker-influenced input through a code path where neutralization is incomplete. Exploitation is conditional: it requires a reflected or stored injection point in the consuming application and victim interaction (loading the affected page) for script execution, and applications that apply their own independent output encoding are not exposed. The vendor-released fix is version 2.4.12; no public exploit code identified at time of analysis, no EPSS data was supplied, and no public CVSS score or vector (Apache and NVD both N/A) exists, so severity must be inferred from the independently assessed vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.
Denial of service in Apache Sling XSS (before 2.4.12) allows remote unauthenticated attackers to exhaust server resources by passing XML content with recursively defined DTD entities through the Sling XSS protection module, which expands them without bound. This CWE-776 XML entity expansion flaw only affects availability (no data compromise) and requires the application to route attacker-controlled XML to the vulnerable parser. No public exploit code or active exploitation has been identified, and the vendor recommends upgrading to 2.4.12.
Reflected cross-site scripting in the Apache Sling XSS library 2.4.10 and earlier arises because the XSSAPI.getValidHref() helper fails to properly neutralize certain attacker-supplied values, returning an href that a consuming application may then render into a page. Remote, unauthenticated attackers can exploit this only where a downstream application actually uses getValidHref() as its sanitizer for attacker-influenced link values and reflects that value back to users, and a victim must click a crafted link for the script to execute (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N). No public exploit code and no confirmed active exploitation were identified at time of analysis, and overall risk is low because reachability depends entirely on how an embedding application wires up this method.
Server-side request forgery (SSRF) in iFlytek astron-agent through version 1.0.6 lets an authenticated console user steer server-side HTTP requests to internal or otherwise restricted destinations by supplying a crafted endPoint argument to the debugToolV2 API, which reaches UrlCheckTool.checkUrl. The weakness is a redirect-handling gap: the pre-patch validator followed only a single 301/302/303 hop and ignored 307/308, so a URL that passes the initial blacklist/whitelist check can still bounce the request to an internal target; the vendor fixed this in release reward-1575 with a bounded 5-hop chain that revalidates every hop and detects loops. Impact is limited (CVSS 4.0 score 5.3; independent assessment CVSS 3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), requiring valid console credentials, and no public exploit identified at time of analysis.
SQL injection in the console component of iFlytek astron-agent (versions up to and including 1.0.7) lets an authenticated low-privilege user inject arbitrary SQL via the `sortDirection` parameter of the getBotList API, which is concatenated directly into the ORDER BY clause of ChatBotMarketMapper.xml. Because the vulnerable ORDER BY sink cannot return query results to the caller, exploitation is blind (time- or boolean-based), so an attacker with a valid console account and network access to the endpoint could progressively extract backend data - the independent assessment rates confidentiality impact as high (CVSS:3.1 C:H, PR:L, AV:N) with no integrity or availability effect. No public exploit code has been identified at time of analysis, the issue is not listed in CISA KEV, and EPSS data was not supplied; the vendor addressed it in release reward-1575 by whitelisting the sort direction.
A local denial-of-service condition affects Ghidra versions before 12.1.4, where the software-suite's OptionsDB.createUnregisteredOption() routine fails to validate the TYPE_COL byte of an imported program database, triggering an ArrayIndexOutOfBoundsException. The exception path skips the lock-release logic in AbstractTransactionManager, leaving domain objects permanently locked so the application stalls and cannot clean up resources or shut down gracefully. Exploitation is not remote: it requires a Ghidra operator to be socially engineered into importing a maliciously crafted program database file (CVSS 4.0 base 6.8, AV:L/UI:P, availability-only impact), and no authentication or special configuration is needed. At time of analysis there is no public exploit code identified and no evidence of active exploitation, so this is best treated as a genuine but low-priority availability bug rather than a critical flaw.
SQL injection in TDuckCloud tduck-platform through version 5.3 lets an authenticated user inject arbitrary SQL through the orders[0].column sort parameter of paginated listing endpoints, which MyBatis-Plus concatenates directly into the ORDER BY clause. Successful exploitation primarily enables inferential (blind) reading of database contents, consistent with the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N profile and the vendor's CVSS 4.0 score of 5.3 with PR:L and uniformly Low impacts. Proof-of-concept exploitation is publicly available (E:P, matching VulDB's 'exploit publicly available' note), but there is no CISA KEV entry, so confirmed active exploitation in the wild has not been established; no EPSS score was supplied for this record.
Reflected cross-site scripting (CWE-79) in sfturing's hosp_order open-source hospital ordering project, affecting commits up to 627f426331da8086ce8fff2017d65b1ddef384f8, allows remote unauthenticated attackers to execute arbitrary script in a victim's browser by crafting a malicious 'Search' argument to Public Search Handlers in HospitalController.java. Exploitation requires the victim to open a crafted request or URL (user interaction), and publicly available exploit code exists via the project's GitHub issue #118. The project has not responded to the report, so no vendor patch is available; real-world risk is tempered by the project's near-zero deployment footprint.
Authentication bypass in the Keycloak (Red Hat Build of Keycloak) Kerberos federation provider lets an attacker on the same or adjacent network impersonate the Key Distribution Center and bypass Kerberos password authentication, potentially gaining unauthorized access to user accounts. The flaw only manifests in the specific, non-default configuration where Kerberos PASSWORD authentication is used while SPNEGO is disabled, because that mode never requests a server ticket to verify the KDC's identity. Rated CVSS 3.1 6.8 (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), exploitation requires network adjacency and an active on-path spoofing operation; no public exploit code has been identified and the CVE has not been listed as confirmed actively exploited (CISA KEV).
Stored cross-site scripting in XXL-JOB up to 3.5.0 allows an authenticated user with permission to manage job groups to inject script through the Name parameter of the /jobgroup/insert endpoint, which then executes in the browser of any admin who views the job-group listing. Publicly available exploit code exists (a GitHub proof-of-concept), but there is no evidence of active exploitation (not in CISA KEV), and no fixed version has been released because the vendor did not respond to coordination attempts. The practical risk is moderate: session or token theft, forced admin actions via the victim's browser, and defacement within the admin console, but no direct server-side code execution.
Authenticated users of lamp-cloud through 5.10.0 can read any other employee's role codes, permission codes, and full front-end router tree by supplying arbitrary employeeId values to the /anyone/visible/resource endpoint, which never verifies that the requested identifier belongs to the caller. Exploitation is trivial - any low-privilege account suffices, the identifiers appear to be enumerable integers, no user interaction or elevated privilege is required, and publicly available exploit code exists (a Python PoC targeting this exact BOLA condition). The flaw is confirmed as an object-level authorization failure (CWE-639) and is not known to be actively exploited (no CISA KEV listing); impact is limited to read-only disclosure of authorization metadata, which matches the assessed CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Authenticated tenant isolation bypass in jshERP through 3.6 allows any logged-in user to read other tenants' records from the GET /tenant/info endpoint by iterating tenant primary keys, exposing login names, validity dates, user quotas, and enabled state for every tenant on the platform. Exploitation requires only a valid account of any privilege level (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) and publicly available exploit code exists, though CISA KEV does not list this CVE as actively exploited. Impact is a bounded confidentiality leak - CVSS 5.0 with changed scope but no integrity or availability effect - and only materializes on instances that are genuinely multi-tenant with other tenants' records present; a single-tenant deployment exposes nothing beyond the caller's own data.
Authenticated low-privileged users of jshERP through 3.6 can overwrite role button-permission definitions for any role in their tenant by sending arbitrary roleId and btnStr values to the POST /userBusiness/updateBtnStr endpoint, because that handler performs no authorization check on the caller's privileges. Publicly available exploit code exists (a Python POC script is published on GitHub) and the CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L reflects moderate impact confined to the integrity and availability of permission configuration with no confidentiality exposure; the CVE is not listed in CISA KEV, so there is no confirmation of active exploitation.
Self-hosted draw.io deployments running the Docker or WAR build prior to 30.2.7 can have a victim's browser session silently bound to the attacker's own cloud-storage identity, because the OAuth callback handler skips verification of the state token against the session cookie whenever IS_GAE is false. An attacker who completes a legitimate authorization for their own account can then induce a victim to open a crafted callback URL, causing subsequent Google Drive, OneDrive, GitHub, GitLab, or Dropbox actions to be performed under the attacker's identity (CVSS 4.2, CVSS:3.1/AV:N/AC:H/PR:N/UI:R, CWE-352); the impact is session integrity loss and misattribution rather than disclosure of the victim's existing cloud files, and no public exploit identified at time of analysis. The hosted SaaS at app.diagrams.net and any Google App Engine build set IS_GAE=true and are unaffected.
Server-side request forgery in self-hosted draw.io deployments prior to 30.2.7 allows unauthenticated remote attackers to make the server fetch attacker-chosen URLs that resolve to private, link-local, or cloud-metadata addresses, returning internal HTTP responses or instance metadata through the image proxy. The flaw only exists when the server is started with ENABLE_DRAWIO_PROXY=1; the SaaS and desktop editions and default installs are unaffected. Successful exploitation depends on a DNS-rebinding timing race (the hostname must resolve to a public address during validation and to an internal address at connection time), which is why the assessed severity is 6.8 with AC:H rather than a high-severity rating; there is no public exploit code identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 30.2.7.
Path traversal in the self-hosted draw.io server (jgraph/drawio) before version 30.2.7 allows unauthenticated remote attackers to redirect the ExportProxyServlet's internal proxy request to unintended routes on the configured export backend by supplying dot segments (literal or percent-encoded) in the request path. Because the servlet copies all request headers and the request body to the traversed destination, an attacker can reach administration, debugging, health, or configuration endpoints that the export server happens to expose, and may trigger unintended internal actions, though the practical impact is bounded by how that backend is configured. Exploitation requires a deployment that has the export proxy feature enabled and pointed at an internal export service; there is no public exploit identified at time of analysis, and no EPSS score was supplied, so the vendor's modest CVSS of 3.7 is a reasonable reflection of real-world risk.
GoCD servers running versions 12.3.1 through 26.1.0 leak historical full server configuration through legacy /go/admin/restful/* routes to authenticated pipeline group administrators, who should only ever receive configuration for the pipeline groups they administer (CWE-863, incorrect authorization). Exposed data can include agent auto-registration keys, webhook invocation keys, encrypted material credentials and GoCD administrator lists, and a malicious group administrator could reuse a disclosed agent registration key to connect a rogue compatible agent, opening a higher-complexity path to receiving work or overwriting artifacts belonging to other groups. The endpoint is read-only and does not modify server configuration, normal authenticated users are explicitly not affected, and deployments that restrict pipeline editing to full administrators or to configuration repositories are not exposed; no public exploit identified at time of analysis. The issue is fixed in 26.1.0.
Authorization bypass in GoCD versions 18.7.0 through before 26.1.0 lets an authenticated user with a lower-privileged account read a pipeline template's configuration without the required view permission. The Get Template Config API selects its authorization filter through a case-sensitive comparison of the HTTP method name, so a request sent with nonstandard capitalization (for example 'Get' instead of 'GET') slips past the permission check; per the assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) exploitation requires only a valid low-privilege account and exposes read-only configuration data, with no modification of data and no exposure of encrypted secure variables. No public exploit identified at time of analysis; the vendor-released fix is GoCD 26.1.0, and deployments whose reverse proxy rejects or normalizes non-uppercase HTTP methods are not exposed.
Incorrect authorization in GoCD 13.1.0 through versions before 26.1.0 lets an authenticated internal user call the /go/api/support/process_list endpoint without the intended administrator privileges and read command-line arguments, usernames, remote material URLs, and internal material paths for materials they cannot otherwise access. Exploitation is gated by a timing race, since the endpoint only leaks this material metadata while source-control child processes are actively running, and disclosure is bounded because credentials, environment variables, and user-defined secrets remain masked or omitted. No public exploit code or confirmed active exploitation was identified, and the issue is fixed in GoCD 26.1.0.
GoCD servers running versions prior to 26.1.0 expose an authorization flaw in the internal UI /jobStatus.json endpoint that lets any authenticated user (CVSS PR:L) enumerate sequential, server-assigned job IDs and read job metadata - job names, state, progress timestamps, assigned agent IP addresses/UUIDs, and the associated stage and pipeline - for pipelines they are not permitted to view. The API fails to verify that the requested job ID actually belongs to the pipeline and stage named in the request (CWE-639), so the disclosure is bounded to metadata only: console output, artifacts, commands, variables, environment data, and configuration are not returned, and the CVSS 3.1 score is consequently 4.3 (low). The issue is fixed in GoCD 26.1.0; no public exploit code was identified and the flaw is not listed in CISA KEV, so there is no indication of active exploitation at time of analysis.
Stored cross-site scripting in XXL-JOB (xxl-job) 3.4.2 and 3.5.0 lets an authenticated operator inject script through the job 'name' or 'author' fields in the admin Task Management interface (JobInfoController); the payload is persisted and executes in the browser of any other user who later opens the affected job list or detail page. Publicly available exploit code exists, but exploitation requires an existing admin-console account with job create/edit rights plus interaction from a second user, so the practical risk is assessed as low despite the public disclosure. No confirmation of active exploitation (CISA KEV) is present in the available intelligence.
Information disclosure in ScadaBR up to and including version 1.1 allows an attacker to pull the complete project export - data sources, data points and graphical views - by invoking the unprotected EmportDwr.createExportJSON DWR method through /ScadaBR/export_project.htm. The vendor's CVSS 4.0 vector lists PR:N, but the fix adds Common.getUser() plus Permissions.ensureAdmin(), which indicates the endpoint executes inside an authenticated session, so realistic exploitation requires a valid low-privilege ScadaBR account rather than true anonymous access; impact is confined to read-only configuration disclosure with no integrity or availability effect. Publicly available exploit code exists and the issue is fixed in ScadaBR 1.2.0, though there is no confirmation of active exploitation.
Stored cross-site scripting (XSS) in Newbee Mall (newbee-ltd newbee-mall) up to version 1.0.0 allows an authenticated low-privileged user to inject arbitrary JavaScript via the goodsName parameter on the Goods Save endpoint (controller/common/UploadController.java), which can be persisted and executed when a victim views the poisoned content if user uploads are served through the /upload/** static mapping. Exploitation requires authentication (PR:L) and victim interaction (UI:P), and publicly available exploit code exists; the independent assessment rates this as low-to-moderate real-world risk given the required privileges, user interaction, and the niche demo-project deployment base.
Unauthenticated username enumeration in Dromara UJCMS through version 12.3.1 allows remote attackers to query the UserController username-existence endpoint and determine whether a given account name is registered on the target site, leaking account information without any credentials, user interaction, or special configuration. The independent assessment rates this as a low-impact confidentiality leak (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), whose practical value lies in feeding follow-on password-guessing or credential-stuffing campaigns against confirmed accounts rather than in direct compromise. No public exploit code has been identified at time of analysis and the vulnerability is not confirmed as actively exploited (no CISA KEV listing); the vendor was notified via a GitHub issue but has not responded, so no fixed release is available.
An authenticated low-privilege user of the Grimmory (BookLore) self-hosted library service can read book files belonging to other accounts by tampering with the bookId argument passed to the Kobo download endpoint handled by KoboController.streamFileToResponse, an IDOR-style authorization bypass (CWE-639) rated CVSS 5.3 with confidentiality-only impact. Publicly available exploit code exists, and although upstream issue #2431 is closed as completed, its only comment states the report 'has already been reported elsewhere' with no fixing commit or pull request identified there. No KEV listing or independent evidence of active exploitation was found, so real-world risk depends on whether the instance is network-reachable to an attacker who already holds valid credentials and whether the Kobo download feature is exposed.
An incorrect authorization check in Grimmory (grimmory-tools/grimmory, published as BookLore) up to versions 3.3.3 and 3.4.1 lets any authenticated low-privilege account read admin-scoped application settings through the Settings API endpoint GET /api/v1/settings, because AppSettingController.getAppSettings returned the full settings map without filtering entries by the caller's PermissionType (ADMIN / MANAGE_METADATA_CONFIG). The exposure is configuration data - integration flags, OIDC session/group-sync settings, Kobo/Komga/OPDS toggles and metadata-provider configuration - not credentials or write access; the case is assessed at low severity (CVSS 4.0 base 2.1; independent CVSS 3.1 assessment AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) and no KEV exploitation is recorded. Publicly available exploit code exists (referenced GitHub issue 2430) and the issue is rated low real-world risk despite the 'Authentication Bypass' tag, since the attacker must already hold a valid account and only gains read access to settings.
Error-based SQL injection in CordysCRM 1.7.0 through pre-1.7.4 lets an authenticated user holding the MODULE_SETTING_UPDATE permission inject database functions into the sort parameter of POST /account-pool/page, exposing database values through an error oracle when the query returns at least one row. No public exploit code is identified at time of analysis, and the independently assessed impact is confidentiality-only (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N). The vendor fixed the flaw in version 1.7.4.
HTTP request smuggling and header injection in Netty's HTTP/2 stack (as bundled in multiple Red Hat products) allow remote unauthenticated attackers to bypass security controls and manipulate requests when HTTP/2 traffic is translated to HTTP/1.1. Affected deployments include Red Hat AMQ Broker 7, Camel, Keycloak, Quarkus, Data Grid, Fuse, EAP, Apicurio Registry, and Debezium. Assessed as high severity (CVSS 3.1 base 7.5, AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:N); exploitation requires the specific topology of an HTTP/2-to-HTTP/1.1 translation boundary, and no public exploit was identified at time of analysis.
This is a real but moderate-priority vulnerability whose severity depends almost entirely on deployment topology rather than the raw 6.5 CVSS score. Netty's HTTP decoder lets split or duplicated Transfer-Encoding header fields slip past its final-chunked validation, so an unauthenticated, remote attacker who can send a raw crafted request to a Netty listener that sits in an HTTP chain with a second HTTP parser (reverse proxy, load balancer, CDN, WAF, or upstream/downstream server) can desynchronize the two parsers and smuggle a request (CWE-444). Impact is confined to low confidentiality and integrity loss (C:L/I:L) with no availability impact, no authentication (PR:N) or user interaction (UI:N) is required, and no public exploit identified at time of analysis.
Parameter substitution in the Elytron token-realm of Red Hat JBoss EAP 7, JBoss EAP 8 and the EAP Expansion Pack allows a remote attacker to manipulate OAuth2 token-introspection requests because parameters are assembled without URL encoding. Only deployments whose application security domain is backed by a token-realm configured with oauth2-introspection are exposed; other realm types (properties, JDBC, LDAP, or JWT validation without introspection) are unaffected, and the achievable impact is limited to Low confidentiality and Low integrity with no availability impact. Vendor scoring is 4.2 on an AC:H basis because success hinges on how the downstream introspection endpoint parses the injected parameters, and no public exploit has been identified at time of analysis.
JVM memory exhaustion in the wildfly-elytron-asn1 DERDecoder allows unauthenticated remote attackers to exhaust heap on any service that feeds untrusted DER/ASN.1 bytes into the library, notably SASL authentication flows and X.500 certificate principal parsing. The decoder reads an attacker-supplied length value and attempts a corresponding allocation without validating it against the actual remaining input, so a crafted payload can force an oversized allocation and destabilize or crash the JVM (availability impact only, CVSS 5.9, AV:N/AC:H/PR:N/UI:N/C:N/I:N/A:H, CWE-770). Exploitation is opportunistic rather than deterministic because the AC:H rating means success depends on payload size/repetition relative to the victim's configured heap, and no public exploit code has been identified at time of analysis; the issue is not listed in CISA KEV and no EPSS score was provided. Scope is limited to Red Hat products that bundle the affected elytron-asn1 library, including Red Hat Build of Keycloak, JBoss EAP 7/8 (and EAP XP), Red Hat Single Sign-On 7, Fuse 7, Quarkus, Data Grid 8, Camel, Debezium, and Cryostat.
HTTP request smuggling in Netty's HTTP/1.1 decoder (HttpObjectDecoder and the HttpRequestDecoder built on it) lets remote, unauthenticated attackers send a chunk-size line containing an embedded bare carriage return - for example `0\rX` - because strict chunk-line validation is skipped whenever the size line carries no `;` chunk extension, causing a request-boundary desync when Netty shares a connection with a second HTTP intermediary that frames the message differently. The flaw reaches every application and Red Hat product that embeds Netty, including AMQ Broker 7, AMQ Clients, Quarkus, Camel 4 for Quarkus 3, Camel for Spring Boot 4, Keycloak / Red Hat Single Sign-On, JBoss EAP 7 and 8, Fuse 7, Data Grid 8, Apicurio Registry 3 and Debezium 3, while independent assessment keeps it at CVSS 6.5 with AC:H because a standalone Netty service with no disagreeing proxy in the chain yields little practical smuggling impact. The public report includes a reproducible PoC test harness, but there is no CISA KEV listing and no evidence of active exploitation.
An authenticated, low-privilege ArcadeDB user can bypass per-type record ACLs and durably append graph edges to protected vertex types in versions before 26.9.1. The flaw is an incomplete fix of GHSA-c23x-pqcj-7hfm: the authenticated principal is bound only on the HTTP handler thread, while the async worker threads used by the parallel edge-connect phase of POST /api/v1/batch/{database} carry no current user, so LocalDatabase.checkPermissionsOnFile returns early and the CREATE_RECORD/UPDATE_RECORD checks on the target vertex type are never enforced. The attacker must already hold CREATE_RECORD on some edge type and submit an edge-load batch with parallelFlush left at its default of true; setting parallelFlush=false causes the request to be correctly rejected. Impact is confined to integrity of graph adjacency - no protected data is read and there is no denial of service - and no public exploit identified at time of analysis; a vendor patch is available in 26.9.1.
Certificate revocation checking in the OCSP client shipped with Red Hat Build of Apache Camel for Spring Boot 4 can be bypassed because the client does not verify the OCSP-signing Extended Key Usage (EKU) on the certificate that signs an OCSP response, allowing a revoked certificate that still chains to a trusted CA to be accepted as valid. The issue is remotely reachable without authentication or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9), although exploitation is conditional: the deployment must actually rely on this OCSP client for revocation checking and the attacker must already possess a revoked-but-chainable certificate. No public exploit identified at time of analysis, and this is assessed as a genuine but moderate-priority integrity flaw rather than a high-urgency issue.
A signed/unsigned type mismatch in Netty's Memcache binary protocol codec desynchronizes frame boundaries, allowing an unauthenticated, network-positioned attacker to smuggle responses across a shared or proxied memcache connection (CVSS 3.1 base 6.5, Medium). The flaw is reachable only when the Memcache binary codec is explicitly wired into a network-exposed Netty pipeline - a non-default configuration - and the affected code ships inside Red Hat Fuse 7, JBoss Enterprise Application Platform 7, Single Sign-On 7, and the Red Hat Build of Apache Camel for Spring Boot 4. No public exploit code has been identified at time of analysis, and there is no confirmation of active exploitation (not in CISA KEV); impact is limited to confidentiality and integrity (C:L/I:L) with no availability effect.
Certificate revocation validation performed by Netty's optional netty-handler-ssl-ocsp module can be silently skipped when the OCSP response omits the optional nextUpdate field, causing the application to proceed with a certificate that should have been rejected. The flaw is remote and requires no credentials or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9), but exploitation is conditional: the deployment must actually use the opt-in OCSP-stapling component, and the attacker must control or intercept the OCSP response seen by the client, typically through a man-in-the-middle position or by operating the TLS server whose certificate is being validated. There is no public exploit identified at time of analysis and no KEV listing, and the practical impact is confined to acceptance of a revoked or otherwise unvalidated certificate rather than code execution or data disclosure.
Heap memory corruption in snappy-java 1.1.10.8 and earlier allows remote attackers to write attacker-influenced bytes past the bounds of the output array when an application decompresses untrusted compressed data through the typed Snappy.uncompress*Array APIs (such as uncompressIntArray, uncompressFloatArray, or uncompressDoubleArray), which size their result array using the uncompressed length divided by element size while forwarding the undivided length to the native JNI layer. Per the assessed vector (CVSS 3.1 AV:N/AC:L/PR:N/UI:N, C:N/I:L/A:L) no authentication or user interaction is needed, but exploitation is conditional: the consuming application must expose the typed decompression path to attacker-controlled input, and applications that only use the generic byte[] uncompress path are not exposed. Impact is currently rated Low integrity and Low availability (heap corruption and crash) with no confirmed confidentiality loss or demonstrated code execution, and no public exploit was identified at time of analysis; this is a genuine memory-corruption flaw but a moderate, not top-tier, priority, and no vendor-released fixed version is identified in the available data.
Cross-site scripting in the FairEmail Android email app (versions prior to 1.2319) allows a crafted AMP email to execute arbitrary JavaScript inside the message-body WebView once the recipient manually enables the per-message AMP toggle, enabling the attacker to read the message DOM, exfiltrate message data, and draw phishing overlays within the message body. The vulnerable ActivityAMP renderer fails to strip inline script bodies, on* event-handler attributes, and javascript: URLs on non-allowlisted hosts, and the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N confirms unauthenticated remote delivery with required user interaction, scope change, and limited confidentiality/integrity impact but no availability impact. No public exploit code or active exploitation is identified at time of analysis, and practical risk is further lowered because AMP email is uncommon and AMP rendering is off by default.
Unauthenticated information disclosure in NCEAS Metacat versions prior to 3.4.2 allows remote attackers to retrieve internal Apache Solr configuration files such as solrconfig.xml through the client-controlled 'qt' parameter. Because Metacat forwards requests from search endpoints like /d1/mn/v2/query/solr/ to its privileged Solr backend via SolrJ, an attacker can force the /admin/file handler to run even against Solr 7.0+ installations configured with handleSelect=false, and the returned file contents are reflected in an XML error response. No authentication or user interaction is required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N, 5.8), but the impact is limited to configuration and infrastructure profiling rather than code execution or credential theft; no public exploit code or active exploitation has been identified at time of analysis.
Missing space-membership authorization checks in Scoold prior to 1.69.0 let any authenticated user write replies and comments into question threads belonging to private spaces they are not members of, resulting in unauthorized modification of private discussions. The flaw only manifests in the non-default configuration where scoold.is_default_space_public is set to false and private spaces are actually in use, and it requires a valid session plus knowledge (or enumeration) of a target question identifier; the attacker gains write access only, not read access, to the affected thread. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, 6.5), exploitation is authenticated and integrity-only, and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis; the vendor-released fix is version 1.69.0.
Scoold deployments prior to 1.69.0 expose replies to questions in private spaces through the answers API: a holder of a valid personal API token can call GET /api/posts/{id}/answers and receive the reply bodies of a private-space question whose own endpoint correctly denies access. The flaw affects instances configured with both scoold.api_enabled and scoold.api_user_access_enabled set to true, and exploitation additionally requires the attacker to know or enumerate the target question's identifier, so it is a confidentiality-only (C:H, no I/A) disclosure of existing private discussion content rated 6.5. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV); the vendor has released a fix in 1.69.0.
Mutual-authentication bypass in AsyncHttpClient (AHC) 3.0.8 through 3.0.11 allows a man-in-the-middle who cannot prove knowledge of the shared secret to be accepted as a legitimate server when SCRAM-SHA-256 or Digest mutual authentication is used over a non-TLS or already-compromised transport. The affected interceptor methods computed the SCRAM ServerSignature or Digest rspauth verification value but only logged a mismatch and still delivered the response to the application as authenticated, so the client silently loses its only signal that the peer is an impostor. Over TLS the flaw is inert because a genuine server always returns a valid verification value; exploitation requires a MITM position (AC:H), the impact is limited to authentication-assurance loss (C:N/I:L/A:N), and no public exploit code or active exploitation has been identified at time of analysis. Fixed in version 3.0.12.
Cleartext exposure of origin credentials in AsyncHttpClient (AHC) 2.0.0-2.16.0 and 3.0.0-3.0.11 occurs when a Java application reaches an HTTPS origin through an HTTP CONNECT proxy while using preemptive origin authentication: the library attaches the origin's Authorization header - Basic or Digest credentials, plus per-connection NTLM/Kerberos/SPNEGO tokens - to the plaintext CONNECT request before any TLS tunnel exists, so the proxy and any observer on the client-to-proxy hop can read credentials meant only for the origin. The vulnerability is rated CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) with high confidentiality impact but a high attack-complexity qualifier, because exploitation requires the specific non-default combination of a CONNECT proxy, preemptive origin authentication, and an adversary positioned on that network segment; authentication requirements are not confirmed from the supplied vector beyond PR:N, and there is no public exploit identified at time of analysis. Vendor-released patches are 2.16.1 and 3.0.12, and because 3.0.12 is itself affected by a separate Digest-to-Basic downgrade flaw (GHSA-rqf5-2wxv-rjf4), 3.0.13 is the recommended target on the 3.x line.
Connection-permit leakage in the AsyncHttpClient (AHC) Java library versions 3.0.8 through 3.0.11 can permanently exhaust a configured connection pool and deny service to subsequent HTTP requests. Applications are exposed only if they set maxConnections or maxConnectionsPerHost above zero; each TLS connection attempt that aborts before the handshake completes strands one permit, because NettyConnectListener removes the partitionKeyLock permit from NettyResponseFuture before every failure path is bound to the channel's closeFuture. Repeated pre-handshake TLS failures can lock out a single host under a per-host limit or drain the shared pool under a global limit even when no connection remains open; the default unlimited setting is not affected, no public exploit code was identified at time of analysis, and the issue is fixed in 3.0.12.
Credential disclosure in AsyncHttpClient (Java) allows a client configured with a client-wide Realm via config.setRealm(...) and with redirect following enabled to leak Basic, Digest, Negotiate, or NTLM credentials to an attacker-controlled origin. When a cross-origin or scheme-downgrade redirect clears the per-exchange realm, the authentication interceptor in Interceptors.java falls back to config.getRealm() and re-attaches the client-wide credentials; if the attacker's target then answers HTTP 401, the client sends those credentials or tokens to that foreign origin. Affected releases are 2.14.5 through 2.16.0 and 3.0.9 through 3.0.11, fixed in 2.16.1 and 3.0.12; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the flaw is conditional on the specific client-wide Realm configuration, redirect following, attacker-influenced redirect, and a 401 response (AC:H per the assessed vector).
MariaDB Connector/J versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9 can be tricked into transmitting a locally selected file to a rogue or man-in-the-middle database server even when the allowLocalInfile option is explicitly set to false, because the connector processes a server-initiated LOCAL INFILE packet (0xfb) without honoring that setting. The exposure is narrow: the attacker can only receive the exact file the application already chose to load via a LOAD DATA LOCAL INFILE COM_QUERY, cannot redirect the request to an arbitrary path, and gains nothing unless the application organically loads sensitive data over an untrusted connection - so this is a low-severity (CVSS 3.7), highly conditional information-disclosure issue rather than a widespread threat. The vulnerability is unauthenticated at the network layer per the vector (PR:N) but requires high attack complexity (AC:H) and control of the server or the connection path; no public exploit code has been identified at time of analysis, and the flaw is fixed in the four versions listed above.
Path traversal in SmallRye JWT's AwsAlbKeyResolver lets an unauthenticated remote attacker force the application server to issue GET requests to arbitrary paths on the same origin as the configured AWS ALB key endpoint, because the attacker-controlled 'kid' header is concatenated into the key-fetch URL without sanitizing path traversal characters or query-string separators. Only applications that explicitly enable the non-default AWS_ALB key provider (used to verify JWTs signed by AWS Application Load Balancers) are affected; installations using other key resolvers are unaffected. The impact is confidentiality-only and limited to non-public endpoints or internal data reachable on that same origin, since the rogue request fires before JWT signature verification. No public exploit code or active exploitation was identified at time of analysis, and no EPSS score was supplied; Red Hat (secalert@redhat.com) tracks the issue as a moderate-severity path traversal.
Password cracking in admin3 3.0.0 and earlier allows anyone who obtains the application's credential database to recover user plaintext passwords offline, because stored credentials use single-round MD5 salted only with the username and no key-derivation function. The flaw does not grant database access by itself - it requires a prior compromise (database breach, SQL injection, exposed backup, or insider/privileged access, reflected by the CVSS PR:H prerequisite), but once that precondition is met, cracking is trivial on commodity hardware; publicly available exploit code exists. With a vendor score of 4.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N) and no confirmed active exploitation, this is a genuine but conditional, low-to-moderate risk that amplifies the impact of an upstream data exposure rather than creating one.
Disabling or locking a user account in admin3 through 3.0.0 does not invalidate that user's existing bearer tokens, so a previously authenticated user retains full access with their original permissions after the account is disabled. The root cause is twofold: the AuthInterceptor never re-checks the user's locked status on subsequent requests, and LocalSessionManager resets session expiry on every request, so a pre-existing token never lapses through inactivity. Publicly available exploit code exists (a proof-of-concept account-lockout-bypass script), and exploitation requires that the attacker already held a valid token issued while their account was enabled (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, CVSS 5.4) - a rogue-insider or post-disable persistence scenario rather than unauthenticated compromise. Confirmed actively exploited (CISA KEV) status is not indicated by the available data, and there is no privilege escalation beyond the disabled account's original permission set.
Path traversal in junrar (the open source Java RAR archive library) prior to version 7.6.1 lets an attacker-supplied RAR archive cause LocalFolderExtractor to create directories outside the intended extraction root. The flaw exists because createFile() validates only the final canonical file path while makeFile() creates intermediate path segments with unchecked mkdir() calls, so a crafted entry whose final path resolves inside the destination can still spawn directories elsewhere - a specificity that is why the assessed vector carries AC:H. Impact is confined to directory creation and file-versus-directory squatting that can make later security-sensitive writes fail; there is no arbitrary file-content write and no confidentiality loss, unauthenticated remote attackers are the relevant threat model only when a host application extracts untrusted archives through this specific extractor, and no public exploit code has been identified at time of analysis. This is a genuinely low-priority issue, and the vendor's CVSS of 3.7 reflects that honestly rather than inflating it.
Missing authorization in the ChangeWeDer CRM UserController index endpoint allows a remote attacker with a low-privilege authenticated account to reach functionality or data that should require stronger privileges, with limited confidentiality, integrity, and availability impact. The product has no versioning scheme and the project has not responded to the issue report, so no patched release is confirmed; exploitation requires network access to the Java CRM application and a valid low-privilege session. No public exploit identified at time of analysis.
Authenticated blind SQL injection in ScadaLTS 2.8.1-release-candidate build 0 lets any logged-in user with the lowest privilege tier (ROLE_USER, ROLE_ADMIN, or ROLE_PUBLIC) extract arbitrary database contents, including password hashes for every account on the platform. The flaw lives in the JSON sortBy array accepted by POST /api/events/search, whose values are concatenated straight into the SQL ORDER BY clause with no sanitization or parameterization, forcing attackers to use slower time-based and boolean-based inference rather than in-band extraction. CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) is well calibrated: exploitation requires valid credentials but scada-lts deployments that grant ROLE_PUBLIC or self-service low-privilege accounts effectively erase that barrier, and there is no public exploit code and no confirmed active exploitation (CISA KEV) at time of analysis.
Server-side request forgery in Hippo4j through 1.5.0 allows an authenticated user of the Hippo4j server console to force the application to issue outbound HTTP GET requests to arbitrary hostnames and ports, because four ThreadPoolController endpoints accept a clientAddress parameter without validation. Affected deployments are those running the Hippo4j console with reachable internal services or cloud metadata endpoints (for example 169.254.169.254); the CVSS v3.1 score is 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting a confidentiality-only impact gated behind a valid console session (PR:L) with no user interaction. No public exploit code or confirmed active exploitation was identified at time of analysis, and the practical impact against cloud environments depends on whether the instance exposes a metadata service and on whether the affected endpoints return the fetched response body, which is not confirmed by the available source data.
Credential isolation bypass in Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier allows an authenticated user who holds Item/Configure permission on a folder to reach 'alternative GitLab API token credentials' that are scoped to a different folder and that they are not entitled to use, because the plugin caches the GitLab API client under a cache key derived solely from the credentials ID and never incorporates the folder in which the credentials were resolved. Rated CVSS 3.1 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) under CWE-522 (insufficiently protected credentials), the issue is a moderate authorization/credential-isolation flaw rather than an unauthenticated remote compromise, and it only exists on multi-tenant Jenkins controllers that actually rely on folder-scoped credentials - single-tenant installations and controllers where all credentials are global/system-scoped see no practical impact. There is no public exploit identified at time of analysis, CISA SSVC records Exploitation: none and Automatable: no, and the CVE is not KEV-listed, so it warrants scheduled patching rather than emergency response.
Information disclosure in Jenkins Gradle Plugin 2.19.1252.v15196b_5a_6e10 and earlier lets an authenticated Jenkins user who can influence the build log of a Gradle job trick the plugin into fetching build scan data from an attacker-controlled URL in preference to the Develocity server URL set in the plugin's global configuration. Because the plugin attaches the globally configured Develocity access key to that outbound request, the attacker can capture the credential; instances with no Develocity access key configured have nothing to leak, so exposure is conditional rather than universal. No public exploit code has been identified at time of analysis, and this is a genuine but moderate-severity issue: exploitation requires authenticated job-run or job-configure privileges plus a configured access key, and the resulting impact is limited to confidentiality (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).
Path traversal in the Jenkins Pipeline: Groovy Libraries Plugin (805.va_fc79344957d and earlier) lets an authenticated user who can configure Pipelines point the `library` step at a path outside the SCM checkout and follow symbolic links, giving read access to files in a resources directory and the ability to delete files in a test directory on the Jenkins controller file system. Exploitation requires the Pipeline-configuration privilege, a symlink placed inside the checkout, and successful traversal during library retrieval, which is reflected in the high attack complexity of the assessed CVSS:3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, base score 4.2). No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), so the practical risk is low-to-moderate and confined to file read and limited file deletion rather than arbitrary write or code execution.
Credential disclosure in Jenkins Pipeline: Multibranch Plugin 841.vec5b_9e1806ec and earlier allows users who already hold Item/Configure permission to capture credentials they are not entitled to by authoring or modifying a Pipeline that invokes the resolveScm step, which fails to establish the correct context for credentials lookup. The issue is an access-control scoping flaw (CWE-863) rated CVSS 3.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting the authenticated Item/Configure prerequisite, the high complexity of targeting specific credential IDs, and impact limited to confidentiality with no integrity or availability effect. It requires a Jenkins instance that actually uses Pipeline/multibranch jobs with resolveScm; at time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified, though the vendor advisory of 2026-09-16 should be reviewed for the fixed release.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to read CRM approval-workflow data through GET /admin-api/crm/flow/flow-users, disclosing approval chain topology, step ordering, approver identifiers, and personal information such as login names, nicknames, departments, email addresses, mobile numbers, and last-login IP addresses. The endpoint does enforce authentication but omits any role or permission check, so a single low-privilege admin-panel account is sufficient - no elevated privileges, user interaction, or special configuration are required. Publicly available exploit code exists for this issue, although the CVE is not listed in CISA KEV; the practical barrier to exploitation is the requirement to hold or obtain a valid back-office session.
Missing authorization in the StoreProductController onSale handler of Yshop CRM through 2.1.3 allows any authenticated back-office user (regardless of assigned role) to toggle product sale status by calling GET /admin-api/product/store-product/sale with sequential product IDs, letting them withdraw entire catalogs from sale or re-enable withdrawn products. The flaw is an integrity-only issue (CVSS 3.1 base 5.3, PR:L) - it is not reachable anonymously and causes no data disclosure or service outage. Publicly available exploit code exists (a Python PoC published alongside the request), but there is no confirmed active exploitation (not in CISA KEV); this is a genuinely low-to-moderate risk issue despite the CRITICAL-sounding CWE-862 label.
Authenticated back-office users can abuse yshop-crm through 2.1.3 to send SMS and email to arbitrary customers via POST /admin-api/crm/customer/send-sms and /send-mail, because CrmCustomerController does not enforce authorization on those actions. Publicly available exploit code exists, but exploitation requires a valid back-office account (PR:L), is remote with no user interaction, and yields only limited integrity impact; no confidentiality or availability impact is assessed. The practical risk is therefore concentrated on malicious insiders or attackers who have already obtained CRM credentials, not pre-auth compromise of default installations.
Reflected cross-site scripting in kkFileView 5.0.0 through 5.0.2 lets unauthenticated remote attackers inject JavaScript into the /onlinePreview endpoint, where the user-controlled `page` and `kkagent` query parameters are passed by OnlinePreviewController into FreeMarker templates and emitted unescaped inside raw JavaScript contexts. Because the CVSS vector is PR:N with UI:R, the attacker needs no credentials but must convince a victim to open a crafted link; successful exploitation runs script in the victim's browser origin, allowing session or token theft and actions performed as the victim, with no server-side code execution or backend data compromise. There is no confirmation of active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and EPSS is low at 0.17% (6th percentile), though the reflected, non-persistent nature of the flaw means each victim must be individually lured.
Use-after-free in zstd-jni's Dictionary Sharing component allows remote attackers to corrupt native heap memory through the ZstdCompressCtx.loadDict() and ZstdDecompressCtx.loadDict() APIs in versions up to 1.5.7-13. The defect is a logic inversion in shared-lock accounting: the code releases the reference count on the incoming dictionary parameter rather than on the previously held dictionary reference, causing the old native buffer to remain referenced after it can be freed by another thread. A public proof-of-concept exists via GitHub issue #404, and vendor released a confirmed fix in version 1.5.7-14.
Missing function-level and data-scope authorization in SmartAdmin API (Java17/SpringBoot3) 3.30.0 lets any authenticated low-privileged employee retrieve employee directory records belonging to other departments and users through a single request to the /employee/queryAll endpoint. The impact is confined to information disclosure (CVSS 4.3, confidentiality:Low, no integrity or availability effect), and exploitation requires a valid low-privileged employee session - the flaw does not allow unauthenticated access. No public exploit has been identified at time of analysis, and the EPSS score of 0.19% (9th percentile) is consistent with the low assessed severity.
Arbitrary file write in Keyfactor SignServer before 7.6.0 requires an authenticated administrator to configure a SignerStatusReportWorker output path, allowing the process to create or overwrite files as the local JBoss user. Because the path is not validated against a safe directory and can reference an existing file, a malicious or compromised admin could overwrite files accessible to the JBoss service account; the assessed impact is integrity-only with no confidentiality or availability impact, and no public exploit identified at time of analysis (EPSS 0.15%). Affected deployments are those running SignServer versions before 7.6.0.
Stored cross-site scripting in itranswarp's Markdown rendering pipeline allows authenticated users to inject arbitrary JavaScript into page content that executes in other visitors' browsers. The flaw exists in the `Markdown.toHtml()` method of `Markdown.java`, which fails to sanitize malicious HTML or script constructs embedded in Markdown input before writing rendered output to the page. All 2.x releases through 2.19 are affected, the project is officially end-of-life with no maintainer response to the vulnerability report, and exploit code has been publicly published.
Missing authorization in the A2A Java SDK (a2aproject/a2a-java) 1.2.0 allows a caller with a valid account to invoke the ListTasks operation without the list-scoped read check that guards other task operations, so task listings are returned to principals that the configured TaskAuthorizationProvider may have intended to reject entirely. The flaw lives in AuthorizationRequestHandlerDecorator.onListTasks in server-common, which delegated to the handler without first consulting the authorization provider for the list scope, leaving protection to per-task filtering inside the TaskStore. It is fixed in release 1.3.0 (tag v1.3.0.Final, commit e9a1abf9c90c02b16d17293afdc3cc2f555d63a6); CVSS 4.0 base is 5.3, there is no CISA KEV listing and no public exploit code identified at time of analysis.
HTTP response splitting in a2a-java 1.2.0 allows attackers who control push notification authentication credentials to inject arbitrary HTTP headers by embedding CR/LF characters in the Authorization header assembled by `BasePushNotificationSender.dispatchNotification()`. The root cause is direct concatenation of client-supplied `scheme` and `credentials` fields into an outbound HTTP header without CRLF sanitization. No public exploit has been identified at time of analysis; vendor-confirmed patch is available as v1.3.0.Final.
Server-side request forgery in tarzan-cms 1.0.0 allows remote attackers to force the application server to initiate arbitrary outbound HTTP connections by manipulating the `httpUrl` argument passed to the `openConnection()` method in `ThemeService.java`. The Theme Download Function passes user-supplied URL input directly to a connection handler without adequate validation, enabling internal network reconnaissance, cloud metadata endpoint access, or pivoting to backend services. A proof-of-concept has been publicly disclosed via a Gitee issue report; no vendor patch exists and the project maintainer has not responded to the disclosure.
Missing authorization in wxiaoqi Spring-Cloud-Platform's OnlineController allows authenticated low-privileged users to invoke getOnlineInfo without proper access checks, exposing session and online-user data beyond their intended permission scope. Affected versions are 1.0, 2.2, and 3.0 of the ace-admin module. A public proof-of-concept exploit (poc_vuln2_session_exposure.zip) has been released, though no vendor patch exists and the project has not responded to the coordinated disclosure via GitHub issue #65.
Missing authorization in wxiaoqi Spring-Cloud-Platform 3.0.1 and 3.1.0 enables remote authenticated attackers to bypass permission enforcement via the `checkUserPermission` function in the Permission Service RPC component. A proof-of-concept exploit (`poc_vuln1_failopen_authz.zip`) is publicly available on GitHub, lowering the barrier to exploitation. The vendor has not responded to the issue report filed at the project repository, leaving affected deployments without an official patch.
Unconstrained memory allocation in TooTallNate Java-WebSocket 1.6.0-1.6.1 allows remote unauthenticated attackers to exhaust server heap memory by sending WebSocket frames with arbitrarily large declared payload lengths. The Draft_6455 fragmentation handler initialized maxFrameSize to Integer.MAX_VALUE (~2 GiB), so the library attempts to allocate the full declared frame size before any payload data is actually received. A publicly available proof-of-concept exists via GitHub issue #1508; the upstream fix is in PR #1509 but has not yet shipped in a tagged release.