Vulnerabilities

A vulnerability was identified in GPAC 26.08-DEV. The impacted element is the function gf_sg_command_del of the file src/scenegraph/commands.c of the component BIFS Handler. The manipulation leads to use after free. The attack needs to be performed locally. The exploit is publicly available and might be used. Upgrading to version abi-16.24 is sufficient to resolve this issue. The identifier of the patch is e34f4ba349d55cd1849f0bcf4cf46552732e2db7. It is suggested to upgrade the affected component.

A vulnerability was determined in GPAC 26.08-DEV. The affected element is the function gf_node_deactivate_ex of the file src/scenegraph/base_scenegraph.c of the component MP4Box. Executing a manipulation can lead to use after free. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. Upgrading to version abi-16.24 is sufficient to fix this issue. This patch is called e34f4ba349d55cd1849f0bcf4cf46552732e2db7. The affected component should be upgraded. This issue is distinct from CVE-2026-90827.

A vulnerability was determined in ChangeWeDer crm up to c07bd4c97141521af6475034bc58523beed51bbd. This vulnerability affects unknown code of the file src/main/resources/public/js/customerServe/customer.serve.js of the component Save Endpoint. This manipulation of the argument customerName causes cross site scripting. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The project was informed of the problem early through an issue report but has not responded yet.

Open5GS up to and including 2.8.0 contains a null pointer dereference (CWE-476) in ogs_pfcp_parse_volume_measurement in lib/pfcp/types.c, part of the PFCP message handler used by its 4G/5G core network functions. An attacker who can send crafted PFCP traffic to a vulnerable SMF or UPF can trigger the flaw remotely, causing the affected process to crash. Per the CVSS 4.0 score (7.1 High), the impact is high availability loss with no confidentiality or integrity impact, so the practical outcome is denial of service of core network elements. Any operator running Open5GS 2.8.0 or earlier is affected, particularly deployments where the PFCP endpoint (typically UDP 8805) is reachable from untrusted networks. No public proof-of-concept is known and the flaw is not listed in CISA KEV, so exploitation has not been confirmed.

Do: Upgrade Open5GS to a release that includes the fix commit 8f07b507b78ff94776f2cd49276eb116ed93d7f2, or apply that commit to a 2.8.0 build. Until patched, firewall PFCP (UDP 8805) so only trusted SMF/UPF peers can reach it and restrict N4 interface exposure to management networks. Monitor SMF/UPF processes for unexplained crashes or restarts, which could indicate probing against this flaw.

HP has disclosed a critical vulnerability (CWE-122, heap-based buffer overflow) in HPLIP (HP Linux Imaging and Printing), part of a batch of externally reported flaws in several HPLIP components. According to the CVSS 4.0 vector, it can be triggered remotely over a network with low attack complexity, no privileges required, and no user interaction, and could enable remote code execution, privilege escalation, denial of service, information disclosure, or unauthorized file modification under certain conditions. Anyone running HPLIP to drive HP printers or scanners on Linux is potentially affected, with the greatest risk on systems where HPLIP-related services are reachable from the network. As of now there is no evidence of exploitation, no public proof of concept, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. HP has released remediation, so users should move to the patched HPLIP release.

Do: Update HPLIP to the latest patched release from HP or apply the HPLIP security update provided through your Linux distribution's package manager. Audit systems for HPLIP/hp-* services exposed to untrusted networks and restrict access where possible. Monitor HP's security advisory for the specific fixed version and component details.

Junrar is an open source Java RAR archive library. Prior to version 7.6.1, LocalFolderExtractor in src/main/java/com/github/junrar/LocalFolderExtractor.java can create directories outside the intended extraction root when processing a crafted archive entry. LocalFolderExtractor.createFile() validates only the final canonical file path, while LocalFolderExtractor.makeFile() creates intermediate path segments with unchecked mkdir() calls. An entry can therefore make the final path resolve inside the destination while causing intermediate directory creation outside it, enabling filesystem pollution or file-versus-directory squatting that can make later security-sensitive writes fail. The demonstrated impact is directory creation, not unconditional arbitrary file-content write. This issue is fixed in version 7.6.1.

Skipper, an HTTP router and reverse proxy for service composition, contains an authorization flaw in its opaAuthorizeRequestWithBody filter: when a request body exceeds maxBodyBytes it is truncated before being sent to Open Policy Agent, but the input.truncated_body signal passed to OPA is derived from Content-Length rather than the actual bytes read. An attacker can trigger this by sending an HTTP/1.1 request with Transfer-Encoding: chunked or an HTTP/2 request without a Content-Length header, since skipperadapter.go copies the request headers without updating Content-Length to reflect the truncation. A body-inspecting OPA policy that follows the prior CVE-2026-50197 mitigation and permits requests with truncated_body equal to false will evaluate only the truncated prefix, allow the request, and Skipper then forwards the full oversized body to the protected upstream. An attacker gains a bypass of body-content-based authorization, letting unvetted oversized payloads reach backend services (integrity impact, no confidentiality or availability loss per the CVSS score). Any Skipper deployment before 0.27.37 using the OPA authorization filter with body truncation is affected; no public proof-of-concept or known exploitation exists, and the flaw is fixed in version 0.27.37.

Do: Upgrade to Skipper 0.27.37 or later, which fixes the truncated_body signal handling. As an interim mitigation, update OPA policies to deny requests using Transfer-Encoding: chunked or lacking Content-Length when the opaAuthorizeRequestWithBody filter inspects bodies, or enforce a hard body-size limit so oversized requests are rejected rather than truncated. Operators who relied on the CVE-2026-50197 mitigation (permitting only truncated_body == false) should audit those policies for requests without Content-Length.

CoreDNS's DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners (in plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go) unpack requests without applying dns.DefaultMsgAcceptFunc, the screening policy that the UDP, TCP, and DNS-over-TLS listeners enforce. As a result, an unauthenticated remote client can submit an RFC 2136 dynamic UPDATE over DoH/DoH3/DoQ/DoG, which the proxy or forward plugin relays unchanged to an update-capable upstream. If that upstream trusts CoreDNS's source address or connection and does not require an attacker-unknown end-to-end TSIG, the attacker can add, replace, or delete DNS records to redirect traffic, take over names, alter mail routing, or corrupt a writable zone. Any CoreDNS deployment prior to 1.14.7 that exposes these listeners and forwards to dynamic-update-capable upstreams is affected, a notable population since CoreDNS is the default DNS server in Kubernetes. No exploitation has been reported (not in CISA KEV, no public PoC), and a fix ships in CoreDNS 1.14.7.

Do: Upgrade to CoreDNS 1.14.7. Until then, do not expose DoH/DoH3/DoQ/DoG listeners to untrusted networks, and require end-to-end TSIG on any upstream zone accepting RFC 2136 updates instead of trusting CoreDNS's source address. Audit Corefiles for doh://, quic:// (h3), and grpc:// server blocks and verify whether their forward/proxy upstreams accept dynamic DNS UPDATEs.

HAPI FHIR before version 6.9.12 contains an infinite-loop flaw in SHCParser (org.hl7.fhir.r5), which decompresses Smart Health Card JWTs: when the JWT header specifies zip: "DEF" and the raw DEFLATE payload is empty or truncated, java.util.zip.Inflater can report zero bytes inflated while never reaching a finished or needsInput-consuming state that ends the loop, and the loop also omits a needsDictionary() termination check; the same zero-progress pattern exists in SHCParser.decompress(). The SHC parsing path is reachable from ResourceChecker.java during file-format detection and from validation of Smart Health Cards, so a single unauthenticated, malformed validation request can pin one JVM worker thread indefinitely. An attacker sending multiple concurrent malformed requests can exhaust all validation worker threads, causing a full denial of service on the FHIR server (CVSS availability impact high, no confidentiality or integrity impact). Any deployment of HAPI FHIR prior to 6.9.12 that exposes validation or content-detection endpoints handling attacker-supplied payloads is affected. No public proof-of-concept is known and the flaw is not listed in CISA KEV, so exploitation is not currently confirmed in the wild.

Do: Upgrade HAPI FHIR to version 6.9.12 or later, which fixes the loop termination conditions in SHCParser. If upgrading is not immediately possible, restrict or rate-limit access to FHIR $validate and any endpoints that accept arbitrary content for format detection, and block or closely monitor requests containing Smart Health Card JWTs with DEFLATE-compressed payloads. Check exposed instances for signs of validation-worker thread exhaustion (hung worker threads, stalled validation requests).

Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. Prior to 5.9.2, devalue.parse does not reject out-of-bounds indices that are greater than or equal to values.length in src/parse.js. A specially crafted untrusted payload can make the parser alternate between array representations, producing quadratic work as the payload grows and causing denial of service in applications that parse untrusted devalue data. This issue is fixed in version 5.9.2.

CVE-2026-79298 is a local arbitrary code execution vulnerability in Howyar Technologies' SysReturn system recovery software, affecting versions prior to 11.3.0.34. The flaw lies in the UEFI boot component BOOTia32.efi, which a local attacker can abuse by placing a crafted cloak32.dat file on the EFI System Partition (ESP); on the next boot, the loader processes this file and executes attacker-controlled code. Because execution occurs through the EFI boot component, an attacker who already has local access (physical or via malware with sufficient disk access) can gain code execution in the pre-boot environment, a strong position for privilege escalation and stealthy, persistent compromise. Any machine running an affected SysReturn version, typically PCs and recovery/kiosk deployments bundled with Howyar's restore solution, is affected. There is no evidence of in-the-wild exploitation and the flaw is not in CISA's KEV, but a public proof-of-concept is available on GitHub.

Do: Upgrade SysReturn to version 11.3.0.34 or later on all managed machines. Restrict write access to the EFI System Partition where possible and audit endpoints for unexpected or modified BOOTia32.efi and cloak32.dat files, since a planted cloak32.dat is the exploit vector. Because exploitation requires local access, maintain endpoint hardening, malware defense, and physical access controls on affected systems.

oRPC is an tool that helps build APIs that are end-to-end type-safe and adhere to OpenAPI standards. Prior to 1.14.8, the @orpc/server CORS plugin in packages/server/src/plugins/cors.ts copies a client's incoming Vary request header into the response instead of controlling Vary as a response-only header and using Origin for request-origin variation. In deployments behind a shared cache, CDN, or reverse proxy that keys responses using Vary, a client can inject arbitrary variation values, pollute cache keys, and cause inconsistent CORS enforcement for other clients. Default non-cached configurations have no established direct confidentiality, integrity, or availability impact. This issue is fixed in version 1.14.8.

The RabbitMQ Java client library (amqp-client) before 5.34.0 fails to enforce the configured maxInboundMessageBodySize cap when the AMQP frame_max negotiated during Connection.Tune is zero (unlimited), which is also the client default, because zero is later interpreted as Integer.MAX_VALUE (CWE-770, allocation of resources without limits). A malicious AMQP server, or a man-in-the-middle able to alter Connection.Tune and inject frames into the connection, can send oversized frames of any type, which Frame.readFrom() allocates into memory before any content-level validation. This allows the attacker to exhaust heap memory and terminate the client JVM process, yielding a high-availability-impact denial of service with no confidentiality or integrity impact (CVSS 4.0 8.7). Any Java or JVM application using the vulnerable client against untrusted AMQP endpoints, or over connections not protected by TLS, is affected, while clients talking to legitimate RabbitMQ brokers over TLS are largely not exposed. There is currently no sign of exploitation: the flaw is not in CISA KEV and no public proof-of-concept is known.

Do: Upgrade amqp-client to 5.34.0 or later and audit dependency trees (e.g., mvn dependency:tree | grep amqp-client) since it is commonly a transitive dependency of spring-boot-starter-amqp. Until patched, connect only to trusted AMQP servers and enforce TLS, which eliminates the man-in-the-middle attack path. Treat unexplained memory-exhaustion crashes in client applications as a possible exploitation indicator.

Mattermost Desktop App versions <=6.2 6.2.2.0 Fixed an issue where Mattermost Desktop did not sufficiently restrict server-rendered content from accessing local or private network resources. Thanks to game0v3r for contributing to this improvement under the Mattermost responsible disclosure policy. Mattermost Advisory ID: MMSA-2026-00698

Arista EOS switches running IGMP snooping (enabled by default on all VLANs) contain an out-of-bounds read flaw (CWE-125) in the IGMP snooping agent. A network-adjacent, unauthenticated attacker can trigger it by sending malformed packets onto an affected VLAN, causing the snooping agent to terminate unexpectedly. The impact is availability-focused: while the agent is down, multicast traffic management is disrupted and multicast traffic may be flooded to all ports of the affected VLAN, and repeated exploitation can prolong the loss of intended multicast forwarding. Any environment running Arista EOS where untrusted devices share a VLAN with multicast traffic is affected, notably data center, campus, and multi-tenant networks. As of now there is no evidence of exploitation in the wild, no known public proof-of-concept, and the issue is not listed in CISA's KEV catalog.

Do: Check Arista's security advisory (assigned by [email protected]) for the fixed EOS release for your train and upgrade, since no fixed version can be confirmed from the available data. Until then, restrict untrusted layer-2 access to VLANs with IGMP snooping enabled (e.g., port security, ACLs, limiting guest/tenant access), and monitor device logs for unexpected IGMP snooping agent restarts as an indicator of attempted exploitation.

Arista EOS switches running with the gRPC Network Packet Sampling Interface (gNPSI) enabled contain a code-injection flaw (CWE-94) that lets an unauthenticated remote gNPSI client execute arbitrary code by sending a crafted request. Exploitation depends on certain circumstances being met (reflected in the CVSS 4.0 Attack Requirements metric), notably that the gNPSI service is enabled and reachable on the affected platform. A successful attacker gains full administrative control over the compromised switch. Only deployments of Arista EOS with gNPSI enabled are affected; the issue was assigned by Arista's own PSIRT and carries a critical 9.2 CVSS 4.0 score. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation has been reported.

Do: Audit EOS devices for gNPSI; if it is not required, disable it, and where it is required restrict the gRPC endpoint with management ACLs so only trusted hosts can reach it. No fixed EOS version is listed in the source data — monitor the Arista PSIRT advisory for patched releases and upgrade as soon as one is available. Verify that the gNPSI/gRPC listener is not exposed on untrusted or internet-facing networks as an interim mitigation.

On affected platforms running Arista EOS with VRRPv2 IP-AH authentication configured, an unauthenticated attacker within the same layer 2 network segment on which VRRP is running can capture a legitimate authenticated VRRP advertisement and replay it indefinitely. Replayed advertisements can be used to advertise stale VRRP state, for example to prevent a backup router from taking over the virtual gateway after the original master has gone down, resulting in a denial of service for hosts using the virtual gateway address.

On affected platforms running Arista EOS with VRRP enabled, the peer device VRRP authentication credentials are logged in cleartext on the switch, allowing an authenticated user with sufficient privileges to view agent trace logs (or a system receiving forwarded log output) to obtain the peer device VRRP authentication credentials without having access to the network segment on which VRRP is running.

Apache MyFaces Core, the Apache implementation of JavaServer Faces (JSF) used by Java web applications, contains a Server-Side Request Forgery flaw (CWE-918) that can also lead to Local File Inclusion. An attacker can trigger it by sending a crafted request to an application running a vulnerable MyFaces Core version, causing the server to issue requests to attacker-chosen URLs and/or read local files. Depending on the hosting environment, this could expose internal services, cloud metadata endpoints, configuration files, or credentials. Any JSF-based application running MyFaces Core before the patched releases is affected, and older unsupported versions may also be vulnerable. No public proof-of-concept is known, the issue is not in CISA KEV, and no exploitation has been reported to date.

Do: Upgrade MyFaces Core to 2.3.12, 2.3-next-M9, 3.0.4, 4.0.4, or 4.1.4 depending on the release branch in use, and check build manifests for the org.apache.myfaces.core artifact to identify vulnerable applications. Audit internet-facing .jsf/.xhtml endpoints, and as interim mitigation restrict the application server's outbound network access and file-read permissions. Applications on older unsupported MyFaces versions should be migrated to a supported patched branch.

Redocly CLI and @redocly/respect-core before version 2.33.0 dynamically evaluate $faker runtime expressions embedded in Arazzo descriptions when the 'respect' command runs, and a crafted expression can traverse constructor, prototype, or __proto__ chains in the context parser (packages/respect-core/src/modules/context-parser/get-value-from-context.ts) to reach the JavaScript Function constructor. An attacker who can supply or modify an Arazzo description that a victim processes — for example a third-party workflow file pulled into a repository or pipeline — gains arbitrary code execution with the privileges of the CLI process, including the ability to run shell commands and read CI secrets. Users who only process trusted, self-authored workflows are not affected. The flaw is code injection (CWE-94, CWE-95) reached via prototype pollution; there is no known public proof-of-concept, it is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Upgrade @redocly/cli and @redocly/respect-core to version 2.33.0 or later (check package.json/lockfiles and CI dependency pins). Until patched, do not run 'respect' against Arazzo descriptions from untrusted sources such as external repositories, pull requests, or downloaded files. Audit CI jobs that invoke these tools for accessible secrets, and rotate any CI secrets exposed to jobs that have processed untrusted descriptions.

Redocly CLI makes OpenAPI validation, linting, and documentation workflows easier. Prior to @redocly/cli 2.33.2, the split command constructs output paths under --outDir from untrusted OpenAPI or AsyncAPI component names and x-codeSamples lang values without verifying that the resolved target remains inside the selected directory. A description containing literal ../ traversal segments in those fields can cause the split command to place or overwrite files outside --outDir. Component data remains constrained to YAML or JSON, and code-sample filenames remain based on the HTTP method, so this is not an unrestricted arbitrary-content file write. This issue is fixed in @redocly/cli version 2.33.2.

Square's Wire library, a protobuf and gRPC runtime for Android, Kotlin, Java, and Swift, does not consistently validate attacker-controlled length fields against the current logical message boundary before advancing cursors, pointers, limits, slices, or allocations (CWE-190, integer overflow/wraparound). In the Kotlin runtime, a positive oversized length in ByteArrayProtoReader32.internalNextLengthDelimited() (reachable via ProtoAdapter.decode(ByteArray) and decode(ByteString)) can wrap pos + length to a negative limit and bypass the existing negative-length check, with similar boundary-crossing, pointer-arithmetic, capacity-reservation, and unrepresentable-size-conversion issues in ProtoReader, ReadBuffer.readVarint(), ReadBuffer.verifyAdditional(count:), packed-repeated and nested-message handling, and ProtoDecoder.decodeSizeDelimited(_:from:). An attacker who can supply malformed protobuf bytes to any affected decode path, typically over the network where apps or services parse untrusted protobuf, can trigger unchecked exceptions, traps, out-of-bounds behavior, or excessive allocation, causing denial of service with no known confidentiality, integrity, or code-execution impact. All applications and services built with Wire versions prior to 6.4.5, or 7.0.0-alpha pre-releases prior to 7.0.0-alpha04, are affected. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation has been reported.

Do: Upgrade Wire to 6.4.5 on the stable line, or to 7.0.0-alpha04 or later on the alpha line. Audit code paths that decode attacker-controlled protobuf bytes — especially ProtoAdapter.decode(ByteArray)/decode(ByteString) and ProtoDecoder.decodeSizeDelimited(_:from:) — and enforce application-level message-size limits or crash handling around decoding. Services that only exchange protobuf with trusted peers face materially lower risk since exploitation requires malformed input to reach these decoders.

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.9, an authenticated LiteLLM Proxy caller with a valid virtual key can place api_base inside the user_config request body to bypass is_request_body_safe, which blocks top-level api_base and base_url but previously did not inspect or reject user_config. Because user_config constructs the outbound router, the nested destination redirects a server-side request to an internal or external host selected by the caller and can expose endpoints the caller cannot otherwise access. This issue is fixed in version 1.83.9.

Suricata versions 8.0.0 through before 8.0.5 contain a deadlock flaw (CWE-833) in the IP defragmentation code that an unauthenticated remote attacker can trigger to hang the engine. The condition occurs when the sensor processes fragmented traffic containing an encapsulated tunnel protocol whose payload is itself fragmented, causing the defragmentation logic to lock up. A successful trigger stalls packet processing, producing a high-availability impact: inline IPS deployments can stop forwarding or inspecting traffic, and monitoring sensors can be blinded. Anyone running an affected Suricata 8.0.x release as an IDS/IPS or NSM engine, including sensors embedded in downstream security products, is affected. No exploitation in the wild, public proof-of-concept, or CISA KEV listing is known; version 8.0.5 contains the fix and no workarounds are available.

Do: Upgrade all Suricata sensors to version 8.0.5 or later; no workarounds exist, so prioritize perimeter and internet-facing sensors that inspect untrusted traffic. Because the flaw deadlocks rather than crashes the engine, monitor for sensors that stop processing packets or appear hung, which may indicate exploitation attempts. Organizations running Suricata inside third-party appliances should apply vendor updates incorporating the 8.0.5 fix.

A Null Pointer Dereference in the mk_sched_event_close function (mk_server/mk_scheduler.c) of Monkey through commit 4fb0c16 allows attackers to cause a Denial of Service (DoS) via sending a crafted HTTP request to the server.

Kubero, a self-hosted PaaS for deploying applications on Kubernetes, fails to enforce authentication on its notifications API endpoints through version 3.1.1 (CWE-306). Any unauthenticated attacker with network access to the Kubero API can call these endpoints directly, with no privileges or user interaction required (CVSS 4.0: 9.3 critical, AV:N/PR:N). An attacker can read stored webhook secrets and service URLs, harvest credentials for connected notification services, register malicious webhooks to intercept pipeline event data, or delete existing webhook configurations to suppress alerting. All deployments running Kubero up to and including 3.1.1 are affected, especially those with the API reachable from untrusted networks. There is currently no known public proof-of-concept, the issue is not listed in CISA's KEV, and exploitation has not been observed in the wild.

Do: Upgrade Kubero to the latest patched release once available (the flaw affects everything through 3.1.1) and restrict network access to the Kubero API/dashboard port via firewall rules, VPN, or an authenticating reverse proxy. Rotate any webhook secrets and service credentials that were configured in Kubero's notification integrations, and audit the notifications configuration for unrecognized webhooks or deleted alerting entries that could indicate compromise.

Quickwit through 0.9.0 is vulnerable to server-side request forgery (CWE-918) because it does not validate the host or scheme of the queue_url parameter used by SQS file sources. An attacker who can reach the create-source API submits a malicious queue_url, causing the Quickwit node to issue requests to arbitrary attacker-chosen internal addresses; the CVSS 4.0 score of 8.7 reflects network exploitation with no privileges or user interaction required. By observing connection response differences (success, failure, timing, error messages), the attacker can scan internal networks and fingerprint internal services, potentially including sensitive targets such as cloud metadata endpoints. Any Quickwit deployment running version 0.9.0 or earlier whose REST API is reachable by untrusted clients is affected, particularly self-hosted clusters exposed beyond trusted networks. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known.

Do: Restrict access to the Quickwit REST API (default port 7280) to trusted networks and enforce authentication, and audit existing sources for queue_url values pointing at unexpected hosts or schemes. Where possible, block Quickwit node egress to cloud metadata services (e.g., 169.254.169.254) and internal RFC1918 ranges. No fixed release beyond 0.9.0 is identified in the available data, so upgrade to a patched version once published and treat the create-source API as untrusted input until then.

Nuclei, the open-source template-based vulnerability scanner from ProjectDiscovery, caches the result of template code-signature verification keyed only on a file's modification time, with no content checksum involved. An attacker with local write access to the templates directory can replace a previously verified template with unsigned malicious content and restore the original modification timestamp, causing the cached 'verified' state to be reused for the tampered file. When a user then runs a scan using that template, Nuclei executes it, giving the attacker arbitrary operating-system command execution with the privileges of the user running the scanner. All users running Nuclei versions prior to 3.11.1 are affected. No public proof-of-concept is known, the issue is not listed in CISA KEV, and there is no confirmed exploitation to date.

Do: Upgrade to Nuclei 3.11.1 or later, which adds content checksums to the signature verification cache. Restrict write permissions on the templates directory, and audit it for templates whose contents do not match their signature or whose modification timestamps appear artificially preserved (e.g., via timestamp-restoring copies or touch). Users who cannot upgrade immediately should re-download templates from the official repository before running scans.

Covenant through version 0.6 registers its CovenantHub SignalR hub without an Authorize attribute, so any unauthenticated caller who can reach the Covenant web interface can invoke CreateHttpListener and receive a signed JWT token. With that token, the attacker authenticates as an operator against the full Covenant API and can access grunts (implants), captured credentials, binaries, tasking events, and the operator roster. Any team running Covenant 0.6 or earlier is affected, especially where the Covenant web/API port is reachable beyond localhost. No public proof-of-concept, KEV listing, or confirmed in-the-wild exploitation is currently known, although the flaw requires no authentication or user interaction and is trivially reachable where the interface is exposed.

Do: Restrict access to the Covenant web/API and SignalR ports to trusted management networks or a VPN, and apply an upstream fix adding the Authorize attribute to CovenantHub as soon as a patched release is available. Organizations that ran Covenant on internet-reachable hosts should assume operator API compromise: rotate the JWT signing key and any credentials stored in the Covenant database, and audit API logs for unauthenticated hub connections or unknown operator activity.

Shuffle through version 2.2.1 contains a cross-tenant privilege escalation flaw (CWE-639, authorization bypass via user-controlled key) in its HandleApiGeneration endpoint. An attacker who holds administrator privileges in one organization can supply arbitrary user IDs belonging to non-administrator users in different organizations; the endpoint fails to verify that the targeted user belongs to the caller's tenant and generates valid API keys for those accounts. This effectively lets a tenant admin reset and read other users' API keys, enabling account takeover across tenant boundaries on a shared instance. Any Shuffle deployment at version 2.2.1 or earlier that hosts multiple organizations is affected; exploitation requires network access to the instance and an organization-admin account. No exploitation has been reported: the flaw is not in CISA KEV and no public proof-of-concept is known.

Do: Upgrade Shuffle to the newest available release and monitor the vendor for a patched version above 2.2.1, since all versions through 2.2.1 are vulnerable. In the interim, keep Shuffle instances off the public internet, minimize the number of organization-admin accounts, and review logs of the HandleApiGeneration endpoint for API-key generation requests referencing user IDs outside the admin's own organization.

IRIS, an open-source incident-response case-management platform, fails through version 2.4.29 to enforce case-level authorization on the comment-listing endpoints for notes, tasks, IOCs, assets, and evidence items (CWE-639, broken object-level authorization). An authenticated user who has legitimate access to any single case can iterate over sequential object identifiers and retrieve comment threads from cases they are not authorized to see, on the same instance. The impact is confidentiality-only (high), but the data exposed can include sensitive investigation details from other clients' or other teams' cases, and the attack requires only a low-privileged account via the network with no user interaction (CVSS 4.0 score 7.1, high). All deployments of IRIS up to and including 2.4.29 are affected, which in practice means self-hosted instances operated by CERTs, CSIRTs, and security teams. No exploitation in the wild, KEV listing, or public proof-of-concept is currently known.

Do: Upgrade to the latest IRIS release (anything beyond 2.4.29, i.e., the first patched build once published) as the primary fix, since no vendor-side mitigation short of patching is described. In the meantime, restrict case membership to vetted staff, limit API access to trusted accounts, and review access logs for authenticated users requesting comment endpoints across many sequential object IDs, which would indicate enumeration. Note that no fix version is confirmed in the available data, so verify the vendor's advisory for the patched release.

Scirius through 3.8.0 contains an arbitrary file write flaw (CWE-22) in its PCAP filestore upload endpoint. An authenticated attacker holding only the default User role can embed path traversal sequences in an uploaded document's _id field, causing the server to escape the intended storage directory. The attacker-controlled JSON content is then written with a .json extension to arbitrary filesystem locations, and the write occurs with root privileges, giving the attacker high integrity and availability impact on the host (CVSS 4.0: 7.2 High, network-vector, low privileges required). Any organization running Scirius 3.8.0 or earlier, typically deployed to manage Suricata rulesets in SELKS or Stamus NSM environments, is affected. No public proof-of-concept is known, the issue is not in CISA KEV, and no exploitation has been reported to date.

Do: Upgrade Scirius to a release newer than 3.8.0 as soon as a patched version is available from Stamus Networks. Until then, restrict User-role accounts in the Scirius UI to trusted operators, keep the console off the public internet, and audit the filesystem for unexpected .json files outside the PCAP filestore directory (especially in cron, systemd, or application config paths) to detect potential abuse.

A vulnerability has been found in Open5GS up to 2.8.0. Affected by this issue is the function smf_n4_handle_session_report_request of the file src/smf/n4-handler.c of the component PFCP Session Report Request Handler. The manipulation leads to reachable assertion. The attack may be initiated remotely. The identifier of the patch is e5f0c06d0f2d9613b003daa1cfa3ba8a4bd157e9. It is suggested to install a patch to address this issue.

A flaw has been found in Artifex MuPDF up to b6d17493700c621c0e70036980a6ebd06d2202c9. Affected by this vulnerability is the function pdf_open_filter of the file pdf-stream.c of the component PDF Xref Loading. Executing a manipulation can lead to null pointer dereference. The attack can be launched remotely. The exploit has been published and may be used. This patch is called 3df1e30f9d7b77260e13bd0dbe1928ddeba8386e. Applying a patch is advised to resolve this issue.

A vulnerability was detected in SourceCodester Inventory and Monitoring System 1.0. The impacted element is an unknown function of the file /admins/assessments/databank/btn_functions.php?action=add. Performing a manipulation of the argument difficulty_id results in sql injection. Remote exploitation of the attack is possible. The exploit is now public and may be used.

kkFileView 5.0.0 through 5.0.2 allows reflected XSS via the /onlinePreview endpoint. The OnlinePreviewController passes the user-controlled page and kkagent request parameters to FreeMarker templates without sanitization, and the templates insert these values into raw JavaScript contexts.

Concrete CMS before 9.5.4 re-authorized OAuth REST API requests from the bearer token alone and did not re-check the state of the account the token had been issued to. The resource server's authorization validator confirmed only that a token existed, had not expired, and had not been explicitly revoked, and deactivating a user did not revoke that user's outstanding tokens. As a result, a deactivated user retained full access to /ccm/api/1.0/* for the remaining lifetime of any token already issued to them. The same gap applied to accounts that had been deleted or locked pending a forced password reset. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.0 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Myq Larson for reporting.

Adobe Experience Manager is affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by a low-privileged attacker to inject malicious scripts into vulnerable form fields. Malicious JavaScript may be executed in a victim's browser when they browse to the page containing the vulnerable field. Scope is changed.