Vulnerabilities

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.

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.

Tesseract OCR versions 5.5.3 and earlier contain a heap out-of-bounds write (CWE-787) in the LSTM recognition path: while earlier hardening added bounds checks to NetworkIO::CopyTimeStepGeneral and NetworkIO::Randomize, the NetworkIO::WriteTimeStepPart and NetworkIO::AddTimeStepPart functions in src/lstm/networkio.cpp remained unchecked. The flaw is triggered when the default LSTM engine processes a specially crafted .traineddata model file: in LSTM::Forward (src/lstm/lstm.cpp) the source_ buffer is sized from the independently deserialized na_ field, but WriteTimeStepPart writes a count driven by ns_ from the CI gate WeightMatrix dim1() value, so a crafted NT_LSTM layer with ns_ much larger than na_ overruns the heap buffer during the first recognition step. An attacker who can get such a model file processed gains heap corruption, causing a crash or potentially controlled memory corruption; CVSS 4.0 rates this 8.6 High with a local attack vector and no privileges or user interaction required. Anyone running Tesseract 5.5.3 or earlier is affected in principle, with practical risk concentrated in applications and pipelines that load third-party or otherwise untrusted .traineddata language models rather than only official trusted ones. No public proof-of-concept or in-the-wild exploitation is known, the flaw is not in CISA KEV, and no fixed release was available at the time of review.

Do: No fixed Tesseract release is available yet, so monitor the project for a patched version and upgrade as soon as one ships. Until then, avoid loading .traineddata files from untrusted or third-party sources on affected builds, verify the provenance and integrity of any externally sourced language models, and consider running OCR of external models in sandboxed, low-privilege workers to limit impact of a crash or heap corruption.

Flowise 3.1.2 contains an improper code generation control flaw (CWE-94, code injection) in its /api/v1/prediction/ API endpoint. A remote, unauthenticated attacker can send a crafted request to this endpoint to execute arbitrary code on the server hosting Flowise, achieving full confidentiality, integrity, and availability impact (CVSS 9.8) under the application's privileges. Only version 3.1.2 is named in the available data; the full range of affected versions and any patched release are not specified. As of the provided data, the issue is not listed in CISA's KEV and no public proof-of-concept or confirmed in-the-wild exploitation is known. The critical rating reflects that the flaw is network-reachable with no privileges or user interaction required.

Do: Inventory Flowise deployments and identify any running version 3.1.2; upgrade to a patched release as soon as the vendor publishes one (no fixed version is named in the current data), and monitor the Flowise GitHub repository for an official advisory. Until patched, restrict access to /api/v1/prediction/ by enforcing authentication, binding the service to internal interfaces, or adding reverse-proxy/firewall rules. Review logs for unexpected or unauthenticated requests to that endpoint as a sign of probing or exploitation.

rclone's `serve s3` command, when configured with an --auth-proxy but without --auth-key, registers any client-chosen access key ID with an empty secret and passes that identifier to the proxy without an independent per-identity credential. An unauthenticated network attacker can send an S3 request signed via SigV4 with an arbitrary access key ID and an empty secret; because both authPairMiddleware and gofakes3 validate against that same empty secret, the signature verifies and the request is accepted. The attacker then reaches whatever backend the auth-proxy script resolves for the chosen identity, with high impact on confidentiality, integrity and availability (CVSS 9.8). Only deployments running rclone prior to 1.75.1 with `serve s3`, --auth-proxy enabled and no --auth-key are affected; other rclone configurations are not implicated. No public proof-of-concept is known and the issue is not in the CISA KEV catalog, so no confirmed exploitation has been reported.

Do: Upgrade to rclone 1.75.1 or later. If upgrading is not immediately possible, set --auth-key on `serve s3` deployments that use --auth-proxy, or restrict network access to the S3 endpoint to trusted clients. Check serve s3 access logs for successful requests using unexpected or arbitrary access key IDs, which would indicate exploitation attempts.

Open WebUI versions 0.6.41 until 0.11.1 contain an authentication flaw in the user-lookup functions get_user_by_oauth_sub and get_user_by_scim_external_id (backend/open_webui/models/users.py): on SQLite, their JSON 'contains' matching compiles to SQL LIKE substring matching, leaving percent (%) and underscore (_) characters unescaped as LIKE wildcards. An OAuth subject or SCIM external ID containing these wildcard characters can therefore resolve to a different stored identity — potentially an administrator account — and the attacker is issued that account's session, effectively an authentication bypass that grants the privileges of the matched account. Exploitation requires unusual conditions (an attacker-controllable identity value with wildcard characters that collides with another account, e.g. an admin), reflected in the high attack complexity of the 8.1 High CVSS score. Only deployments using the SQLite backend with OAuth or SCIM login are affected; PostgreSQL deployments are not. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation exists as of this analysis.

Do: Upgrade to Open WebUI 0.11.1 or later, which escapes the wildcard matching. If immediate upgrade is not possible, either migrate the backend to PostgreSQL (not affected) or restrict/disable OAuth and SCIM logins, and check whether any user's OAuth sub or SCIM external ID contains '%' or '_' characters that could collide with other accounts — especially administrators. Review active sessions on privileged accounts for logins you cannot attribute.