Vulnerabilities

The C-MOR Video Surveillance web interface (up to version 6.0104) is vulnerable to Path Traversal via the 'cam' parameter in show-movies.pml.

Cross Site Scripting vulnerability in za-internet GmbH C-MOR Video Surveillance <= V6.0104 allows a remote attacker to execute arbitrary code via the size parameter in ptzpreset.pml component and the showmovies.pml component

Netmaker makes networks with WireGuard. Prior to version 1.5.0, the `sqliteDeleteRecord` function in Netmaker's database layer constructs SQL `DELETE` statements using direct string concatenation of user-supplied input. This allows an authenticated attacker to perform boolean-based SQL injection. Version 1.5.0 fixes the issue.

Concrete CMS 9 before 9.5.3 authorized the dashboard sitemap reorder action (Concrete\Controller\Backend\Dashboard\SitemapUpdate) using only the global access_sitemap task permission and did not check per-page edit permission before updating each page's display order. As a result, an authenticated user granted sitemap access could change the display order (cDisplayOrder) of any pages they had no rights to edit, altering the order in which those pages render in navigation, breadcrumb, and page-list output. The reorder action additionally validated no CSRF token, so the write could be triggered by a forged request. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting.

Concrete CMS 9.0.0 to 9.5.2 is vulnerable to Server-Side Request Forgery iremote file import via cross-port reuse of a host's validated DNS pin. When multiple remote URLs share the same host, only the first `ValidatedRemoteUrl` is retained and reused for every later URL with that host. A low-privileged authenticated user permitted to import files could therefore supply a DNS-rebinding host that resolved to a public address during validation and to a private or loopback address during the unpinned download, causing the server to fetch internal-only resources such as loopback services, internal admin panels, or cloud metadata endpoints and to save the responses into the file manager. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N. Thanks Ahmad Wicaksono (sonix03) for reporting.

Concrete CMS 9.0.0 through 9.5.2 is vulnerable to Insecure direct object reference (IDOR) in the Express saved search preset delete and edit dialogs . An authenticated user holding only view permission on a single Express entity could therefore permanently delete, with no undo, or rename saved search presets owned by Express entities for which they had no permission, and a renamed preset name was displayed back to users of the targeted entity, enabling defacement or social engineering. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N. Thanks Yalguun Tumenkhuu ( fg0x0 ) for reporting.

Concrete CMS before 9.5.3 did not enforce a destination-side authorization check and did not validate a CSRF token in the multilingual page assignment backend action (Backend\Page\Multilingual::assign). As a result, an authenticated user who held the Edit Page Multilingual Settings permission on a single page could bind an arbitrary page in another locale as that source page's translation, and could delete legitimate translation pairs maintained by other editors, altering public-facing language routing across the site. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting.

Improper certificate validation on LDAPS connections to Active Directory in Devolutions Server 2026.2.16 and earlier allows a network-positioned attacker to intercept privileged directory service credentials via a spoofed domain controller certificate.

http4s Ember's HTTP/2 implementation buffers a frame's entire declared payload — up to 16 MiB, bounded only by the protocol's 24-bit length field — into contiguous memory before checking it against the advertised SETTINGS_MAX_FRAME_SIZE (16 KiB), because the validation in processFrame cannot run until the frame is fully assembled. An unauthenticated attacker triggers it simply by opening an HTTP/2 connection and declaring an oversized frame; no request, stream association, or credentials are required, and dribbling the payload without finishing evades rejection entirely since incomplete frames never reach validation. The result is uncontrolled resource consumption and remote denial of service by memory exhaustion — roughly 16 GiB of heap within reach at the default 1024 maxConnections — and the client side is symmetric because ember-client's readLoop shares the same code path. Only deployments explicitly built with .withHttp2 on ember-server or ember-client are affected; HTTP/2 is off by default on both builders. No public PoC exists, the CVE is not in CISA's KEV, and no exploitation in the wild is known.

Do: Upgrade to a patched http4s release as soon as one is published (track http4s security advisories for CVE-2026-88975), since the flaw sits in ember-core's H2Frame/H2Connection read loop and cannot be fixed in application code. Until then, disable HTTP/2 on Ember (it is off by default) or terminate HTTP/2 at a reverse proxy that enforces frame-size limits and speak HTTP/1.1 to the backend. Note that lowering SETTINGS_MAX_FRAME_SIZE or setting withIdleTimeout provides no mitigation — the check runs only after buffering and dribbled frames make steady read progress — so also monitor heap usage on any HTTP/2 listeners you cannot yet disable.

rust-libp2p's QUIC transport (libp2p-quic) contains a remote panic in its post-handshake upgrade path: after Quinn completes the TLS 1.3 handshake, the code re-parses the peer certificate with an expect() that assumes validation cannot fail, but the parse re-runs wall-clock validity checks. A malicious peer can present a valid but very short-lived libp2p TLS certificate, let the handshake-time validation succeed, and then withhold the final handshake fragment until just after the certificate expires but before the handshake timeout, causing the post-handshake re-parse to panic and crash the process. The attacker gains a remote, unauthenticated denial of service against any application exposing a libp2p QUIC listener, with no malformed packets required. Affected software is any Rust application using the libp2p-quic transport from rust-libp2p where a QUIC listener is reachable; exact affected version ranges were not specified in the advisory. There is no known public PoC and no indication of in-the-wild exploitation, though the flaw is trivially reachable by any network peer once the technique is known.

Do: Upgrade rust-libp2p to the patched release containing the fix for the post-handshake certificate re-parse as soon as it is available (check the libp2p/rust-libp2p security advisories for the fixed version, as none was listed in this report). Until patched, restrict inbound QUIC (UDP) listener exposure via firewalling to known peer ranges where feasible, and run affected services under a supervisor that restarts on panic to limit downtime from crash-triggering connections. Monitor logs for panics originating in transports/quic connection upgrade code, which would indicate attempted exploitation.

http4s Ember, the native Scala HTTP server and client, fails to limit how much data can accumulate from HTTP/2 CONTINUATION frames that follow a HEADERS or PUSH_PROMISE frame without the END_HEADERS flag, allowing unbounded heap growth until the connection closes. A remote, unauthenticated attacker can send an endless stream of CONTINUATION frames against any reachable path on an Ember server configured with .withHttp2 (even paths returning 404), exhausting memory and crashing or degrading the service; a malicious origin server can likewise exhaust an Ember client's memory via an oversized response header block. The attack completes before the request is decoded, so no authentication or valid path is required, and consumption is limited only by the attacker's bandwidth and connection lifetime. Only deployments that explicitly enabled HTTP/2 via .withHttp2 are affected, since HTTP/2 is off by default; the fix bounds the accumulated header block at SETTINGS_MAX_HEADER_LIST_SIZE and terminates offending connections with GOAWAY. No public proof of concept or in-the-wild exploitation is known, and the flaw is not in the CISA KEV catalog.

Do: Upgrade to a patched http4s Ember release that enforces SETTINGS_MAX_HEADER_LIST_SIZE (derived from maxHeaderSize / maxResponseHeaderSize) and terminates oversize header blocks with GOAWAY; if an immediate upgrade is not possible, remove .withHttp2 (reverting to the HTTP/1.1 default) or place Ember behind a reverse proxy that terminates HTTP/2 itself and speaks HTTP/1.1 to Ember. Also verify that receiveHeadersTimeout is configured to bound how long an incomplete header block may remain open, and monitor Ember processes for unexpected heap growth.

Http4s: CookieJar middleware matches by substring, leaking cookies cross-origin The `CookieJar` client middleware decides whether to attach a cookie to an outgoing request using an unanchored substring test on the host and path, instead of the domain match specified by RFC6265 5.1.3. A cookie stored for `example.com` is therefore sent to any host whose name merely contains `example.com` (e.g. `evilexample.com`), leaking potentially sensitive cookies to an attacker-chosen host. ## Impact Disclosure of session and authentication cookies to an attacker-controlled host, enabling session hijack of the application's outbound calls. ## Preconditions - Application uses the `CookieJar` client middleware. - Application can be induced to make an outbound request to a host controlled by the attacker, where the hostname contains the targeted domain as a substring. ## Workarounds - Do not use the `CookieJar` with clients that fetch attacker-influenced URLs - Apply a separate `CookieJar` per trusted origin.

Http4s: DigestAuth allows replay of captured requests The `DigestAuth` replay defence stores `lastNc + 1` rather than the nonce-count (`nc`) value it just accepted. When a legitimate client sends non-contiguous `nc` values (parallel or retried requests, as browsers do), the server's counter lags behind the highest `nc` seen, and a captured `Authorization` header can be replayed multiple times. ## Impact A passive observer can turn one captured Digest-authenticated request into several replayed authenticated (state-changing) requests, defeating the core replay protection Digest provides over Basic. ## Preconditions - Application uses `DigestAuth`. - Attacker can passively observe at least one legitimate digest request. - Legitimate client emits an `nc` more than one greater than the last, for instance from a parallel or retried request. ## Workarounds - Deploy over TLS so requests cannot be captured.

The Ember HTTP/1.x header parser in the Scala toolkit http4s tests the Transfer-Encoding header value with a case-sensitive substring match for 'chunked', violating RFC 9112 §7's requirement for case-insensitive comparison. An unauthenticated remote attacker who sends 'Transfer-Encoding: Chunked' (or values like 'notchunked' or a Kelvin-sign variant) causes Ember and an RFC-compliant front-end proxy to disagree on where the request body ends, enabling classic TE.CL / TE.0 request smuggling. Successful exploitation lets the attacker bypass front-end ACLs and authentication, hijack the next victim's request on a pooled keep-alive connection to capture its Cookie/Authorization headers, or poison cache entries; ember-client shares the same parser and enables response smuggling when http4s acts as a gateway to a malicious upstream. Any deployment running ember-server as an origin behind a proxy that treats Transfer-Encoding case-insensitively and forwards it verbatim is affected. No public proof of concept is known and there is no evidence of in-the-wild exploitation, though the issue carries a high CVSS 3.1 score of 8.7.

Do: Upgrade http4s ember-server and ember-client to the first release that performs a case-insensitive, charset-pinned (ISO-8859-1) Transfer-Encoding token comparison, checking the http4s security advisories for the exact fixed versions once published. Where an immediate upgrade is not possible, mitigate at the intermediary: enable full request buffering and re-encoding (e.g. nginx's default proxy_request_buffering on), normalize or lowercase the Transfer-Encoding token before forwarding, or disable keep-alive between the proxy and the Ember backend. Audit gateway-style deployments using ember-client for signs of response-splitting from untrusted upstreams.

http4s Ember, when HTTP/2 is explicitly enabled via .withHttp2, fails to enforce the SETTINGS_MAX_CONCURRENT_STREAMS limit, allowing a single unauthenticated connection to open an unbounded number of concurrent streams whose per-stream state is never released. An attacker can exploit this to exhaust the JVM heap and crash or degrade any Ember server speaking HTTP/2, making it a resource-exhaustion flaw in the same family as the 2023 HTTP/2 Rapid Reset attacks (CVE-2023-44487). The same unchecked allocation is reachable in ember-client through server-initiated PUSH_PROMISE frames, so a malicious or compromised origin can exhaust clients that make HTTP/2 requests to it. Affected parties are Scala/JVM services built on http4s Ember with HTTP/2 enabled, and ember clients connecting over HTTP/2 to untrusted servers. No public proof of concept is known and the flaw is not in the CISA KEV catalog, so exploitation in the wild is not indicated.

Do: Upgrade Ember server and client to the next patched http4s release as soon as Typelevel publishes one, since no fixed version is identified in the advisory. Until then, disable HTTP/2 on EmberServerBuilder and EmberClientBuilder (this is the default configuration), and for clients avoid HTTP/2 to untrusted origins. If HTTP/2 must be kept, place Ember behind a load balancer or proxy that strictly enforces SETTINGS_MAX_CONCURRENT_STREAMS and monitor JVM heap and connection/stream counts for anomalous growth.

The Ember HTTP/2 implementation in http4s replenishes the inbound flow-control window based on bytes received from the wire rather than bytes actually consumed by the application, and buffers received DATA frames in an unbounded per-stream channel. As a result, HTTP/2 flow control provides no backpressure: an unauthenticated attacker can stream a large or endless request body to an Ember server built with .withHttp2 faster than the route drains it, or feed a large response body to an Ember client, forcing the connection to retain the entire payload in heap. The impact is remote denial of service through out-of-memory exhaustion of the JVM, with no confidentiality or integrity impact (CVSS 3.1: 7.5). This is the read-path mirror of the previously disclosed outbound queue issue (GHSA-8f3q-3jmv-7prw). No public proof of concept is known and there is no evidence of in-the-wild exploitation.

Do: Disable HTTP/2 in Ember until a patched http4s release can be applied, which removes the vector entirely. Where HTTP/2 must stay enabled, wrap body-consuming routes in EntityLimiter (or an equivalent aggregate request-entity size limit) and ensure handlers fully drain request bodies with aggressive idle timeouts. Monitor JVM heap usage and long-lived HTTP/2 streams with large inbound bodies as indicators of attempted exploitation.

CVE-2026-92180 is a local privilege escalation vulnerability (CWE-427, uncontrolled search path element) in the activation-service Update Service component of pdfforge PDF Architect on Windows. The activation-service process loads a library from an unsecured, attacker-writable location, so a low-privileged local attacker can plant a malicious DLL that the service loads and executes in the context of SYSTEM. Exploitation requires the attacker to already have the ability to run code on the target machine, such as a standard user account or malware running with limited rights. Anyone running an affected PDF Architect installation on Windows is exposed, since the flaw grants full SYSTEM-level compromise once local code execution is obtained. No public proof of concept is known and the issue is not listed in CISA's Known Exploited Vulnerabilities catalog, so exploitation appears limited to the coordinated disclosure channel (formerly ZDI-CAN-29536).

Do: Update PDF Architect to the fixed build referenced in the ZDI/pdfforge advisory, since the exact patched version is not stated in this data. As an interim mitigation, use NTFS permissions and application control to block standard users from writing to the PDF Architect installation and service directories, and monitor the activation-service process for DLL loads originating from user-writable paths. Because exploitation requires a local foothold, reinforce least-privilege account policies and treat any successful exploit as full SYSTEM compromise requiring host-level investigation.

pdfforge PDF Architect contains an out-of-bounds write vulnerability in its PDF file parsing logic, caused by inadequate validation of user-supplied data, which allows a write past the end of an allocated buffer. Exploitation requires user interaction: the victim must either open a specially crafted PDF file or visit a malicious page, after which a remote attacker can execute arbitrary code in the context of the current process. Successful exploitation gives the attacker full control with the privileges of the logged-on user, making it a serious risk on workstations where PDFs from untrusted sources are routinely opened. All users of affected PDF Architect builds on Windows are potentially at risk; the specific affected version range was not stated in the advisory data, so the vendor and ZDI advisories should be consulted. The flaw was coordinated through Trend Micro's Zero Day Initiative as ZDI-CAN-29219; it is not listed in CISA's KEV catalog and no public proof-of-concept is known, so there is no evidence of in-the-wild exploitation at this time.

Do: Update PDF Architect to the patched release as soon as pdfforge publishes the fix, checking the ZDI advisory (ZDI-CAN-29219) and pdfforge release notes for the specific fixed version. In the interim, instruct users to open PDFs only from trusted sources and to disable automatic rendering of embedded content; endpoint protections that block malicious PDF attachments (e.g., email gateway sandboxing) will reduce the user-interaction attack path.

CVE-2026-92178 is a memory corruption vulnerability (CWE-119) in how pdfforge PDF Architect parses PDF files, caused by improper validation of user-supplied data during parsing. A remote attacker can exploit it by convincing a target to visit a malicious page or open a specially crafted PDF, after which the attacker executes arbitrary code in the context of the current process, gaining the privileges of the logged-in user. All users of affected PDF Architect installations are potentially at risk, though exploitation requires user interaction, which the CVSS 3.0 score of 7.8 (AV:L/AC:L/PR:N/UI:R) reflects. The flaw was disclosed through Trend Micro's Zero Day Initiative as ZDI-CAN-28916. There is no known public proof of concept and it is not listed in CISA's Known Exploited Vulnerabilities catalog.

Do: Update PDF Architect to the latest version as soon as pdfforge releases a patch and verify the fixed version against the ZDI advisory for ZDI-CAN-28916. Until patched, instruct users not to open PDF files from untrusted sources or follow links to untrusted pages, and consider blocking PDF attachments from unknown senders at the mail gateway. Since exploitation runs code as the logged-in user, running users without administrator privileges will limit the blast radius.

CVE-2026-92176 is an out-of-bounds read (CWE-125) in how pdfforge PDF Architect handles App objects, caused by improper validation of user-supplied data that allows a read past the end of an allocated buffer. The flaw is triggered when a victim opens a malicious PDF file or visits a malicious page that feeds crafted content to the application, making user interaction a prerequisite. A successful exploit lets a remote attacker execute arbitrary code in the context of the current process, potentially gaining the privileges of the logged-in user. Anyone running an affected build of the Windows desktop PDF editor PDF Architect is exposed, particularly users who routinely open PDFs from untrusted sources. The bug was coordinated through Trend Micro's Zero Day Initiative (ZDI-CAN-28570); it is not in CISA's KEV catalog and no public proof-of-concept is known, so there is no evidence of in-the-wild exploitation.

Do: Update PDF Architect to the newest release as soon as pdfforge ships a fix — confirm the patched version against the ZDI advisory, since the affected range was not stated in this data. Until then, warn users not to open unsolicited PDFs or follow links that auto-launch PDF Architect, and consider opening untrusted documents in a sandboxed or isolated viewer. IT teams should inventory endpoints for PDF Architect installs and prioritize patching machines used for handling external documents.

Server-Side Request Forgery (SSRF) in the VMware synchronization feature in Devolutions Server 2026.2.16 and earlier allows a low-privileged authenticated user to obtain other users' credentials and reach internal or cloud-metadata network endpoints via a crafted connection definition submitted for datacenter discovery.

Improper access control in the vault entry listing feature in Devolutions Server 2026.2.16 and earlier allows an authenticated user lacking the view-password permission to obtain cleartext passwords via a request to the entry listing endpoint with password disclosure parameters.

Improper certificate validation in the shared HTTP client used by synchronization and integration features in Devolutions Server 2026.2.16 and earlier allows a network-positioned attacker to intercept and tamper with outbound TLS connections via a spoofed or self-signed certificate.

Joomla Extension - joomgalleryfriends.net - Unauthenticated arbitrary file upload via the TUS endpoint in JoomGallery < 4.4.1 - The TUS endpoint allows arbitrary file uploads, however neither file name nor file extension are under attacker control. Code execution requires non-standard server configuration.

Joomla Extension - j2commerce.com - Unescaped request data reflected into PayPal notify redirect in J2Store 1.0.0-3.3.2, 4.0.0-4.0.22, 4.1.0-4.1.7 - A crafted link to the paypal notify endpoint, if followed by a victim's browser (or an automated system that fetches it), causes the resulting redirect to `com_j2store`'s checkout controller to carry attacker-chosen query parameters instead of only the intended `view=checkout&task=confirmPayment&orderpayment_type=...&paction=process` set — parameter injection/smuggling into that follow-up request. This requires a victim to load the crafted link (`UI:R`/`UI:P`); it does not by itself grant an unauthenticated attacker anything they could not already obtain by requesting the target `com_j2store` URL directly with their own parameters.

Joomla Extension - j2commerce.com - Predictable/forgeable order access token in J2Store 1.0.0-3.3.2, 4.0.0-4.0.22, 4.1.0-4.1.7 - Anyone who obtains the site's Joomla `secret` can compute a valid access token for *any* order on the site without ever having placed one, gaining guest access to that order's details and any purchased digital downloads. Because the token is never rotated, this exposure persists indefinitely even after the underlying secret-disclosure vector is patched, unless the Joomla secret itself is also rotated. The attack complexity (`AC:H`) is high because it depends on the secret already being known through a separate vector; it is not directly exploitable by an anonymous visitor with no other foothold.

J2Store, a Joomla e-commerce extension from j2commerce.com, contains an unauthenticated flaw in its order-status handling: an attacker who can reach the storefront can send a crafted status-update request for any order without authenticating or supplying valid payment or transaction data. The impact is a denial of service against the order pipeline — pending orders can be mass-flipped to FAILED to disrupt revenue and force manual reprocessing, and already-fulfilled orders can be reverted to FAILED, triggering unwarranted refunds, cancellations, and customer-support load. The root cause maps to CWE-472 (trust of assumed-immutable web parameters) and CWE-602 (client-side/server-side enforcement mismatch) on the order-status update flow. Every released version is affected — 1.0.0-3.3.2, 4.0.0-4.0.22, and 4.1.0-4.1.7 — earning a CVSS 4.0 score of 8.7 (high), though with no integrity impact beyond order state. Exploitation status: no public PoC and no known in-the-wild attacks, but the flaw is trivially discoverable by anyone probing a Joomla store.

Do: Update J2Store to a release newer than the affected ranges — i.e., beyond 4.1.7 on the current line, or the latest available build for sites still on the 3.x/4.0.x branches — since all prior versions are vulnerable. Audit order history for unexplained FAILED transitions and reconcile order states against payment-gateway records before issuing any refunds or cancellations. Until patched, apply a WAF rule or rate limit to block and log unauthenticated requests hitting order-status update endpoints.

Concrete CMS before 9.5.3 is vulnerable to Cross-Site Request Forgery (CSRF) in the theme page-template activation feature. The Dashboard theme Inspect controller's activate_files() action created PageTemplate records from attacker-supplied pageTemplates[] values without validating an anti-CSRF token.A remote attacker could host a page that auto-submitted a forged POST request; when a signed-in administrator visited it, the request executed under the administrator's session and created theme page-template records, changing site configuration without the administrator's consent. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Andrew Gonzalez for reporting.

In Concrete CMS before 9.5.3, the SEO Bulk Update Meta Tags editor did not check per-page edit permissions before saving. The saveRecord() action validated the per-page CSRF token but never called canEditPageProperties() for the target page, so a user who was granted access to the bulk SEO tool and could view (but not edit) a given page was able to change that page's meta title, meta description, and URL handle outside their edit scope, tampering with the presentation and live URLs of otherwise protected content. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Andrew Gonzalez for reporting.

Concrete CMS before 9.5.3 did not enforce a per-page authorization check when reordering pages from the sitemap. In the sitemap Explore dashboard controller, the send_to_top and send_to_bottom reorder tasks ran after only a generic sitemap-access check; the controller loaded the page named by the attacker-controlled cNodeID parameter and changed its display order without verifying that the current user held move or arrange permission on that specific page. Because of this, an authenticated user who could reach the sitemap but had no edit or arrange rights on a given page could still move that page and alter the site's global navigation order. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Andrew Gonzalez for reporting.

Concrete CMS 8.5.3 through 9.5.2 enabled the OAuth 2.0 refresh-token grant using the unmodified upstream League grant, which issued new access tokens from a valid refresh token without re-checking the associated account's active status. A user who obtained a refresh token while active could therefore continue to mint valid access tokens after being deactivated or suspended (uIsActive=0), so deactivating an account did not revoke its API access. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L. Thanks sh4d0byss for reporting.

Concrete CMS below 9.5.3 was vulnerable to Cross-Site Request Forgery in the dashboard SEO Excluded Words page. The reset() controller action cleared the administrator-configured reserved-word list (concrete.seo.exclude_words) but did not validate the anti-CSRF token that the reset modal emitted, and it did not restrict the request to the POST method. A remote attacker who lured an authenticated user with SEO access to a crafted page could revert the reserved-word list to its default and silently alter future URL-slug generation for pages, files, topics, and other objects created through the Text urlify service, undoing the site's configured SEO slug policy. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks riodrwn for reporting.

Concrete CMS below 9.5.3 did not validate an anti-CSRF token on the block-arrangement backend endpoint (the arrange() action of Concrete\Controller\Backend\Page\ArrangeBlocks). The action enforced page-edit authorization but performed no token check, and its route accepted any HTTP method, so an attacker could induce a signed-in content editor into loading an attacker-controlled page that auto-submitted a cross-site request and reordered or moved blocks in the draft version of a page the victim was permitted to edit. The default null cookie SameSite configuration let the victim's session cookie accompany the forged request. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.

J2Store, a Joomla e-commerce extension from j2commerce.com, builds the on-disk path for purchased digital downloads in J2StoreModelOrderdownloads::getFilePath() by concatenating the configured attachment folder with the stored product_file_save_name, applying only JPath::clean() — which normalizes separators but does not reject ../ segments — and never verifying the resolved path stays inside the attachment folder. When a customer triggers a download via task=download for a product file whose saved name contains a ../ traversal sequence, the path resolves outside the attachment folder and the requester can download any file readable by the web server, such as configuration.php containing database credentials and the Joomla secret. The traversal string is most plausibly injected through the CSRF-forgeable admin product-file save actions, so an attacker needs no server compromise to plant it, and a valid token/pid pair can be obtained by simply purchasing the product. Affected deployments are Joomla sites running J2Store 1.0.0-3.3.2, 4.0.0-4.0.22, or 4.1.0-4.1.7 that use the digital downloads feature. There is no public PoC, no known in-the-wild exploitation, and the CVE is not in CISA's KEV catalog.

Do: Upgrade J2Store to a build newer than the affected ranges (later than 3.3.2 on the 3.x branch, later than 4.0.22 on 4.0.x, or later than 4.1.7 on 4.1.x), which resolves and confines the download path to the attachment folder. Audit stored product_file_save_name values in the product-files table for ../ segments and review web server access logs for task=download requests containing traversal sequences. If configuration.php may have been read, rotate the database credentials and the Joomla secret and invalidate all active sessions.

J2Store, a widely used e-commerce extension for Joomla from j2commerce.com, contains an unauthenticated blind SQL injection flaw in the storefront product list, reachable on any public shop that exposes the standard product listing or product-tags filter. An attacker with no account can craft malicious filter/listing requests and use boolean- or time-based inference to slowly extract arbitrary database content, including customer records, order data, and stored credentials or tokens. All shops running J2Store versions 1.0.0-3.3.2, 4.0.0-4.0.22, or 4.1.0-4.1.7 are affected because the vulnerable endpoint sits on the public-facing storefront, requiring no authentication or user interaction. The issue is rated high severity (CVSS 4.0: 8.7) with high impact on confidentiality of the shop database. No public proof-of-concept exists, the flaw is not on the CISA KEV list, and no exploitation in the wild has been reported as of this analysis.

Do: Upgrade J2Store immediately to a release outside the affected ranges (later than 4.1.7, or a patched build of your current branch). Until patched, apply WAF rules that filter SQL metacharacters on the product-list and product-tags filter parameters, and verify that the database account used by Joomla has least-privilege access. Review web server and database logs for anomalous, repetitive or slow-responding requests to storefront product listing/filter URLs as signs of blind SQL injection probing, and rotate any credentials, tokens, or secrets stored in the database if compromise is suspected.

Incorrect privilege assignment in the admin user-management component of Webkul Bagisto 2.4.9 allows an authenticated backend user holding only the settings.users.edit permission to escalate to full administrator. The user-update endpoint (route admin.settings.users.update, UserController::update()) does not verify that the actor is permitted to grant the requested role, does not prevent a user from changing their own role, and does not restrict assignment to roles whose permission set is a subset of the actor's own. By submitting a request that sets role_id to the Administrator role for their own account, a low-privileged administrator gains every admin-panel capability, including store configuration, payment gateway credentials, and customer PII.

Improper validation of the quantity parameter in the add-to-cart path of Webkul Bagisto v2.4.9 allows authenticated attackers to reduce their order total below the legitimate price of shippable goods.

An issue in Webkul Bagisto 2.4.9 allows a remote attacker to obtain sensitive information via the add-to-cart API and the downloadable fulfilment components.

J2Store, a Joomla e-commerce extension from j2commerce.com, ships its cart, checkout, and myprofile controllers without CSRF token checks, so a forged cross-site request can ride a victim's active session and silently overwrite the billing or shipping address before order confirmation — potentially redirecting a paid order's goods to an attacker-controlled address — or tamper with a saved profile address via saveAddress(). The attack requires user interaction (the victim must encounter attacker-controlled content while logged in), but needs no privileges and executes with the victim's own session rights, so there is no cross-account data access. The flaw is rated high severity (CVSS 4.0: 7.1, primarily an integrity impact). Every release of the product is affected: 1.0.0–3.3.2, 4.0.0–4.0.22, and 4.1.0–4.1.7. No public proof of concept exists and no in-the-wild exploitation has been observed.

Do: Upgrade every J2Store installation to the latest available release, which is newer than the affected ranges (beyond 4.1.7, 4.0.22, and 3.3.2 respectively). As an interim mitigation, enforce SameSite=Lax or Strict on session cookies (the 'cookie_samesite' setting on Joomla 4+) to blunt cross-site forgeries, and review recent orders for shipping or billing address changes made late in checkout that differ from the customer's saved profile.

On affected platforms running Arista EOS, under certain circumstances plaintext shared secrets for configured Terminal Access Controller Access-Control System Plus (TACACS+) servers

On affected platforms running Arista EOS, under certain circumstances user passwordss may be written in clear text to log files during operations when specialized non-standard debugging trace levels are explicitly enabled. To exploit these vulnerabilities, a malicious actor must already possess authenticated local administrative access to the device shell, and specialized non-standard debugging trace levels must be explicitly enabled. This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.

On affected platforms running Arista EOS, under certain circumstances plaintext private keys may be written in clear text to log files during operations when specialized non-standard debugging trace levels are explicitly enabled. To exploit these vulnerabilities, a malicious actor must already possess authenticated local administrative access to the device shell, and specialized non-standard debugging trace levels must be explicitly enabled. This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.

On affected platforms running Arista EOS with dual switch cards and with ingress Security ACLs configured on Switched Virtual Interfaces (SVI) in shared mode, restarting of the secondary switchcard forwarding agent or insertion of secondary switchcard, can cause security ACLs on shared SVIs to stop functioning. This may result in incorrect packet permit/deny behavior. This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember’s chunk decoder trims the chunk-size token and accepts leading plus or minus signs instead of requiring one or more hexadecimal digits followed by the required CRLF. When an intermediary forwards chunked data without re-encoding and interprets malformed chunk boundaries differently, an unauthenticated attacker can create TE.TE request smuggling that bypasses intermediary controls, poisons caches, or hijacks the request queue. The same response-path leniency can enable response smuggling against an ember-client used as a gateway when the upstream is malicious or compromised. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, The CookieJar client middleware stores a response cookie’s Domain attribute without checking that it domain-matches the host that supplied the cookie or rejecting public suffixes. A malicious or compromised server contacted through the same CookieJar can plant a cookie for another domain, and the jar later sends that cookie to the victim domain, enabling session fixation or overwriting security-sensitive cookies. The patch validates the Set-Cookie domain against the response origin, although public-suffix rejection remains unimplemented. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

http4s Ember, the Scala HTTP server and client implementation, serializes outbound HTTP/2 frames through a single unbounded queue consumed by its writeLoop. An unauthenticated remote attacker can trigger the flaw by sending a stream of PING, SETTINGS, or DATA frames while refusing to read responses, causing Ember to enqueue acknowledgments and WINDOW_UPDATE frames faster than the writer drains them, which exhausts heap memory and crashes or degrades the service. This only affects servers explicitly built with withHttp2, but the same shared behavior also exposes an ember-client that connects to a malicious HTTP/2 server. The vulnerability is rated high (CVSS 3.1: 7.5) with availability-only impact and requires no privileges or user interaction. There is no known public proof of concept and no evidence of exploitation in the wild, and the issue is fixed in versions 0.23.35 and 1.0.0-M47.

Do: Upgrade to http4s 0.23.35 (stable line) or 1.0.0-M47 (milestone line), where outbound queues are bounded and backpressured. If immediate upgrade is not possible, remove withHttp2 from Ember servers or front them with a reverse proxy that enforces HTTP/2 frame limits, and restrict ember-client usage to trusted upstream servers. Monitor JVM heap usage and connection behavior for unexpected growth from slow-reading peers.

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, The FollowRedirect client middleware strips Authorization and Cookie headers only when a redirect changes authority, but authority comparison excludes the URI scheme. A same-authority redirect from HTTPS to HTTP therefore preserves credentials and transmits them over a plaintext connection. An attacker who can induce the downgrade and observe the network can capture those sensitive headers from applications using FollowRedirect. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, ResponseCookie.render writes attacker-influenced name, content, domain, path, and extension values without neutralizing semicolons or control characters. An application that constructs a ResponseCookie from unvalidated input can therefore emit injected cookie attributes such as Domain, Path, or SameSite, widening cookie scope or weakening protections, and control characters may enable header splitting on permissive backends. The patch strips control characters from all five fields and strips semicolons from name, content, domain, and path while retaining the extension delimiter behavior. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

The shared WebSocket decoder in http4s, a Scala HTTP services interface, buffers message fragments without any limit during defragmentation and its FrameTranscoder accepts declared frame lengths up to Int.MaxValue (about 2 GiB). A remote, unauthenticated attacker who completes a WebSocket handshake against a service built on http4s-blaze-server or http4s-ember-server can send oversized frames or heavily fragmented messages to exhaust server memory, causing denial of service (crash or OOM). Any http4s-based application exposing WebSocket endpoints on the Blaze or Ember backends is affected. The flaw is fixed in versions 0.23.35 and 1.0.0-M47, which enforce a configurable 64 MiB default limit on individual frames and defragmented messages via EmberServerBuilder.withMaxWebSocketMessageSize. No public proof of concept or known exploitation in the wild has been reported.

Do: Upgrade to http4s 0.23.35 (0.23.x line) or 1.0.0-M47 (1.0 milestone line) as soon as possible. If immediate upgrade is not feasible, place WebSocket endpoints behind a reverse proxy that enforces frame/message size limits, and tune EmberServerBuilder.withMaxWebSocketMessageSize appropriately after patching. Monitor server memory and connection behavior for oversized-frame or fragmentation abuse on any internet-exposed Blaze or Ember WebSocket endpoints.