Wazuh: Missing input validation in multiple active response scripts allows argument injection

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.2.0 through 4.14.6, multiple active response scripts pass attacker-influenced alert fields to privileged system commands without validating their format, allowing argument injection into tools that run as root. Five of the eight scripts that handle the srcip field, route-null.c, netsh.c, pf.c, npf.c, and ipfw.c, omit the get_ip_version() check that rejects non-IP input, and disable-account.c passes the dstuser field to passwd/chuser with only a comparison against "root". An attacker who can inject crafted log events, for example via syslog, can supply srcip or dstuser values that, when an active response rule triggers, are passed unvalidated to firewall and account-management commands such as pfctl, npfctl, ipfw, route, netsh, and passwd. This enables injecting additional command arguments, and on Windows the unquoted CreateProcess command-line concatenation in wpopenv() lets a srcip containing spaces add further arguments, while disable-account.c can be abused to lock arbitrary system accounts. This issue is fixed in version 4.14.7.

Wazuh: RBAC permission-effect check in mask_sensitive_config allows low-privilege users to read cluster.key

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.14.0 through 4.14.6, an authenticated low-privilege user can read the cluster secret from the manager configuration because the logic that masks sensitive values is disabled by any update-config RBAC rule, including an explicit deny. The mask_sensitive_config() decorator applies masking only when _has_update_permissions() returns false, but that gate treats a user as able to update the config whenever a  manager:update_config  or  cluster:update_config  rule exists, without ever checking whether the rule's effect is allow or deny. Because a deny rule is stored as a real entry, a read-only account that is hardened by explicitly denying config edits is counted as having update permission, which turns masking off. A single authenticated GET request to the configuration endpoint with  raw=true  then returns the verbatim ossec.conf XML with  cluster.key  in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7.

Wazuh cluster worker file sync allows arbitrary file write under /var/ossec (incomplete fix for CVE-2026-30893)

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.4.0 through 4.14.6, a party holding the cluster key can write, overwrite, or delete arbitrary files under /var/ossec on worker nodes, leading to remote code execution as root. During cluster file synchronization, the non-merged branch of update_master_files_in_worker() moves each staged file to a destination derived only from safe_join(), which confines the path to /var/ossec but never verifies that the file lands in the directory declared by its cluster_item_key. Because the destination check present on the primary node and on the worker's merged branch was not applied, a peer can place files at attacker-chosen locations under /var/ossec, including paths that are executed as root, and the delete branch has the same gap. This is an incomplete fix for CVE-2026-30893, which addressed traversal outside /var/ossec but left this path able to redirect files anywhere within it. This issue is fixed in version 4.14.7.

Wazuh discloses cleartext cluster key to low-privilege API users via GET /cluster/local/config

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.14.0 through 4.14.6, a low-privilege API user can read the cleartext cluster key from a configuration endpoint that fails to redact it. The REST API provides a masking control, mask_sensitive_config, that redacts sensitive fields such as authd.pass and cluster.key from configuration responses for users who lack update-config permission, and every config-read endpoint carries this decorator except GET /cluster/local/config. That endpoint, backed by read_config_wrapper, is gated only by cluster:read and returns the local node's cluster configuration including the cleartext key, whereas its siblings return the same value masked. As a result, any account with the default readonly or cluster_readonly role, which is explicitly denied update-config precisely so it cannot view secrets, receives the real cluster key. Because the cluster key authenticates and encrypts traffic between cluster nodes, disclosing it to an unprivileged account provides the authentication precondition for the cluster-peer remote code execution chains established by prior advisories. This issue is fixed in version 4.14.

Remote Code Execution via Unvalidated Flow ID in Flowise 3.1.2

An issue in Flowise 3.1.2 allows a remote attacker to execute arbitrary code via the /api/v1/prediction/<flowId> endpoint

Flowise before 3.1.4 Cross-Workspace Credential IDOR via node-load-method

Flowise is a low-code platform for building LLM applications. In versions up to and including 3.1.3, the POST /api/v1/node-load-method/:name endpoint is mounted without any route-level permission check and invokes component loadMethods with an attacker-controlled nodeName, loadMethod, inputs, and credential value. The selected credential is resolved by raw Credential.id via getCredentialData() and decrypted without verifying Credential.workspaceId against the caller's active or shared workspace, unlike other credential read paths which are workspace-scoped. As a result, an authenticated low-privilege user (or workspace API key) in one workspace can supply a credential ID owned by another workspace and cause Flowise to act as a confused deputy, performing third-party provider calls with the victim workspace's credential and returning provider metadata to the attacker. Statically identified affected load methods include Google Drive listFiles, Google Sheets listSpreadsheets, and AWS DynamoDB KV Storage listTables. The raw credential secret itself is not returned to the attacker. This issue is fixed in version 3.1.4.

Flowise before 3.1.4 Denial of Service via text-to-speech/abort

Flowise versions before 3.1.4 contain an unauthenticated denial of service vulnerability in the /api/v1/text-to-speech/abort endpoint that accepts user-supplied chatflowId and chatId without ownership verification. Attackers can terminate active chatflow predictions for any user by submitting requests with known chatflow and chat identifiers, causing targeted service disruption.

Microsoft SQL Server Information Disclosure Vulnerability

Buffer over-read in SQL Server allows an authorized attacker to disclose information over a network.

Authenticated Buffer Overflow Vulnerabilities in AOS-CX API Endpoint Leads to Possible Code Execution

Vulnerabilities exist in the authentication module that may improperly process malformed or truncated input. An authenticated remote attacker could exploit these vulnerabilities by providing specially crafted input from a compromised or hostile authentication server. Successful exploitation could result in a Denial-of-Service or potential remote code execution with elevated privileges.

Registry Mode Socket Firewall Fails to Verify TLS Certificates, Allowing Man-in-the-Middle

Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates by default. When the api_ssl_verify and upstream_ssl_verify configuration keys are omitted from socket.yml, the generated configuration sets SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false', and the OpenResty/Lua HTTP client used for outbound requests accepts any certificate, including self-signed and otherwise untrusted certificates, without validating the chain. An attacker positioned to intercept traffic between Socket Firewall and the Socket API or an upstream package registry can present a crafted certificate and modify responses in transit, including substituting malicious package content or altering the allow/block decisions the firewall enforces. Setting api_ssl_verify: true and upstream_ssl_verify: true enables verification; however, in versions before 1.1.334, the generated nginx configuration did not emit lua_ssl_trusted_certificate, and thus verification could not be used successfully without manually patching the generated configuration. Version 2.0.0 changes the default for both settings to true.

Forgejo 13.0.0 through 16.0.4, when "[federation] ENABLED = true" is set, has a spoofing issue that affects identity integrity but does not allow account takeover or content modification. It does not verify that the HTTP Signature on an incoming ActivityPub activity was produced by the key belonging to the actor named in the activity body. The signature verification in routers/api/v1/activitypub/reqsignature.go validates the request signature, but the inbox activity handlers subsequently read the acting identity from the attacker-controlled JSON body without binding it to the verified signing key. Additionally, the signed Digest header is not recomputed against the received request body. A remote attacker who hosts a single valid ActivityPub actor and keypair can therefore submit signature-valid activities attributed to any actor identity they name.

Coder: Workspace agent API insecure redirect handling allowed cross-agent file read and write

Coder allows organizations to provision remote development environments via Terraform. Prior to 2.29.19, 2.32.9, 2.33.10, and 2.34.4, agentConn.apiClient() follows redirects while its custom transport accepts the host from the redirected request URL when the port is the workspace agent HTTP API port 4. An authenticated user who controls a modified workspace agent and knows another online agent's UUID can derive the victim's tailnet address and redirect control-plane requests to that agent. HTTP 301, 302, and 303 redirects can redirect read requests, while HTTP 307 and 308 preserve replayable write and process-start requests. The redirected workspace agent file APIs can read or write files as the victim workspace user, and affected versions exposing the workspace agent process API can execute commands after a redirected file write, crossing workspace and tenant boundaries. This issue is fixed in versions 2.29.19, 2.32.9, 2.33.10, and 2.34.4.

netty-incubator-codec-ohttp: [OHttpServerCodec] Native Direct-Memory Leak on AEAD Decryption Failure Leads to Gateway Denial of Service

netty-incubator-codec-ohttp implements Oblivious HTTP (OHTTP) gateway and client functionality using Netty. Prior to 0.0.23.Final, the OHTTP gateway decryption path in codec-ohttp/src/main/java/io/netty/incubator/codec/ohttp/OHttpRequestResponseContext.java allocates a pooled direct ByteBuf for decrypted plaintext before the AEAD tag is verified. When an invalid tag causes decryptChunk() to throw CryptoException, OHttpRequestResponseContext.decodeChunk() does not release the ByteBuf because the allocation is not guarded by try/finally. Repeated invalid encrypted requests can therefore leak native off-heap memory until the gateway is unable to continue serving requests. This issue is fixed in version 0.0.23.Final.

This CVE ID was assigned in error as a duplicate of CVE-2026-70496, which describes the same vulnerability. Please use CVE-2026-70496 instead.

This CVE ID was assigned in error as a duplicate of CVE-2026-70495, which describes the same vulnerability. Please use CVE-2026-70495 instead.

Authenticated Remote Command Injection in AOS-CX Web-based Management Interface

An authenticated user with low-privileged access could submit crafted input through the web-based management interface to execute arbitrary commands on the underlying operating system.

Microsoft SQL Server Elevation of Privilege Vulnerability

Improper link resolution before file access ('link following') in SQL Server allows an authorized attacker to elevate privileges over a network.

FreeRDP before 3.31.0 Denial of Service via Desktop Dimensions

FreeRDP before 3.31.0 fails to validate client-supplied DesktopWidth and DesktopHeight values during GCC negotiation, allowing remote attackers to crash the server. Attackers can send crafted RDP packets with zero or oversized dimensions to trigger division-by-zero or assertion failures in multifragment update capability calculations, terminating the server process.

OpenBao: Cross-namespace lease revocation/renewal via canonical sys/leases/{revoke,renew} — incomplete fix of CVE-2026-45808

OpenBao is an open source identity-based secrets management system. Prior to 2.5.5, an OpenBao user with access to sys/leases/revoke/:lease_id in one namespace could revoke a lease in another namespace when the foreign lease_id was known, bypassing namespace ACL isolation. The affected lease lookup routing in vault/expiration.go allowed FetchLeaseInfo and loadEntry to resolve cached or stored lease data outside the request namespace, allowing a tenant that intentionally disclosed a lease identifier to have the lease and its underlying credential revoked by another tenant. This issue is fixed in version 2.5.5.

MCP Gateway: Argument injection via OCI image label YAML in Docker MCP Gateway

MCP Gateway allows easy and secure running and deployment of MCP servers. From 0.21.0 until 0.42.2, Docker MCP Gateway YAML-unmarshalled the attacker-controlled io.docker.server.metadata OCI image label into the broad catalog.Server structure for direct docker:// references and catalog snapshot imports in pkg/oci/self_contained.go and pkg/workingset/workingset.go. Runtime-shaping fields including Volumes, User, and ExtraHosts were then appended to the docker run argument vector without an origin allowlist, allowing a malicious image author to request host filesystem or Docker socket mounts and UID 0 execution when a victim selected or pulled the image. This container-creation-time boundary bypass can execute arbitrary code on the host and is not prevented by no-new-privileges because no in-container privilege escalation is required. This issue is fixed in version 0.42.2.