Vulnerabilities

A logic error in the cellular modem component causes an improper authorization check (CWE-285/CWE-693), allowing a permission bypass. An attacker who already has low privileges and is on an adjacent network (proximal, e.g., a hostile local or cellular-adjacent network) can trigger the flaw without any user interaction, and successful exploitation yields remote escalation of privilege with high impact on confidentiality, integrity, and availability (CVSS 3.1 base score 8.0). The flaw was assigned through Google's device security CNA ([email protected]), consistent with modem firmware shipped in Google Pixel-class devices; specific affected firmware versions were not provided in the source data. No public proof-of-concept is known, the issue is not listed in CISA's KEV catalog, and there is no evidence of exploitation in the wild. Defenders should treat this as a patch-on-next-bulletin item unless devices operate in high-risk adjacent-network environments.

Do: Install the latest Google monthly security update that includes the cellular modem firmware patch and verify the device's security patch level reflects it. Because exploitation requires network adjacency plus some existing privilege, prioritize devices used in high-risk or shared-network settings and watch for indicators of rogue femtocell/base-station or hostile local-network activity. With no public PoC or KEV listing, standard monthly patch cadence is reasonable outside those high-risk scenarios.

Cisco AsyncOS Software for Cisco Secure Email Gateway contains a SQL injection flaw (CWE-89) in its email parsing logic, caused by insufficient validation of message content. An unauthenticated, remote attacker can trigger it simply by sending a crafted email containing malicious SQL statements through an affected gateway, with no user interaction required. Successful exploitation allows arbitrary SQL execution that escalates to arbitrary operating-system command execution with root privileges, fully compromising the appliance and all mail flowing through it. Any organization running an affected version of Cisco Secure Email Gateway is impacted, and because these appliances sit on the inbound mail path they are inherently reachable over the network. There is no known public proof-of-concept, the flaw is not on the CISA KEV list, and no in-the-wild exploitation has been reported to date, though the CVSS 9.8 rating makes patching urgent.

Do: Upgrade to the fixed AsyncOS release listed in the corresponding Cisco PSIRT advisory as soon as possible, since the flaw is unauthenticated, requires no user interaction, and yields root. Until patched, apply any Cisco-documented workarounds and tightly restrict which hosts can submit mail to the gateway where operationally feasible. Review mail and system logs on these appliances for anomalies such as SQL errors in parsing, unexpected processes, or unexplained outbound connections that could indicate exploitation attempts.

FlowiseAI Flowise up to version 3.0.2 contains a server-side request forgery (SSRF) flaw in the Evaluations Endpoint, specifically in the axios.post call within packages/server/src/controllers/evaluations/index.ts. A remote attacker who manipulates the Host or X-Forwarded-Proto headers can trick the server into issuing requests toward attacker-influenced destinations, potentially reaching internal services, cloud metadata endpoints, or other network resources reachable from the Flowise host. The CVSS 4.0 vector indicates low privileges are required (PR:L), so an attacker needs at least limited authenticated access to the Flowise instance, and overall impact is rated low (2.1). Only Flowise versions that are no longer supported by the maintainer are affected, and a public exploit reference exists as a GitHub issue on the Flowise repository. EPSS is very low (0.2%, 12th percentile), the issue is not in the CISA KEV catalog, and no active exploitation in the wild has been reported.

Do: Upgrade Flowise to version 3.1.3 or later, which contains the patch (commit 700137738bcaebefd4709021f6d6b0abcd7df0ac); since affected versions are unsupported, running them long-term is not viable. If upgrading is delayed, restrict access to the evaluations endpoint to trusted authenticated users, avoid blindly trusting Host/X-Forwarded-Proto headers from untrusted proxies, and egress-filter the Flowise server so it cannot reach internal services or metadata endpoints. Review server logs for unexpected outbound requests originating from the evaluations controller as evidence of exploitation attempts.

Flowise versions before 3.1.4 contain a missing-authorization flaw (CWE-862) in the /api/v1/text-to-speech/abort endpoint, which accepts user-supplied chatflowId and chatId values without verifying that the requester owns the session. An unauthenticated remote attacker who knows or guesses valid identifiers can submit abort requests that terminate other users' active chatflow predictions, causing targeted service disruption. The impact is limited to availability of individual chat sessions (CVSS 4.0: 6.3, medium) with no confidentiality or integrity impact. Anyone running a self-hosted Flowise instance on a version prior to 3.1.4, especially one exposed to untrusted networks, is affected. Exploitation status: a public advisory/PoC reference exists, EPSS is very low (0.2%, 16th percentile), and the flaw is not in the CISA KEV catalog, so no in-the-wild exploitation is known.

Do: Upgrade Flowise to version 3.1.4 or later, where ownership verification for the abort endpoint is enforced. If immediate patching is not possible, place Flowise behind an authenticating reverse proxy or restrict network access so unauthenticated callers cannot reach /api/v1/text-to-speech/abort. Review application logs for abort requests referencing chatflowId/chatId values not associated with legitimate sessions as an indicator of abuse.

Inclusion of functionality from an untrusted control sphere in the Kiro Powers feature in Amazon Kiro IDE before version 0.8.135 might allow remote unauthenticated actors to obtain sensitive information from a developer workstation. Crafted repository content can cause the agent to modify the workspace settings file, which redirects the Kiro Powers registry request to an actor controlled endpoint and sends workspace data to that endpoint when the Powers panel is opened. To remediate this issue, users should upgrade to Kiro IDE version 0.8.135 or later. Users who opened a project in an earlier version should also rotate any credentials that were present in that project.

Concrete CMS 9 through 9.5.2 is vulnerable to Server-Side Template Injection (SSTI) in Theme Customizer via Unvalidated Style Values. Values submitted through the customizer (color channels and other style properties handled by ColorStyle and sibling Style classes such as FontFamilyStyle and ImageStyle) are interpolated into server-compiled LESS source without neutralization of LESS syntax, allowing a user with the Theme Customization permission to inject arbitrary LESS directives. By injecting the @import (inline) directive, an attacker can read arbitrary files on the server and reach internal network resources through PHP stream wrappers. The compiled output, including any disclosed file contents, is written to the site's publicly served CSS cache, exposing database credentials, private keys, and other application secrets, and enabling server-side request forgery. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.9 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.

Improper restriction of XML external entity references in the RemoteQueryCachePlugin in AWS Advanced JDBC Wrapper 3.3.0 through 4.2.0 might allow an actor with write access to the shared cache infrastructure to disclose sensitive files from application hosts that read cached query results, including stored database and IAM role credentials, via crafted XML data in a cached column value. To remediate this issue, users should upgrade to version 4.3.0 or later.

strongSwan's libcharon, the component implementing IKEv2/IPsec key negotiation in the charon daemon, contains a use-after-free (CWE-416) in its handling of IKEv2 rekeying collisions, affecting versions 6.0.0 through 6.0.7. The flaw is triggered when two peers simultaneously initiate rekeying of the same security association and the daemon frees an object that the colliding rekey transaction still references; because the CVSS vector scores network attack complexity as high with low privileges required, an attacker needs to be a valid (authenticated) IKEv2 peer and hit a timing-dependent race condition. Successful exploitation can crash the VPN daemon, and the high confidentiality/integrity/availability impacts in the score indicate memory corruption that could potentially extend to code execution in the context of the daemon. Anyone running strongSwan 6.0.0 through 6.0.7 as an IKEv2 responder or initiator — including VPN gateways, site-to-site tunnel endpoints, and appliances or distributions that bundle the 6.0.x series — is affected. No public proof-of-concept, in-the-wild exploitation, or CISA KEV listing is known at the time of this analysis.

Do: Upgrade strongSwan to a release newer than 6.0.7 once the fix is published — check the upstream release notes or security advisories for the patched 6.0.x version, as the affected range ends at 6.0.7. Until then, restrict IKEv2 access (UDP 500/4500) to trusted, authenticated peers via firewall rules or peer allowlists, and monitor VPN gateways for unexpected charon daemon crashes or restarts. Because exploitation requires valid IKEv2 credentials and a hard-to-hit race condition (AC:H), exposure to unauthenticated attackers is limited, but authenticated VPN peers should be treated as potential sources of malicious rekey traffic.

IBM Langflow OSS versions 1.0.0 through 1.11.5 contain a code injection flaw (CWE-94) that occurs during graph construction, the process by which Langflow builds executable AI/agent workflow graphs. Because the CVSS 3.1 vector is network-exploitable with low complexity, no privileges, and no user interaction, a remote attacker who can reach the service can inject and execute arbitrary code on the underlying server without authenticating. Successful exploitation gives full control of the host — confidentiality, integrity, and availability are all rated high impact — and typically exposes any API keys, model credentials, or data configured in Langflow flows. All organizations running self-hosted IBM Langflow OSS in the affected range are at risk, especially instances exposed to the internet. As of now there is no known public proof of concept, no confirmed in-the-wild exploitation, and the flaw is not on the CISA KEV list, though the severity makes pre-patching attention warranted.

Do: Upgrade IBM Langflow OSS to a release newer than 1.11.5 as soon as a fixed version is available from IBM. If patching must wait, remove the instance from internet exposure (place behind a VPN or authenticated reverse proxy) since exploitation requires no credentials or user interaction. Review logs for unauthenticated requests to graph-construction/flow endpoints and for unexpected Python process or outbound network activity originating from the Langflow server.

Suricata versions 8.0.0 through before 8.0.5 contain a flaw (CWE-693 protection mechanism failure, CWE-787 out-of-bounds write) in which a Lua detection rule that registers too many flow variables corrupts Lua detection state and can allow bypass of Suricata's restricted Lua sandbox. The condition only arises when an affected Lua script/rule is loaded, and the excessive flow-variable registration — potentially driven by traffic matching such rules — can also crash the Suricata engine. An attacker who triggers the condition gains a bypass of the Lua sandbox's restrictions, scored as a high integrity impact (no confidentiality impact per the CVSS vector), with crash-related availability risk as a secondary effect. Only deployments running Suricata 8.0.0–8.0.4 with Lua rules enabled are affected; users of other versions or without Lua rules are not exposed. There is currently no known exploitation, no public proof-of-concept, and the issue is not listed in CISA KEV; the fix is available in Suricata 8.0.5.

Do: Upgrade Suricata to version 8.0.5, which contains the fix. Where upgrading is not immediately possible, disable 'security.lua.allow-rules' unless Lua rules are required, and audit any loaded Lua rules for excessive flow-variable registration while monitoring for crashes or unexpected Lua state behavior.

Improper neutralization of special elements in data query logic in the GridFS component of the MongoDB C Driver can cause a caller-supplied structured file identifier to be interpreted as a query condition rather than as a literal identifier. An authenticated user who can influence the identifier passed by an affected application may obtain stored file content beyond the intended target or cause all GridFS file chunks in the affected bucket to be removed, rendering stored file content unreadable.

Improper neutralization of special elements in data query logic in the GridFS component of the MongoDB C++ Driver can cause a caller-supplied structured file identifier to be interpreted as a query condition rather than as a literal identifier. An authenticated user who can influence the identifier passed by an affected application may obtain stored file content beyond the intended target or cause all GridFS file chunks in the affected bucket to be removed, rendering stored file content unreadable.

CVE-2026-88032 is a use-after-free (CWE-416) in the reactive client-side encryption component of the MongoDB Java Driver, in which native resources can be freed while a still-running encrypted operation is using them. The issue is reachable only when the application uses a reactive encryption configuration that retrieves KMS credentials on demand, and it is triggered when an attacker or component able to cause such an in-flight encrypted operation to be cancelled does so. The result is an availability-only impact: the hosting application process can terminate, with no confidentiality or integrity loss (CVSS 4.0 vector shows VA:H with VC:N/VI:N, scored 8.2 High). Affected parties are JVM application developers embedding the MongoDB Java Driver with reactive streams plus client-side encryption and on-demand KMS credential retrieval; MongoDB deployments that do not use client-side encryption, or that use the sync/standard async drivers, are not affected. 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: Audit JVM applications for use of the MongoDB Java Driver's reactive streams API with client-side encryption configured to fetch KMS credentials on demand; if present, upgrade to the fixed driver version identified in MongoDB's security advisory (version numbers not provided in the available data). Until patched, limit which callers can cancel in-flight encrypted operations, and monitor MongoDB's advisory for version and mitigation details.

Tesseract OCR 5.5.3 and earlier fails to validate counts read from the legacy INTTEMP component of .traineddata files: Classify::ReadIntTemplates uses NumClassPruners, NumClasses, and NumProtoSets as loop bounds without capping them against their maximums, and writes heap pointers past the fixed-capacity ClassPruners and ProtoSets arrays. An attacker who can supply or replace a .traineddata file consumed by Tesseract triggers this during legacy-classifier initialization, before any OCR output, gaining heap corruption, a crash (denial of service), or potentially controlled corruption. All deployments running Tesseract 5.5.3 or earlier are affected, particularly applications, document pipelines, and services that load traineddata files from untrusted or user-controlled sources. No fixed release is available as of this review, and no public proof-of-concept, KEV listing, or known in-the-wild exploitation exists.

Do: No patched version is available yet, so mitigate by ensuring Tesseract only loads .traineddata files from trusted sources and treat user-supplied traineddata as untrusted input. Deployments using only LSTM-based recognition can check whether their pipelines load legacy INTTEMP components, since the flaw is reached during legacy-classifier initialization. Monitor the tesseract-ocr GitHub repository for a fixed release and upgrade promptly once published.