Vulnerabilities

node-opcua, the most widely used open-source OPC UA implementation for Node.js, contains a resource-exhaustion flaw (CWE-400) in which every failed reconnection leaves a TCP socket stranded in FIN-WAIT-2 state, leaking file descriptors and memory until the process or container is killed by the OOM killer. No attacker interaction is required: with the default keepSessionAlive: true setting, a server clock skewed beyond the server's timestamp tolerance (e.g., an industrial PLC roughly 50 minutes ahead of the client) makes the keepalive manager misread the resulting BadInvalidTimestamp fault as a network outage and force a full transport reconnect every keepAliveInterval, while the failed HEL/ACK handshake path calls socket.end() instead of socket.destroy(), so sockets the PLC never closes accumulate indefinitely. At the commonly used 3-second keepAliveInterval this is about 20 leaked sockets per minute (~1,200 per hour), so an attacker who controls or spoofs a skewed, non-responsive OPC UA endpoint — or simple clock misconfiguration — can crash the Node.js client application, gateway, or SCADA data bridge (CVSS 3.1 7.0 High, availability-focused). Any node-opcua client deployment carries the flawed code (confirmed on 2.169.0, the latest release as of April 2026), but only installations communicating with clock-skewed or non-responding servers actually leak; no public proof-of-concept or in-the-wild exploitation is known.

Do: No fixed version is named in the advisory, so watch node-opcua releases beyond 2.169.0 and upgrade as soon as a patch lands; in the interim, either disable keepSessionAlive or lengthen keepAliveInterval, and enforce NTP time synchronization (or raise the server's accepted timestamp tolerance) so client request timestamps stay within the server's window. Monitor FIN-WAIT-2 socket counts on client hosts and apply container file-descriptor/memory limits so any leak surfaces as a bounded, restartable failure rather than a silent OOM crash.

A heap-use-after-free vulnerability exists in H5T__conv_f_f() in src/H5Tconv.c in HDF5 before 1.14.2. When converting a compound datatype containing floating-point members during a dataset read, a temporary buffer allocated with calloc() is freed and subsequently read from within the same conversion routine. An attacker who can supply a crafted HDF5 file containing a specially constructed compound datatype can trigger the use-after-free when the file is parsed by an application that reads the affected dataset, such as h5dump. This can result in a crash and, depending on heap layout and allocator behavior, may be exploitable for further memory corruption up to remote code execution.

Control iD iDSecure, an on-premises access control management platform, versions prior to 4.8.3.0 contain an unauthenticated denial-of-service flaw (CWE-476). An attacker can send a simple network request to the /api/dguardintegration/dguardVersion endpoint, which dereferences the DGuard integration login state without checking whether it is set, triggering an unhandled null reference exception. Because the exception is raised inside an asynchronous method that returns void, it is never observed by a caller and can crash the entire iDSecure process. Any organization running an affected version is exposed, with the greatest risk to instances whose web API is reachable by untrusted networks. No public proof-of-concept is known, the flaw is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Upgrade iDSecure to version 4.8.3.0 or later, which resolves the flaw. If upgrading is not immediately possible, restrict network access to the iDSecure server so that only trusted hosts can reach its web API, and monitor for unexplained iDSecure process restarts or crashes, which would indicate attempted exploitation.

Control iD iDSecure, an access-control management server, exposes the /api/license/restartService endpoint without requiring authentication in versions prior to 4.8.3.0 (CWE-306, missing authentication for a critical function). When called, this endpoint runs an internal routine that terminates the iDSecure service process and relaunches it via a generated batch script. An unauthenticated remote attacker can invoke the endpoint repeatedly to trap the service in a continuous restart cycle, leaving the server unavailable and disrupting access-control management. Any organization running iDSecure before 4.8.3.0 is affected, with risk highest where the server's API is reachable from untrusted networks rather than only the local LAN. No public proof-of-concept is known, the flaw is not listed in CISA KEV, and no exploitation has been reported to date.

Do: Upgrade iDSecure to version 4.8.3.0 or later, which restores authentication on the restartService endpoint. Until patched, restrict network access to the iDSecure server so /api/license/* is reachable only from trusted management hosts, and check firewall/proxy logs for repeated unauthenticated requests to /api/license/restartService, which would indicate restart-loop attempts.

A flaw was found in flightctl. The configureRepoHTTPSClient() function in the device-render worker builds a per-repository tls.Config (which may include InsecureSkipVerify, a custom CA bundle, or tenant-supplied mTLS client certificates) and installs it into go-git's process-global client.Protocols map via gitclient.InstallProtocol("https", ...). Because the worker renders devices for multiple organizations concurrently from a shared goroutine pool, whichever tenant's repository configuration is written last wins for all in-flight git.Clone calls. This race condition can cause one tenant's TLS settings, including InsecureSkipVerify or mTLS client credentials, to leak into another tenant's git operations.

CVE-2026-92397 is an operating system command injection vulnerability in the cc_set function of unifyframe-sgi.elf, part of the configChange component of the Ruijie RG-EW3000GX wireless router running firmware EW_3.0(1)B11P380. An attacker sends a crafted request in which the data.url argument is concatenated into a shell command without sanitization, allowing arbitrary OS commands to be executed remotely; per the CVSS 4.0 vector (PR:H), the attack requires an authenticated high-privilege (administrator-level) session but no user interaction. Successful exploitation yields full command execution on the device (confidentiality, integrity and availability impacts all rated High), enabling router takeover, traffic manipulation, and pivoting into the connected LAN. Only RG-EW3000GX units running the affected EW_3.0(1)B11P380 firmware are implicated, a product line typically deployed in SOHO and small-business Wi-Fi networks. The flaw is not listed in CISA KEV and no standalone public PoC has been catalogued, although the source advisory states an exploit has been publicly disclosed; no confirmed in-the-wild exploitation is documented.

Do: Check the router's firmware version in the admin console and, if it is EW_3.0(1)B11P380, apply the latest EW 3.0 firmware from Ruijie's official support channel (no fixed version is specified in the available data, so confirm the patched release with the vendor). Minimize exposure by disabling remote/WAN management, restricting the management interface to trusted networks, and placing the device behind a firewall where possible. Monitor for unexpected requests to the configChange/unifyframe-sgi.elf handler containing shell metacharacters in the data.url parameter, and rotate administrator credentials on any device that may have been accessed.

A vulnerability has been found in SourceCodester Online Food Ordering System 1.0. The affected element is an unknown function of the file /admin/update_category.php of the component Category Update. The manipulation leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

Sentry Seer, Sentry's AI-powered debugging/fix agent, suffers from a multi-stage trust-boundary violation in which unauthenticated, attacker-controlled telemetry (Sentry events) is treated as trusted input and ultimately becomes code executed by the agent in a privileged automation environment. An external attacker triggers the flaw by submitting fabricated error events to a victim's Sentry organization without needing access to the victim's account, source repository, or infrastructure; when Seer processes the crafted events, the embedded content is translated into executed automation. Successful exploitation gives the attacker code execution within Seer's privileged environment, with whatever access that automation context carries. Any Sentry customer organization that has Seer enabled and accepts externally submitted event data is affected. As of this writing the flaw has no CVSS score, is not in CISA KEV, has no known public proof-of-concept, and there are no confirmed reports of in-the-wild exploitation (CERT/CC advisory VU#212479).

Do: Track CERT/CC VU#212479 and Sentry's advisories for the patched release and apply it promptly, since Seer is a SaaS feature and remediation may arrive server-side or as a configuration change. Until patched, consider disabling Seer or excluding projects that receive unauthenticated SDK events (e.g., public-facing web/mobile apps) from automated analysis, and lock down event ingestion (DSN handling, allowlisted origins). Review Seer automation logs and any agent-executed actions for unexpected code execution or anomalous event sources.

Dell ObjectScale, Dell's Kubernetes-based software-defined object storage platform, versions prior to 4.4.0.0 contain an incorrect permission assignment for a critical OS resource (CWE-732). The flaw can be triggered by an attacker who already holds high privileges and has remote access to the system, by acting on improperly protected OS resources. Successful exploitation primarily results in denial of service (high availability impact, with a minor integrity impact per the CVSS vector), which could disrupt object storage services. Only organizations running affected ObjectScale releases are exposed, and the attacker must already be highly privileged, limiting the realistic attack surface. No public proof-of-concept is known, the issue is not in CISA's KEV catalog, and no in-the-wild exploitation has been reported.

Do: Upgrade Dell ObjectScale to version 4.4.0.0 or later. Restrict remote access to high-privileged accounts and management interfaces (VPN, allow-listing, MFA), since exploitation requires high privileges, and audit administrative accounts for unusual activity. Monitor for storage service disruptions or restarts that could indicate exploitation.

Dell ObjectScale, Dell's Kubernetes-based enterprise object storage platform, contains a deserialization of untrusted data flaw (CWE-502) in all versions prior to 4.4.0.0. An unauthenticated attacker with remote network access to a vulnerable deployment can supply maliciously crafted serialized data to trigger the flaw, requiring no credentials or user interaction. Successful exploitation results in remote code execution, and the CVSS scope change (S:C) with high confidentiality, integrity, and availability impacts indicates a compromise could extend beyond the vulnerable component to the wider cluster or host. All Dell ObjectScale deployments running versions before 4.4.0.0 are affected. There is currently no evidence of in-the-wild exploitation, no known public proof-of-concept, and the flaw is not listed in CISA's Known Exploited Vulnerabilities catalog.

Do: Upgrade Dell ObjectScale to version 4.4.0.0 or later per Dell's security advisory. Until patched, restrict network access to ObjectScale management and service interfaces to trusted networks only, since the flaw is exploitable remotely without authentication. Review Dell's advisory for related ObjectScale fixes shipped in the same release and monitor for updates.

djust, a Python (pip) LiveView framework, left its Server-Sent-Events transport open to cross-site request forgery: the SSE client-to-server POST endpoints were decorated @csrf_exempt and the SSE GET stream endpoint performed no Origin check. An attacker hosts a web page that forces a victim's browser to GET the stream URL (which creates and mounts a LiveView using the victim's cookies) and then POSTs to the message endpoint with credentials included, using a client-chosen session_id and a text/plain JSON body that qualifies as a CORS simple request with no preflight. This lets the attacker fire state-changing, victim-authenticated event handlers on the server, with high confidentiality and integrity impact but no availability impact (CVSS 3.1: 8.1). Any djust application that exposes the SSE transport to authenticated users is affected. No public proof-of-concept or in-the-wild exploitation is known, and the flaw is not listed in CISA KEV.

Do: Upgrade to djust 1.0.7, which validates the request Origin against ALLOWED_HOSTS on all three SSE endpoints (rejecting cross-origin requests with 403) and requires Content-Type: application/json on POST endpoints (415 otherwise). If upgrading is not immediately possible, disable the SSE transport or place a reverse proxy in front of the SSE endpoints that enforces an Origin allowlist. Audit any djust application that uses SSE with cookie-authenticated LiveViews, since only those deployments are exposed to this flaw.

Dell ECS and Dell ObjectScale contain an improper privilege management vulnerability (CWE-269) that allows an attacker who already has high privileges and local access to the system to elevate those privileges. Because the CVSS vector requires local access and high existing privileges, exploitation is limited to users or compromised accounts that already have substantial control over the storage platform, but a successful attack yields full high-impact access (high confidentiality, integrity, and availability impact). Affected products are Dell ECS versions 3.8.1.0 through 3.8.1.7 and Dell ObjectScale versions prior to 4.4.0.0; ObjectScale is Dell's Kubernetes-based successor to the ECS object storage platform, so both product lines are deployed primarily in enterprise data centers. There are no reports of in-the-wild exploitation, the flaw is not in CISA KEV, and no public proof-of-concept is known.

Do: Upgrade Dell ObjectScale to version 4.4.0.0 or later and upgrade ECS to a release beyond 3.8.1.7 as specified in Dell's security advisory. Because exploitation requires local access with high privileges, restrict and audit management-plane and SSH access to ECS/ObjectScale nodes, limit the number of high-privileged storage accounts, and monitor privileged activity for anomalies. Follow Dell's advisory (CNA: Dell/emc security team) for exact fixed builds and any interim mitigations.

A flaw was found in the first-broker-login flow of the keycloak-services component. This component handles the initial authentication and account linking when a user logs in via an external identity provider. The issue allows an attacker to register a matching username on an external provider to trigger a collision in Keycloak, which results in the legitimate user being locked out of their account.

A missing authorization check (CWE-862) in Keycloak's impersonation feature allows any user holding the impersonation role to impersonate a realm administrator account. The attack is carried out over the network by an authenticated user with the impersonation role who invokes impersonation against an administrator, yielding a session with full administrative privileges. The attacker thereby gains complete control of the realm, including the ability to manage users, clients, and roles, enabling persistence and compromise of every application the realm protects. Deployments are at risk where the impersonation role has been delegated beyond full realm administrators (for example to helpdesk or user-management staff); the available data does not specify affected or fixed version ranges. No public proof-of-concept is known, the flaw is not in CISA KEV, and there are no confirmed reports of exploitation in the wild.

Do: Audit role mappings in each realm and revoke the impersonation role from any principal that is not a full realm administrator, since restricting that role is the primary mitigation. Upgrade Keycloak to the fixed release identified in the Red Hat security advisory for this CVE. Review admin-event logs for impersonation events targeting administrator accounts as a check for prior abuse.

LMdeploy's AsyncRPCServer (zmq_rpc.py) passes incoming RPC messages directly to pickle.loads() without any sanitization (CWE-502), so anyone who can send a request to the server's TCP endpoint can have it deserialize attacker-controlled pickle data. Because pickle deserialization can instantiate arbitrary objects, an attacker reaching the RPC port gains arbitrary code execution on the host; the researcher demonstrated a full reverse shell from a crafted request. The server performs no validation of the connecting IP, and although its port is randomized, an attacker can find it by port scanning, so any network-reachable deployment is at risk. Affected users are operators running lmdeploy's RPC server component (typically in distributed/multi-node LLM inference setups), especially where the service is reachable beyond localhost or from untrusted networks. No exploitation in the wild is known and the flaw is not in CISA KEV, though the advisory includes working reproduction steps, and the flaw carries a CVSS 3.1 score of 9.8 (critical).

Do: No patched version is identified in the advisory, so monitor the lmdeploy repository/PyPI for a fix and upgrade as soon as one is released; the maintainer-suggested mitigations are replacing pickle with a safer serializer (e.g., msgpack or safetensors) or restricting deserialization via an Unpickler.find_class allowlist, plus enabling RPC authentication. In the meantime, bind the RPC server to localhost or a trusted, firewalled cluster network only, and audit hosts for lmdeploy RPC processes listening on non-local ports.

Dell ObjectScale, Dell's Kubernetes-based enterprise object storage platform, contains an improper authentication flaw (CWE-287) in versions prior to 4.4.0.0. An unauthenticated attacker with network access to the affected system could potentially exploit it, though the CVSS vector indicates high attack complexity. Successful exploitation leads to unauthorized access, with high impact on confidentiality, integrity, and availability per the CVSS 8.1 score. All deployments running ObjectScale versions before 4.4.0.0 are affected. As of this analysis, there is no evidence of exploitation in the wild, no public proof-of-concept, and the flaw is not listed in CISA's Known Exploited Vulnerabilities catalog.

Do: Upgrade Dell ObjectScale to version 4.4.0.0 or later as published in Dell's security advisory. Until patched, restrict network access to ObjectScale management and service interfaces to trusted networks and review access logs for unexplained activity. Verify the currently deployed ObjectScale version, as only pre-4.4.0.0 releases are affected.

FileRise before version 3.28.0 fails to enforce independent, stateless authentication on its WebDAV interface, as required by RFC 4918, and instead lets WebDAV requests inherit privileges from an ambient web application session (CWE-613, insufficient session isolation). A low-privilege authenticated user can send WebDAV requests with their own valid Basic-Auth credentials combined with an active administrator PHPSESSID cookie, causing the WebDAV layer to treat the request as admin-level. The attacker gains unauthorized read and write access to files and folders that should be outside their authorization boundary, though no availability impact is assessed (CVSS 4.0: 7.6 High, AV:N/AC:H/PR:L/UI:N/VC:H/VI:H). Any FileRise deployment running an affected version with both the web UI and the WebDAV interface enabled is affected, with the highest risk where admin and low-privilege sessions can share a browser or where an admin cookie can be injected into requests. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known as of this analysis.

Do: Upgrade to FileRise 3.28.0 or later, which enforces independent WebDAV authentication. As interim mitigations, do not use the admin web UI and WebDAV from the same browser session, log out of admin sessions after use, and restrict the WebDAV endpoint via reverse-proxy allowlisting or VPN. Check WebDAV access logs for low-privilege accounts performing unexpected reads or writes on admin-owned files.

Rejected reason: CVE ID reserved in error and not assigned to a vulnerability. The correct CVE ID is CVE-2026-92574.

reNgine, an open-source automated reconnaissance framework, through version 2.2.0 fails to enforce role-based authorization on its GetFileContents API endpoint (CWE-862). Any authenticated user, including the low-privilege Auditor role, can query the endpoint over the network without a permission check and read the bundled configuration files for its recon tools. Those files contain the instance's third-party API keys for services such as SecurityTrails, Shodan, Censys, VirusTotal, BinaryEdge and Hunter, so an attacker gains full disclosure of stored credentials that can be abused or resold. Anyone running a self-hosted reNgine instance — typically bug-bounty hunters and security teams on internet-reachable VPS deployments — is affected if untrusted users hold Auditor accounts. No public proof-of-concept is known and the flaw is not in CISA's KEV, so exploitation has not been confirmed.

Do: Upgrade reNgine to a patched release as soon as one is published (no fixed version is specified in current disclosures) and restrict the Auditor role to fully trusted users. As interim mitigation, block or restrict access to the GetFileContents endpoint at the reverse proxy/WAF layer and review instance logs for API calls made by Auditor-role accounts. If low-privilege users could have reached the endpoint, rotate the stored Shodan, Censys, VirusTotal, SecurityTrails, BinaryEdge and Hunter API keys.

Hippo4j through 1.5.0 contains a server-side request forgery vulnerability in four ThreadPoolController endpoints that fail to validate the clientAddress parameter. Authenticated attackers can supply arbitrary hostnames and ports to trigger outbound GET requests to internal networks and cloud metadata services.

MLRun through 1.11.0 contains a server-side request forgery vulnerability in the WebhookNotification handler that allows authenticated users to make the API server send arbitrary HTTP requests to internal addresses. Attackers can update a run with a malicious webhook notification that executes when the run reaches a terminal state, enabling requests to internal services, Kubernetes APIs, or cloud metadata endpoints from within the cluster.

TDuck survey form through version 5.0 contains an authorization bypass (CWE-639) in the POST /user/form/data/update endpoint, which fails to verify that the authenticated caller owns the targeted form submission. Because submission identifiers are allocated in narrow, predictable ranges, an authenticated user can enumerate other users' submission IDs and send update requests that overwrite arbitrary form responses, including responses containing personal data. The flaw requires only low-privilege authenticated access with no user interaction, and per the CVSS score the impact is to data integrity rather than confidentiality. Any organization running TDuck 5.0 or earlier is affected. No public proof-of-concept or in-the-wild exploitation is currently known, and the vulnerability is not listed in CISA's KEV.

Do: Deploy a fixed TDuck release as soon as the vendor publishes one, and in the meantime restrict access to the POST /user/form/data/update endpoint to trusted, minimal user roles. Audit form submission records for unauthorized modifications and review access logs for authenticated users issuing update requests against submission IDs they do not own, particularly patterns of sequential ID enumeration.

DataGear through version 6.0.0 contains a server-side request forgery (CWE-918) in its /dataSet/preview/Http endpoint, which is reachable without authentication. An attacker supplies a fully caller-controlled URI, causing the server to issue arbitrary GET, POST, PUT, PATCH, or DELETE requests to attacker-chosen destinations. Because the full response bodies are returned to the attacker, they can read data from internal network services and cloud instance metadata endpoints, enabling information disclosure and potentially credential theft for further attacks. Any deployment of DataGear up to and including 6.0.0 is affected, with the greatest risk to internet-exposed instances or those running in cloud environments where a metadata service is reachable. No public proof-of-concept and no confirmed in-the-wild exploitation are known, and the issue is not listed in CISA KEV.

Do: Upgrade DataGear to a version newer than 6.0.0 as soon as a patched release is available, since no fixed version is specified in the current data. As interim mitigations, restrict or block unauthenticated access to the /dataSet/preview/Http path at a reverse proxy or WAF, and apply egress filtering so the application server cannot reach cloud metadata addresses (e.g., link-local metadata IPs) or sensitive internal services. Review access logs for unauthenticated requests to /dataSet/preview/Http that could indicate probing or exploitation.

Rallly before 4.15.0 contains an information disclosure vulnerability in the polls.get tRPC procedure that returns scheduled-event invitee names and email addresses to unauthenticated callers. Attackers can access a poll's urlId from public invite links to retrieve sensitive invitee information regardless of privacy settings.

A flaw in @fastify/proxy-addr versions 3.0.0 through 5.1.0, the Fastify plugin that computes request.ip and request.ips, causes trust subnets written in IPv4-mapped IPv6 notation with an IPv4-sized prefix (e.g., ::ffff:10.0.0.0/8 instead of ::ffff:10.0.0.0/104) to be silently accepted as trusting every IPv4 address on the internet. In that configuration the direct socket peer is trusted at hop 0, so any unauthenticated client can supply an arbitrary X-Forwarded-For header and fully control the client address the application reads. An attacker can thereby defeat IP-based access control, rate limiting, geolocation, and audit logging. Only Fastify applications on affected plugin versions that define a trust proxy subnet in IPv4-mapped IPv6 notation with a prefix shorter than 97 bits are exploitable; the defect was inherited from the upstream proxy-addr module (CVE-2026-90711). No exploitation in the wild and no public proof-of-concept are known, and a fix is available in version 5.1.1.

Do: Upgrade @fastify/proxy-addr to 5.1.1 or later (and apply the upstream proxy-addr fix referenced by CVE-2026-90711 if that module is used directly). Audit trustProxy settings and replace any IPv4-mapped IPv6 subnet with a prefix shorter than 97 bits using a prefix of at least 97 (e.g., /104) or plain IPv4 notation such as 10.0.0.0/8. Until patched, avoid relying on request.ip for IP allowlists, rate limiting, or audit logging.

A security vulnerability has been detected in PbootCMS up to 3.2.24. This vulnerability affects the function UserController::del/UserController::mod of the file apps/admin/controller/system/UserController.php of the component User Management. Such manipulation leads to cross-site request forgery. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. Upgrading to version 3.2.25 is able to resolve this issue. The name of the patch is c25241a0964742cefb7f698efbb6c38b868d6ff7. It is advisable to upgrade the affected component.

A weakness has been identified in PbootCMS up to 3.2.22. This affects the function decode_string of the file apps/admin/controller/content/ContentController.php of the component Template Rendering. This manipulation of the argument Title causes cross site scripting. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The reported GitHub issue was closed with the reason "completed".

A flaw has been found in WuzhiCMS up to 4.1.0. The impacted element is the function ckditor::saveRemote of the file coreframe/app/attachment/index.php of the component Remote Image Fetch. This manipulation of the argument source[] causes server-side request forgery. The attack can be initiated remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability was determined in code-projects Matrimonial System 1.0. This affects an unknown part of the file /search.php of the component Regular Search. This manipulation of the argument sex/mothertongue/maritialstatus/country/state/religion/agemin/agemax causes sql injection. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized.

@fastify/auth versions 5.0.0 through 5.1.0 mishandle nested strategy groups: when strategies are composed with the 'or' relation together with the run 'all' option and one entry is a nested array acting as an AND group, evaluation is order-dependent, so an earlier failing check is silently dropped and the group's result becomes the outcome of its last check. As a result, a request that satisfies only the final member of an AND group — for example, a caller holding a valid API key but lacking administrator rights — is authorized instead of rejected, granting access or privileges the AND group was intended to deny; a mirrored order-dependent bypass affects configurations where the top-level relation is 'and' with a nested 'or' group. Any application using @fastify/auth 5.0.0–5.1.0 with these specific compositions is affected, and exploitation requires only a low-privileged identity that satisfies the last check in the group (no user interaction). No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is currently known.

Do: Upgrade to @fastify/auth 5.1.1 or later. If upgrading is not immediately possible, audit route definitions for the 'or' relation combined with run 'all' (and the mirrored top-level 'and' with nested 'or' groups), omit run 'all' where it is not required, order each AND group so its stricter check is evaluated last, or replace nested AND groups with an explicit top-level 'and' composition. Also review authorization logs for access granted to identities holding only weaker credentials (e.g., API keys) where administrator-level checks were expected.

Adenion Blog2Social plugin for WordPress before 9.1.0 allows low-privileged users to modify the scheduled post records of other users. The b2s_calendar_move_post AJAX handler in includes/Ajax/Post.php issues an UPDATE against the b2s_posts table using only the attacker-supplied b2s_id primary key with no blog_user_id ownership constraint, allowing any user with the edit_posts capability to reschedule, suppress, or alter the publication state of any other user's scheduled social media post.

Plate is a rich-text editor with AI and shadcn/ui. Prior to 53.3.11, and in the discontinued 54.0.0-beta.0 through 54.0.0-beta.1 builds, Plate core HTML deserialization APIs parse supplied HTML strings in the active document. When an application passes untrusted or cross-user HTML to these APIs, certain HTML attributes can trigger browser behavior before the HTML is converted into editor nodes. This can allow attacker-controlled script to execute in the consuming application's origin when another user loads the deserialized content. This issue is fixed in version 53.3.11.

Backstage's @backstage/plugin-techdocs-node package, which powers TechDocs documentation generation, insufficiently validates the mkdocs.yml file supplied by an authenticated user who can register or modify a TechDocs source. Unsafe Python YAML tags, markdown_extensions names and configuration, theme options, and extra_templates values are passed through to the MkDocs documentation generator, causing unintended code execution during the build. An attacker gains code execution in the context of the TechDocs backend or build container, limited to the files, credentials, network access, and other resources available to that process. Any Backstage deployment running a vulnerable version of the plugin with TechDocs enabled is affected wherever non-fully-trusted users can contribute documentation sources. No public proof-of-concept, KEV listing, or known in-the-wild exploitation has been reported; fixes are available in versions 1.14.6 and 1.15.4.

Do: Upgrade @backstage/plugin-techdocs-node to 1.14.6 (1.14.x line) or 1.15.4 or later. Until patched, restrict which authenticated users can register or modify TechDocs-enabled catalog entries, and reduce the TechDocs backend/build container's access to files, credentials, and network resources. Audit recently added or modified mkdocs.yml files for unsafe Python YAML tags, unusual markdown_extensions, theme options, or extra_templates values.

ReactPHP's react/http package, an event-driven streaming HTTP client and server library, contains an unauthenticated denial-of-service flaw (CWE-835, infinite loop) in its ChunkedDecoder component, present from version 0.6.0 through versions before 1.11.1. Because the decoder's handleData routine only exits its loop when the buffer shrinks on each iteration, a malformed Transfer-Encoding: chunked body — an incomplete terminal-chunk trailer lacking CRLF, or exactly two non-CRLF bytes after a completed non-terminal chunk — leaves the buffer unchanged and loops forever. A malicious client can therefore freeze any server built on React\Http\HttpServer by sending a crafted request body, and a malicious or compromised server can freeze any client using React\Http\Browser via a crafted response body, hanging the event loop and every connection it serves. A reverse proxy that normalizes inbound requests may shield the server direction but does not protect outbound Browser requests. No public proof-of-concept or exploitation has been reported (not in CISA KEV), and the flaw is fixed in react/http 1.11.1.

Do: Upgrade react/http to 1.11.1 or later (e.g., composer update react/http) and verify the patched version in composer.lock and the vendor directory. Until patched, place a reverse proxy that normalizes or rejects malformed chunked requests in front of HttpServer — noting this does not protect outbound Browser requests — and restrict Browser use to trusted servers. Audit PHP applications for this dependency, since Composer packages are often invisible in conventional asset inventories.

ScadaLTS 2.8.1-release-candidate build 0 enforces Spring Security access control on DWR endpoints only by URL path pattern, while DWR actually decides which Java method to invoke from POST body parameters (c0-scriptName and c0-methodName). Because the crossDomainSessionSecurity setting in web.xml is set to false, DWR's built-in origin validation is disabled, so any authenticated user can send a request to a URL they are permitted to access (such as MiscDwr.initializeLongPoll.dwr) while naming a restricted class in the POST body. This lets a low-privilege authenticated user invoke any DWR method that should be off-limits, effectively bypassing URL-based authorization and enabling several other ScadaLTS flaws to be exploited without elevated privileges. Any deployment of ScadaLTS 2.8.1-release-candidate build 0 with authenticated low-privilege accounts is affected. No public proof-of-concept or known exploitation has been reported, and the issue is not in CISA's KEV catalog.

Do: Upgrade ScadaLTS to a release that fixes the DWR authorization bypass as soon as the vendor publishes one (no fixed version is stated in the available data). As an interim mitigation, set crossDomainSessionSecurity to true in web.xml to restore DWR origin validation, restrict network access to the ScadaLTS web interface, and limit which low-privilege accounts exist on internet-reachable instances. Because this bypass chains with other DWR-based findings, review access logs for authenticated low-privilege users calling restricted DWR classes.

ScadaLTS 2.8.1-release-candidate build 0 is affected by an Authenticated Blind SQL Injection The /api/events/search endpoint accepts a JSON body containing a sortBy array. The values in this array are concatenated directly into the SQL ORDER BY clause without any sanitization or parameterization. This allows authenticated users with the ROLE_USER role to perform time-based and boolean-based blind SQL injection to extract arbitrary data from the database, including password hashes of all users. The endpoint is accessible to any authenticated user with ROLE_USER, ROLE_ADMIN, or ROLE_PUBLIC via POST /api/events/search as defined in spring-security.xml.

ScadaLTS 2.8.1-release-candidate build 0 contains an authenticated remote code execution flaw caused by a scripting sandbox bypass. The DWR (Direct Web Remoting) class DataSourceEditDwr exposes a validateScript method that compiles and executes attacker-supplied JavaScript through the Rhino scripting engine, and this method has no authorization checks. A low-privilege authenticated user can invoke validateScript via a DWR routing bypass, causing their JavaScript to run on the server. Successful exploitation yields full confidentiality, integrity, and availability impact on the SCADA host (CVSS 8.8), effectively giving the attacker code execution as the web application service account. No exploitation has been reported and no public proof-of-concept is known; the issue was assigned by Tenable's CNA.

Do: Upgrade ScadaLTS to a fixed release as soon as the vendor publishes one (no fixed version is identified in the available data), and in the meantime restrict which accounts can reach the DWR endpoints and limit network access to the web interface to trusted operators only. Review data sources and scripting configurations for unauthorized edits, monitor validateScript/DataSourceEditDwr requests in web logs, and ensure low-privilege users cannot reach the SCADA server's HTTP service from untrusted networks.

CVE-2026-82964 is an improper preservation of permissions (CWE-281/CWE-862) in the Avast sandbox minifilter driver (aswSnx.sys) on Windows: the driver opens virtualization target objects with GENERIC_WRITE and FILE_WRITE_ATTRIBUTES but omits WRITE_DAC, so every attempt to reapply the original security descriptor fails silently, leaving virtualized copies of sensitive files with permissive permissions. The IRP_MJ_CREATE callback also fails to strip WRITE_DAC for sensitive directories, allowing a local, low-privileged process running inside the Avast sandbox to rewrite the security descriptor of a virtualized object and read its virtualized copy. By doing so against the SAM database, the attacker extracts local NTLM password hashes and can execute code as SYSTEM, fully escaping the sandbox's file isolation. Any Windows host running Avast products with the sandbox driver loaded is potentially affected, though the attack requires a low-privileged attacker already executing inside the sandbox. No public proof-of-concept is known, the flaw is not on CISA's KEV list, and no in-the-wild exploitation has been reported.

Do: Update Avast/Gen Digital products to the latest available patched release once the vendor publishes a fixed version (no fixed version is given in the source data), and watch for Gen Digital advisories referencing CVE-2026-82964. Until patched, avoid running untrusted low-privileged code inside Avast's sandbox, and treat unexpected writes to security descriptors on sandbox-virtualized objects as suspicious. Note that the missing IRP_MJ_SET_SECURITY callback is only a defense-in-depth gap; patching must address the WRITE_DAC handling, not just add that callback.

PocketBase, an open-source Go web backend, applies its panic-recovery middleware only to regular request handling, leaving internal child and worker goroutines unprotected against uncaught panics (CWE-248). If a panic occurs inside one of these internal goroutines — such as background or realtime worker code — it escapes recovery and terminates the entire server process. Per the CVSS vector (network vector, low complexity, no privileges or user interaction required), an unauthenticated remote attacker who can reach the server can induce such a crash, gaining a denial of service with no confidentiality or integrity impact. All deployments running versions prior to 0.22.48 on the 0.22 maintenance line, or prior to 0.39.7 on the current line, are affected. No public proof-of-concept or confirmed in-the-wild exploitation is known at this time.

Do: Upgrade to PocketBase 0.39.7, or 0.22.48 if you are pinned to the 0.22 maintenance branch; the fix adds routine.SafeWrap so worker-goroutine panics become handled errors instead of process crashes. If you cannot patch immediately, restrict unauthenticated network access to the instance (reverse-proxy authentication, firewall rules) and run the binary under a supervisor (e.g., systemd) that restarts it after a crash. Verify the running version in the admin dashboard after upgrading.

CVE-2026-80274 is a remotely triggerable denial-of-service (unexpected program exit, CWE-617) in ISC BIND 9 recursive resolvers when processing certain DNSSEC responses. It is triggered without authentication or user interaction when a resolver queries a DNSSEC-signed authoritative zone and receives a valid wildcard answer with a signed NSEC3 proof, followed by an unsigned NSEC record at the same owner name. A successful trigger crashes the named daemon, denying DNS service to all clients that depend on that resolver until it is restarted. Any operator running an affected BIND 9 resolver that performs DNSSEC validation is exposed (authoritative-only servers are not the crash target). No public proof-of-concept, in-the-wild exploitation, or CISA KEV listing is known; the flaw was disclosed by ISC as one of fourteen BIND 9 vulnerabilities.

Do: Upgrade affected resolvers to the first fixed release per ISC's advisory for CVE-2026-80274 (any release after 9.18.50, 9.20.27, 9.21.25, and the corresponding 9.18.50-S1 / 9.20.27-S1 preview builds). As interim mitigation, restrict recursion to trusted clients and, if operationally acceptable, disable DNSSEC validation on exposed resolvers until patching. Since ISC disclosed fourteen BIND 9 vulnerabilities at once, inventory all resolver instances and patch the full set together.

CVE-2026-79651 is an uncontrolled resource-consumption flaw (CWE-400) in the theme localization endpoints of the keycloak-services component of Keycloak, the open-source identity and access management software that handles authentication flows and theme management. The endpoints accept arbitrary locale tags from unauthenticated requests and store them in a permanent in-memory cache that has no size or entry limits. A remote attacker with no credentials can send a large volume of unique locale tags, filling this cache until the server exhausts memory and crashes, causing a denial of service; there is no confidentiality or integrity impact. Any deployment of Keycloak exposing the affected endpoints, especially over the internet, is affected. No public proof-of-concept is known and the flaw is not listed in the CISA KEV catalog at the time of writing, though the attack requires no special conditions (low attack complexity, no privileges, no user interaction).

Do: Apply the fixed Keycloak release as soon as Red Hat publishes it, since this advisory does not specify a patched version. As an interim mitigation, restrict or rate-limit unauthenticated access to the theme localization endpoints at a reverse proxy, WAF, or load balancer, and ensure memory monitoring and automatic restart policies are in place. Check whether your Keycloak instances (including the Red Hat build of Keycloak, if deployed) expose these endpoints publicly, as internet-facing authentication servers are the most likely targets.

RabbitMQ's amqp091-go library, the standard Go AMQP 0.9.1 client, prior to version 1.13.0 reads the length of an AMQP byte-array field (type tag 'x') in readField (read.go) into a signed int32 and passes it directly to make() when allocating the field buffer. A malicious or compromised broker can encode a length of 0xFFFFFFFF, which is interpreted as -1 and triggers a 'len out of range' runtime panic. The panic escapes the network reader goroutine and terminates the entire client process, and can be triggered during parsing of connection.start server properties or message header tables, i.e., essentially any interaction with a hostile broker. An attacker who controls or compromises the broker gains denial of service against every Go client connecting to it, with no confidentiality or integrity impact indicated by the CVSS vector (VA:H, VC:N, VI:N). Any Go application using amqp091-go before 1.13.0 is affected; no public PoC or known exploitation exists and the issue is not in CISA KEV.

Do: Upgrade amqp091-go to version 1.13.0 or later (e.g., 'go get github.com/rabbitmq/[email protected]') and audit go.mod / dependency graphs for vulnerable versions. Until patched, restrict clients to trusted brokers, lock down broker access and credentials (the flaw requires a malicious or compromised broker), and monitor for unexplained client process restarts/crashes.

RabbitMQ's amqp091-go, the standard Go client library for the AMQP 0-9-1 messaging protocol, contains an improper error-handling flaw (CWE-754): before version 1.13.0, readLongstr in read.go returns an empty string and a nil error when a declared long-string length exceeds 0x7FFFFFFF, instead of returning ErrSyntax. A malicious or compromised broker can supply a table field with such an oversized longstr; readTable treats the failed read as successful and continues parsing from the wrong byte offset, desynchronizing the connection. Attacker-controlled trailing bytes are then misinterpreted as later table fields or protocol frames, disrupting connection integrity and availability — CVSS 4.0 scores this critical (9.5), though exploitation requires the client to be connected to a hostile broker. Any Go application built with amqp091-go prior to 1.13.0 is affected, particularly those connecting to third-party, multi-tenant, or otherwise not-fully-trusted AMQP endpoints. No public proof-of-concept is known, the flaw is not in CISA's KEV, and no exploitation has been reported.

Do: Upgrade to amqp091-go 1.13.0 or later and rebuild all Go binaries that link the library; audit go.mod, vendored copies, and dependency trees for versions below 1.13.0. Until patched, restrict clients to brokers you fully control and treat connections to third-party or shared AMQP services as untrusted. Prioritize patching applications that talk to external or multi-tenant brokers, since broker compromise or malice is the prerequisite for exploitation.

Channel.recvContent in channel.go of the RabbitMQ amqp091-go Go client preallocates the message body slice using the uint64 size declared in an AMQP content header, without capping the allocation to the negotiated Connection.Config.FrameSize. A malicious or compromised broker can therefore declare an extreme body size, causing the Go runtime to attempt a correspondingly huge allocation before any body data is actually received, and the resulting memory exhaustion can terminate the client process. An attacker who controls or compromises the broker gains denial of service only — there is no confidentiality or integrity impact, though downstream systems relying on the client's availability are also affected (CVSS 4.0 rates availability impact high). Any Go application built with amqp091-go before 1.13.0 that consumes messages from a broker is affected, with real-world exploitability contingent on the broker turning malicious or being compromised. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known.

Do: Upgrade the github.com/rabbitmq/amqp091-go dependency to version 1.13.0 or later, then verify via go.mod, go list -m all, or govulncheck that no stale copies of older versions remain in the build. Until upgraded, limit consumers to trusted brokers over TLS, treat shared or multi-tenant broker environments as higher risk, and monitor client processes for abnormal memory growth. There is no configuration-only substitute for the fix, since the patched code caps the preallocation to the negotiated frame size.

RabbitMQ's amqp091-go, the widely used Go client for the AMQP 0-9-1 protocol, prior to version 1.13.0 synchronously forwards broker events — publisher confirmations, flow-control notices, consumer cancellations, and returned messages, including NotifyConfirm events and connection-block notifications — to application-supplied Go channels in Channel.dispatch, confirms.confirm, and Connection.dispatch0. If such a channel is unbuffered, full, or not drained promptly, the client's sole reader goroutine blocks on the send and stops processing incoming frames, acknowledgments, deliveries, and heartbeats. An attacker or compromised/misbehaving broker that can trigger bursts of these events can therefore stall connections, cause missed heartbeats, deadlocks, and disconnections — an availability-focused denial of service that can silently halt message processing (CVSS 4.0 rates availability impact as High). Any Go application embedding amqp091-go before 1.13.0 that passes unbuffered or under-drained notification channels to the library's Notify* APIs is affected. No public proof-of-concept or confirmed in-the-wild exploitation is known, and the issue is not listed in CISA KEV.

Do: Upgrade github.com/rabbitmq/amqp091-go to version 1.13.0 or later and scan go.mod / dependency graphs for older versions. If upgrading is not immediately possible, audit all Notify* registrations (e.g., NotifyConfirm, NotifyReturn, NotifyFlow, NotifyCancel, connection block notifications) and ensure the supplied channels are adequately buffered and drained by dedicated goroutines that never block on send.

RabbitMQ's amqp091-go Go client library, prior to version 1.13.0, contains an integer overflow (CWE-190) in the writeShortstr function in write.go, which casts the byte length of AMQP 'shortstr' property values to uint8 without rejecting values longer than 255 bytes. If an application allows an oversized value to reach any shortstr field — CorrelationId, ReplyTo, MessageId, Expiration, UserId, AppId, ContentType, ContentEncoding, or Type, frequently data originating from user or upstream input — the length wraps and only a truncated prefix is serialized, with no error reported. An attacker who can influence these fields can therefore silently corrupt message metadata, breaking request/reply correlation, routing, tracing, and downstream message processing; CVSS 4.0 rates the confidentiality impact low but message integrity and availability impact high. Any Go application or service embedding amqp091-go before 1.13.0 to communicate with RabbitMQ is affected regardless of broker version, since the flaw is in the client-side serializer. No exploitation has been reported, no public proof-of-concept is known, and the issue is not listed in CISA's KEV catalog.

Do: Upgrade to amqp091-go v1.13.0 or later and rebuild and redeploy every Go service that embeds the library (patching the RabbitMQ broker alone does not fix this). As an interim mitigation, validate before publishing that the byte length of CorrelationId, ReplyTo, MessageId, Expiration, UserId, AppId, ContentType, ContentEncoding, and Type values never exceeds 255 bytes, especially when these fields are derived from user or third-party input. Also review Go-based consumers and request/reply flows for unexplained correlation or routing failures, which would indicate past silent truncation.

The official Go AMQP 0.9.1 client for RabbitMQ (amqp091-go) fails to clear PlainAuth credentials after a successful PLAIN authentication handshake: Connection.openComplete in connection.go leaves exported plaintext username/password fields populated in Connection.Config.SASL for the lifetime of the connection. The flaw is triggered by any code that can access the live Connection object, such as reflective loggers, application performance monitoring agents, debugging utilities, and panic handlers, which can traverse the configuration and dump the credentials into logs or state captures. An attacker with local process access, or anyone who obtains such log output or crash dumps, gains the valid RabbitMQ username and password. All applications built with amqp091-go versions prior to 1.13.0 that authenticate with PLAIN are affected. No public proof-of-concept, listing in CISA KEV, or known in-the-wild exploitation has been reported; the vendor-assigned CVSS 4.0 score is 7.0 (high) with a local attack vector.

Do: Upgrade amqp091-go to version 1.13.0 or later, which clears the credentials after authentication. As an interim mitigation, ensure loggers, APM agents, debug dumps, and panic handlers never serialize Connection.Config or its SASL fields, and audit existing logs and crash captures for exposed passwords. If sensitive logs or dumps may have retained credentials, rotate the affected RabbitMQ user credentials.

The RabbitMQ amqp091-go library (the official Go AMQP 0.9.1 client) fails to validate values passed to Channel.Qos before casting signed integers to unsigned uint16/uint32 fields, a signed-to-unsigned conversion error (CWE-195). Versions prior to 1.13.0 wrap negative values such as -1 into extremely large prefetch limits (65535 or 4294967295) instead of rejecting them. Exploitation requires an application that lets untrusted input configure these Qos values; an attacker who can set a negative prefetchCount or prefetchSize causes the client to accept massive prefetch limits, letting the broker flood it with queued messages until client memory is exhausted and message processing is disrupted (denial of service, with limited impact on downstream systems). Any Go application embedding amqp091-go before 1.13.0 is vulnerable in principle, but only those exposing Qos settings to untrusted control are realistically exploitable, which the CVSS attack-requirements metric reflects. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known.

Do: Upgrade github.com/rabbitmq/amqp091-go to version 1.13.0 or later, which restores Qos validation. In the meantime, audit your dependency tree (go.mod) for the library and reject or clamp negative prefetchCount/prefetchSize values at the application layer, especially where Qos settings come from user- or API-supplied configuration. Treat this primarily as a client-side denial-of-service risk; brokers and message data are not directly compromised.

Prior to version 1.13.0, the tlsConfigFromURI function in uri.go of RabbitMQ's amqp091-go library builds tls.Config objects without setting MinVersion to tls.VersionTLS12. When an application connects through an amqps URI on a build whose Go runtime defaults still permit TLS 1.0 or TLS 1.1, the AMQP-over-TLS connection can negotiate an obsolete protocol version. A network attacker able to influence TLS negotiation against such a legacy build can weaken transport protection, exposing AMQP message contents and broker credentials to reduced confidentiality and integrity. Only applications embedding this Go client library under those conditions are affected; the flaw is fixed in version 1.13.0. No public proof-of-concept or in-the-wild exploitation is known, and the issue is not listed in CISA KEV, though its CVSS 4.0 score of 9.4 is critical (with high attack complexity and a prerequisite vulnerable configuration).

Do: Upgrade amqp091-go to version 1.13.0 or later. As an interim mitigation, explicitly set tls.Config MinVersion to tls.VersionTLS12 (or higher) in application code and build with a Go toolchain whose TLS defaults already enforce TLS 1.2+. Audit whether your services connect via amqps URIs that rely on tlsConfigFromURI, since those are the affected code paths.