Go
Monthly
Nil-pointer dereference in kin-openapi 0.136.0 through 0.148.x lets an unauthenticated remote client reliably panic Go applications that run openapi3filter request validation against an OpenAPI 3.1 spec declaring an array schema without an items definition. Three decoder paths are affected: a plain array query parameter, a deepObject query parameter whose object contains an array property, and an application/x-www-form-urlencoded body whose array property appears inside an allOf, anyOf, or oneOf subschema - each passes a nil items schema into urlValuesDecoder.parseArray or buildResObj, which dereferences it. Impact is availability-only (CVSS 7.5, CWE-476), exploitation is conditional on the target application actually exposing such a nil-items array schema on a validated route, and no public exploit code or CISA KEV entry is identified at time of analysis; the vendor fixed the issue in 0.149.0.
Denial of service in kin-openapi before 0.149.0 allows unauthenticated remote attackers to terminate the entire Go process by triggering unbounded recursion during runtime schema validation. When a loaded OpenAPI document contains an allOf, anyOf, or oneOf chain that refers back to an ancestor schema - a circular reference the loader and document validation accept without error - a request or response that reaches that schema causes Schema.visitJSON or openapi3filter.decodeValue to recurse until the goroutine stack is exhausted; the resulting fatal stack overflow cannot be caught with recover and aborts the whole process, including unrelated in-flight requests. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5), driven entirely by availability with no confidentiality or integrity impact; the key limiting factor is that a vulnerable circular schema must already exist in the deployed spec, so default non-circular specs are unaffected. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the issue is fixed in version 0.149.0.
A nil-pointer panic in kin-openapi's openapi3filter validation path can crash any Go service that embeds versions 0.136.0 through 0.142.x and serves an OpenAPI 3.1 document with an array schema that omits the items keyword. Unauthenticated remote clients (CVSS vector PR:N/UI:N) only need to send a single nonempty application/x-www-form-urlencoded or multipart/form-data request to an affected operation - or trigger a matching response on a surface such as a response header - to deterministically panic ValidateRequest or ValidateResponse, producing denial of service with no confidentiality or integrity impact (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 7.5). The risk is real but bounded: only OpenAPI 3.1 specs containing the specific malformed-but-spec-legal array shape are exposed, JSON request bodies use a different decoder, and OpenAPI 3.0 documents are rejected at validation time. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation.
RA-TLS session binding bypass in Privasys Go before privasys-v0.5.1-go1.26.5 allows remote attackers who already possess a valid enclave TLS private key to relay a genuine attestation quote onto a different TLS connection, causing a relying party to accept an attacker-terminated handshake as an attested enclave connection. The flaw stems from challenge-mode RA-TLS certificates binding quote ReportData to the certificate public key and client nonce but not to the active TLS session (CWE-346). No public exploit code has been identified, and exploitation requires both a stolen enclave TLS private key and a verifier that does not independently bind attestation to the session channel; the vendor has released a fix in privasys-v0.5.1-go1.26.5.
Memory exhaustion in Go's standard-library net/http HTTP/2 server lets a remote attacker send a single crafted request whose "Trailer" header declares an excessive number of fields, causing the server to allocate a disproportionately large Request.Trailer map for the handler. The issue is availability-only (C:N/I:N/A:H), requires no authentication and no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and crucially bypasses the Server.MaxHeaderValueCount and Server.MaxHeaderBytes defenses; HTTP/1 servers are not affected because they do not multiplex many requests over one connection and account for MaxHeaderBytes differently. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV); EPSS is low at 0.23% (12th percentile), and vendor patches are available, so this is a genuine but moderate-priority availability bug rather than an emergency.
Checksum verification bypass in the Go toolchain (cmd/go) versions 1.27.0 before 1.27.2 and before 1.26.9 allows a malicious Go project with a forged golang.org/toolchain go.sum entry, combined with a user-selected attacker-controlled GOMODPROXY, to substitute a tampered toolchain that cmd/go would otherwise reject. Exploitation requires local access and user interaction (CVSS 7.8, AV:L/UI:R) and two attacker-controlled preconditions the victim must opt into: operating inside the crafted project and using the malicious proxy. No public exploit code identified at time of analysis, and EPSS is 0.13% (2nd percentile), indicating low predicted exploitation likelihood.
Resource exhaustion in the Excelize Go library (versions 2.1.0 through 2.11.0) lets a crafted .xlsx workbook drive excessive CPU and memory consumption - up to process OOM - when an application loads the file and later invokes a column-mutating API such as SetColWidth. The root cause is a missing bounds check in flatCols, which iterates from an attacker-controlled column minimum to an attacker-controlled maximum and performs a deep copy plus append for every declared column number instead of clamping to the spreadsheet's 16,384-column limit. Exploitation requires a victim or service to parse the malicious workbook (UI:P) and then perform a column operation on it; no authentication to the library is required (PR:N), no public exploit code has been identified at time of analysis, and no fixed release is available - although an upstream fix exists as a pull request and commit. CVSS 4.0 base score is 7.1 with availability-only impact (VC:N/VI:N/VA:H); the impact is denial of service, not confidentiality or integrity loss.
Denial of service in the Excelize Go spreadsheet library (github.com/xuri/excelize/v2 2.0.0-2.11.0 and github.com/xuri/excelize 1.1.0-1.4.1) lets an unauthenticated remote attacker terminate the calling process by supplying a crafted workbook. The ColumnNameToNumber function converts bijective base-26 column names into int64 without overflow detection, so an over-long name such as VGWQHXLSDVIKWV wraps to zero and is later used as a slice index by checkSheetR0 and xlsxWorksheet.checkRow, producing a negative index panic during worksheet normalization. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5), meaning availability-only impact; there is no evidence of confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis, though the upstream fix commit and PR are public. This is a moderate-severity denial-of-service condition rather than a high-priority emergency, and it is only reachable when an application built on the vulnerable versions parses an untrusted spreadsheet.
Uncontrolled recursion in the Excelize Go library (versions 2.8.1 through 2.11.0) allows a fatal Go stack overflow that aborts the host process when mutually referencing dynamic-array formulas using _xlfn.ANCHORARRAY are evaluated, resulting in a pure availability impact (CVSS:3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Reachability depends entirely on the host application: it is exploitable only when an application feeds attacker-controlled spreadsheet content into CalcCellValue or another formula-evaluating API, while applications that merely read raw cell values are unaffected. No public exploit code has been identified at time of analysis, and although an upstream fix commit exists, no released patched version has been confirmed (the advisory states no fixed version is available as of its review).
Memory exhaustion and runtime panic in the Excelize Go library (versions 2.3.1 through 2.11.0) let unauthenticated remote attackers crash or drive out-of-memory conditions in any service that decrypts attacker-supplied, password-protected OLE compound (CFB) Excel workbooks. The assessed CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) confirms no privileges or user interaction are needed and that impact is confined to availability, with no code execution or data exposure. No vendor-tagged fixed release was available as of this review, though an upstream fix exists as PR #2396 / commit 5f636f9; no public exploit code was identified at time of analysis and there is no KEV listing.
Denial of service in Excelize versions 2.3.1 through 2.11.0 allows unauthenticated remote attackers to terminate the calling Go process by supplying a malformed OLE compound file with a version-valid EncryptionInfo stream to the library's Decrypt function. The decryption dispatch lacks structural and parameter validation, causing nine malformed-input classes to trigger unrecovered Go runtime panics instead of returning documented errors. Exploitation requires the host application to process attacker-supplied encrypted spreadsheets, no fixed version is available as of this review, and no public exploit code has been identified.
Denial of service in Excelize 2.9.0 through 2.11.0 allows a crafted spreadsheet to panic and terminate a Go process that calls File.GetSlicers. When a worksheet contains an extLst element but the independently optional drawing element is absent, GetSlicers dereferences the nil ws.Drawing pointer while resolving the drawing relationship, producing a runtime panic; the CVSS v4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) indicates remote, unauthenticated triggering with high availability impact but no confidentiality, integrity, or scope impact. Exploitation is not confirmed to be occurring in real-world campaigns and no public exploit code has been identified at time of analysis, though the upstream fix commit and pull request are public, which lowers the bar for crafting a malicious XLSX; the independent assessment rates this as a moderate, impact-limited risk because GetSlicers is not part of the default file-open or parse path and any recover() wrapper neutralizes the crash.
Denial of service in the Excelize Go library (versions 2.1.0 through 2.11.0) allows an attacker-controlled spreadsheet to pin a CPU core for an arbitrary duration when a Go application calls File.GetRows or iterates Rows.Next/Rows.Columns on the untrusted file. The bug is an inconsistency in the row-number limit: Rows.Next enforces the TotalRows (1,048,576) cap, but Rows.Columns consumes the 'r' attribute of a crafted <row> element located after an ordinary valid row without that cap, so the iterator walks every missing row number instead of rejecting the workbook. Impact is availability-only (CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), unauthenticated but requiring the application to accept and parse attacker-supplied XLSX files; no public exploit code was identified at time of analysis and no fixed release exists, though an upstream fix is present in PR #2438/commit 01a9ff32. This is a genuine but bounded denial-of-service issue (CWE-770, uncontrolled resource consumption).
Silent argument dropping in Coraza WAF v3 (>= 3.0.0, < 3.8.1) lets unauthenticated remote attackers evade every SecRule that inspects ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES or ARGS_PATH - including the OWASP CRS SQLi, XSS, RCE and LFI families - by padding a request past SecArgumentsLimit (default 1000) so the malicious parameter is discarded before phase 2 evaluation; roughly 10,000 GET parameters yields about a 94% per-request bypass, and the failure is completely silent (no audit-log entry, no transaction flag). The same advisory covers unbounded ARGS_POST growth because Coraza's urlencoded and JSON body processors ignored the argument cap entirely, which is also a per-request memory-exhaustion DoS surface. No public exploit identified at time of analysis and no confirmed active exploitation; vendor-released patch: 3.8.1 (the 3.8.0 fix was incomplete and 3.8.0 remains listed as affected), and the advisory/report is credited to the corazawaf project with AI-assisted analysis disclosed. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L (7.2 High), a CWE-693 protection-mechanism failure whose impact lands on the protected application rather than Coraza itself.
Denial of service in Apache Thrift's Go bindings (versions before 0.25.0) lets unauthenticated remote attackers exhaust memory or CPU by sending highly compressed payloads over a compressed transport, so a tiny request expands into a disproportionately large in-memory buffer (CWE-409 data amplification / decompression bomb). Exploitation is conditional: per the vendor's CVSS 4.0 score the AT:P metric applies, meaning the affected service must actually accept attacker-supplied compressed data (for example a zlib-backed transport carrying untrusted input) - deployments of the Go bindings that do not parse compressed payloads from external sources are not exposed. Impact is availability-only (service crash, hang, or memory exhaustion) with no code execution or data disclosure; no public exploit code and no confirmed active exploitation were identified at time of analysis, and our independent assessment uses a 3.1 vector of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H reflecting that precondition.
OpenSave through 2.4.0 contains a path-validation bypass (CWE-73) in which a paired peer can supply save paths that fall outside the operator's configured save locations, enabling arbitrary file read and write on the target instance via the manifest request handler and sync routes. The CVSS 4.0 base score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H) reflects high confidentiality and integrity impact with no user interaction and low attack complexity, though the attacker must already be a paired peer of the target (authenticated, PR:L), so an unpaired remote party cannot reach the flaw. No public exploit code and no confirmed active exploitation were identified at time of analysis, but a public advisory and the affected source locations are documented, making the issue straightforward to reason about for anyone already inside a peer trust relationship.
Improper verification of the source of ADS discovery responses in Apache PLC4X (CWE-940) allows an attacker on the adjacent network to redirect subsequent connections to an arbitrary host by spoofing a UDP discovery response, potentially exposing ADS route credentials. Affected versions are PLC4Go 0.11.0-<1.0.0, PLC4J ADS/Modbus 0.10.0-<1.0.0, and PLC4J EtherNet/IP 0.11.0-<1.0.0. Exploitation requires the consuming application to invoke the opt-in discovery API and act on discovered items; no public exploit identified at time of analysis. Upgrade to 1.0.0 to fix.
Symbolic-link path resolution flaw in Google MCP Toolbox for Databases 1.2.0 through 1.9.0 lets an authenticated remote attacker who holds tool-execution permissions read or overwrite arbitrary local files outside the directories configured in allowedLocalRoots. The affected tools, cloud-storage-upload-object and cloud-storage-download-object, validate a caller-supplied path lexically before following it, so a symlink planted inside an allowed root that points outside that root is accepted. Exploitation requires valid tool-execution authorization (CVSS PR:L) and a symlink reachable inside an allowed root, so no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); the vendor describes the control as a guardrail that must be layered on top of OS file permissions.
Improper authorization in Ollama's experimental agent-mode Bash tool allows an attacker who can influence model output - for example through prompt injection from untrusted content the agent reads - to smuggle extra shell commands past the user approval prompt. Because the approval logic (x/agent/approval.go in 0.14.0 through 0.31.1) authorizes commands by prefix match without parsing shell syntax, appending a control operator such as ';', '&&', or '||' to an already-approved command causes the trailing command to run with full host privileges, yielding high confidentiality, integrity, and availability impact (CVSS 4.0 base 8.5; independently assessed as CVSS 3.1 AV:L/AC:L/PR:N/UI:R with C:H/I:H/A:H). This is a genuine but conditionally-gated risk rather than a mass-exploitation threat: the attack vector is local, agent mode is an experimental feature that is not enabled by default, and the victim must approve at least one Bash command within the session; no public exploit identified at time of analysis.
Arbitrary code execution on an operator's workstation is achievable through kube-compare when it processes a 'container://' reference path pointing at an untrusted container image, because the tool launches that image's entrypoint instead of only reading data out of a stopped container. Exploitation is locally scoped and gated: per the assessed vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, an unauthenticated (PR:N) attacker must convince the operator to invoke the tool against the malicious reference (UI:R), so the victim's own action is the trigger. This is a genuine but conditionally-gated risk - escalation to full root-mediated impact occurs only where the local Docker daemon runs with elevated privileges - and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis; EPSS data was not supplied. The tool is distributed in Red Hat OpenShift Container Platform 4 and the 'Pen Drive Powered by Red Hat Lightspeed' offering.
Host header injection in Nezha 2.2.3's OAuth2 redirect endpoint (/api/v1/oauth2/{provider}) allows an unauthenticated remote attacker who can control the HTTP Host header on a request reaching the server to make Nezha emit an attacker-chosen redirect_uri to the configured identity provider; a victim induced to start the OAuth2 login/binding flow can then have their authorization code delivered to the attacker's origin, letting the attacker complete the flow and take over the account. The bug is a regression of the GHSA-9rc6-8cjv-rcvx fix and only manifests when the new optional dashboard_host setting is left empty, so the code no longer falls back to install_host; exploitation also requires victim interaction and an identity provider that accepts the forged redirect URI, which is why the independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:R while the vendor-style CVSS 4.0 rating is 9.3. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; no patched release version was published with the advisory, only an upstream fix commit (38824dbc11a63964c5b9296ae4c68e62b34fa04b).
Authorization bypass in Obot before v0.21.1 lets any authenticated user with a known MCP Server ID connect to restricted MCP servers through the /mcp-connect/{id} gateway endpoint, which fails to enforce Access Control Rules and MCP Registry membership. Because the gateway reuses Obot's stored OAuth/API credentials for the upstream server, an attacker in a Basic role or above can invoke that server's tools - reading and writing data in whatever backends those credentials reach - even when administrators explicitly scoped the server to a small group. Independently assessed at CVSS 9.3, this is a genuine high-priority authorization flaw limited to multi-user deployments that register credential-bearing MCP servers and depend on ACRs for isolation; no public exploit code has been identified at time of analysis, and vendor-released patched version 0.21.1 is available.
Server-side request forgery in Obot through v0.22.1 allows an authenticated user holding the Power User, Power User Plus, or Admin role to register a remote MCP server pointing at an arbitrary URL, which Obot then fetches server-side with no destination validation. Because the fetched response is reflected back in Obot's error messages, this is a non-blind SSRF: the attacker can read responses from internal services and, against the cloud metadata endpoint 169.254.169.254, potentially obtain the host's cloud IAM credentials and pivot into the cloud account. Exploitation is role-gated and requires authentication to be enabled with privileged users permitted to register remote MCP servers; there is no public exploit identified at time of analysis, and the issue is fixed in v0.23.0.
OAuth dynamic client registration in Obot through v0.22.1 allows unauthenticated remote attackers to register an OAuth client pointing at an attacker-controlled redirect URI, then harvest an access and refresh token from a logged-in victim who visits a single crafted authorization URL. The minted token carries the victim's full group set and is accepted as a bearer token against any Obot API endpoint the victim can access - not just the requested MCP server - letting the attacker read or modify the victim's resources until the token is revoked. Exploitation is gated by the server running with OBOT_SERVER_ENABLE_AUTHENTICATION=true and by required victim interaction (clicking the link); no public exploit code has been identified at time of analysis. Versions v0.23.0 and later add a consent screen, token scoping to the requesting MCP server, and audience validation.
Host-controlled AML injection in Edgeless Systems' Contrast confidential-computing runtime before 1.18.0 lets an adversary who controls the QEMU host achieve arbitrary code execution inside AMD SEV-SNP guest VMs, including reads and writes to private memory pages that the confidential-computing model is supposed to shield. Only the Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms are affected; Metal-QEMU-TDX is not, because OVMF measures ACPI table contents into RTMR 0 on Intel TDX. The flaw is rated CVSS 8.4 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) via the host-to-guest trust boundary, carries no CISA KEV status and no public exploit code identified at time of analysis, and is fixed in Contrast 1.18.0, which sandboxes the kernel AML interpreter; the underlying BadAML technique is publicly documented in academic and Black Hat EU 2024 research, and the weakness is generic to Confidential Computing deployments that expose the ACPI interface to the host.
Arbitrary writes to the guest root filesystem in Edgeless Systems' Contrast confidential-computing runtime before 1.19.1 allow a malicious process on the untrusted Kubernetes host to achieve full guest takeover. The flaw lives in the Kata agent policies generated by the Contrast CLI: the CopyFile verification does not correctly resolve symlinks (CWE-59), so an attacker who can open a VSOCK connection to the Kata agent can chain CopyFile requests to overwrite security-critical files inside the guest or trick the workload into disclosing sensitive data. The vendor (via VulnCheck) scores this CVSS 4.0 8.6 (High), and an independent assessment concurs that it is a genuine confidentiality-and-integrity break (CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) rather than a high-score paper cut. Exploitation is not reachable over a standard network - the attacker must already hold a foothold on the untrusted host, which is precisely the adversary model Contrast assumes - and no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis.
Remote attestation relay in Edgeless Systems Contrast before 1.16.0 allows an attacker to impersonate a Contrast Coordinator or a Contrast workload and defeat attested TLS (aTLS) identity verification. Contrast accepted any TEE attestation report that verified correctly and matched expected firmware patch levels and software measurements, without binding that attestation to specific, physically-trusted hardware, so a valid report captured from one machine can be replayed to stand in for another. Per the assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), no public exploit code has been identified at time of analysis, and this is not exploitable against a default deployment by a purely remote attacker: it requires a network man-in-the-middle position on the aTLS path plus a genuine TEE machine under the attacker's physical control. The vendor's CVSS 4.0 score of 9.1 (Critical) substantially overstates real-world risk because it does not fully reward the steep compound preconditions this attack requires.
Container image substitution in Edgeless Contrast 1.14.0 through 1.23.0 lets an attacker who can reach the Kata agent API - in Contrast's threat model, a Kubernetes cluster administrator - swap a workload's container image for an exploit payload and thereby break the integrity guarantees of the confidential container. The root cause is a runtime-policy generation bug: a misplaced allow_storage rule introduced by a bad rebase during a Kata Containers update accepts storage entries using the image_guest_pull driver without verifying the image digest. No public exploit code has been identified at time of analysis and EPSS is low at 0.23% (12th percentile), but exploitation is authenticated (CVSS PR:L), non-automatable per SSVC, and gated on the substituted image still satisfying all remaining policy rules; technical impact is rated total.
Coordinator impersonation in Edgeless Systems Contrast (a confidential-computing runtime for Kubernetes) before version 1.4.1 lets an attacker who can redirect traffic to a rogue Coordinator recover arbitrary secrets of workloads deployed after the attack. The recovering Coordinator fails to verify the seed supplied by the recovering party, so a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled can issue certificates chaining to its own root CA, impersonating a workload owner when the `contrast` CLI `set` call does not compare the returned root CA certificate against the existing one (the CLI's default behavior) or when `verify` is run without comparing against a trusted reference. Exploitation is unauthenticated but conditional - it requires a network-position/man-in-the-middle prerequisite plus a victim workload-owner action - so this is a genuine but conditional integrity and confidentiality flaw rather than a widespread emergency; no public exploit is identified at time of analysis and the issue is not in CISA KEV.
Workload secrets managed by Edgeless Systems' Contrast confidential-computing platform are written to Kubernetes pod logs, letting anyone with log-read access recover secrets that are meant to be visible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner. All Contrast releases up to and including 1.8.0 are affected whenever the Contrast initializer runs at the default CONTRAST_LOG_LEVEL of info (the same leak also occurs at debug), so installations that never customized the initializer log level are exposed by default; deployments that do not use workload secrets at all are unaffected. Recovering the leaked value requires low-privileged access - Kubernetes get or list permission on pods/logs (PR:L in the assessed vector) or read access to the underlying Kubernetes log storage - this is a passive confidentiality disclosure with no code execution, and no public exploit has been identified at time of analysis.
Kyverno 1.14.0 through 1.19.0 fail open in a way that lets unsigned or untrusted container images be admitted to a Kubernetes cluster: the ImageValidatingPolicy evaluator silently ignores the spec.images and spec.allowedValues fields of a PolicyException, so any exception whose policyRefs and matchConditions match a resource disables image signature verification for that entire resource rather than only for the named images or values. An authenticated user with Kubernetes API rights sufficient to deploy or modify workloads covered by such an exception (CVSS PR:L) can therefore bypass signature enforcement without obtaining any new privileges - the flaw simply turns a narrow, trust-anchored carve-out into a blanket exemption. No public exploit code identified at time of analysis, and the vendor has released a fix in Kyverno 1.19.1; scope is limited to clusters that actively enforce signature verification through ImageValidatingPolicy and define matching PolicyExceptions.
Case-sensitivity bypass in Hugo's security.http.urls IP-literal deny rule lets builds running v0.162.0 through v0.165.x fetch URLs that the rule was configured to block - a mixed-case scheme such as 'HTTP://localhost/...' evades the deny match, re-enabling SSRF through resources.GetRemote. The issue is unauthenticated (PR:N) but local (AV:L): it only matters when a Hugo build processes attacker-influenced input and the operator depends on the IP-literal deny rule as the SSRF control, and it cannot be triggered against an already-served static site. No public exploit code has been identified and there is no confirmation of active exploitation, but a vendor patch is available in Hugo v0.166.0.
Symlink-following flaws in Hugo's theme and module mount confinement allow files outside a project's mount roots to be read during a site build and, via static mounts, published into the public/ output directory. The flaw affects Hugo builds after v0.123.0 and before v0.166.0 for any project that adopts an untrusted theme checked into themes/ or a vendored (non-Go-modules) module containing a symlink at a mount root and then runs a build; the vendor scores this 8.7 (High) under CVSS 4.0, while independent analysis models it as CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N because the site operator must first adopt the malicious theme and execute the build. No public exploit code identified at time of analysis and no KEV listing; a vendor-released patch exists in v0.166.0.
Account takeover in Wakapi before 2.17.6 is possible because the user caching service resolves lookups in an unintended context, allowing one user's lookup to return another user's cached record; unauthenticated remote attackers can thereby hijack an existing account. The high attack complexity (AC:H) reflects that an attacker must induce or await the specific cache state in which lookups cross contexts, rather than sending a single deterministic request, and no public exploit has been identified at time of analysis. Vendor-released patch: 2.17.6.
Signature-verification bypass in MinIO (all releases through commit 7aac2a2) and in the pgsty/silo fork (before commit 1233254) lets an attacker who holds a valid SigV4 presigned PUT URL - one scoped to a single object - append an unsigned x-amz-copy-source header to the otherwise unmodified URL and cause a server-side CopyObject executed with the signer's credentials, converting a write grant into reads of every object that signing key can reach. The root cause is a CWE-347 improper-verification-of-signature error: extractSignedHeaders() in cmd/signature-v4-utils.go iterates only the client-claimed X-Amz-SignedHeaders list and never enumerates the x-amz-* headers that actually arrived, so an unsigned header is neither hashed into the canonical request nor rejected, while cmd/api-router.go dispatches CopyObject purely on the presence of x-amz-copy-source. Amazon S3 rejects the equivalent request with HTTP 403 AccessDenied; exploitation here requires a delegated presigned URL plus a signing key with broader read permission, making this a privilege escalation from a delegated credential rather than unauthenticated access, with no public exploit code or confirmed active exploitation identified at time of analysis.
SigNoz deployments configured to use the non-default opaque session tokenizer leave existing sessions valid after a password reset or user deletion, so a remote authenticated attacker who already holds a live session token for an account retains that account's full access - up to administrator - for up to the token's configured maximum lifetime (30 days by default) after a reset, and until the token next rotates (30 minutes by default) after deletion. Affected versions run from v0.98.0 up to but not including v0.143.0; default installations in that range never used the opaque tokenizer and are therefore not exposed. The vendor has released v0.143.0 as the fix, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Session token forgery in SigNoz v0.8.0 through v0.142.x allows unauthenticated attackers to impersonate any user, including administrators, when the default JWT tokenizer provider runs without a configured signing secret. The application defaults the JWT HMAC key to an empty string and fails to reject this in Config.Validate(), so tokens are both signed and verified with an empty key; an attacker who knows a target user ID can forge valid access and refresh tokens, and the refresh token can be rotated at /api/v2/sessions/rotate and cannot be revoked. No public exploit identified at time of analysis; deployments that explicitly set a secret or use the opaque provider are not affected, and v0.143.0 eliminates the exposure.
Account takeover in Klever-Go's KleverUpdateAccountPermission built-in (all versions prior to 1.7.20) allows an attacker-controlled smart contract to replace a victim account's entire permission set without any victim key or signature. The handler authorizes updates using the attacker-supplied vmInput.RecipientAddr instead of the authenticated vmInput.CallerAddr, and because the default self-signer created by createDefaultOwnerPermission satisfies the contractHasValidPermission check, a contract can name any permissioned victim as recipient and install attacker-supplied Owner permissions - enabling asset theft or permanent lockout of the victim. The CVSS 4.0 score is 8.7 with a low-privilege vector (PR:L), reflecting that the attacker must be able to deploy or control a contract that can issue an indirect built-in call; accounts without stored permissions and the native transaction path are not affected. Exploitation requires no user interaction, and no public exploit code or confirmed active exploitation was identified at time of analysis; this is nevertheless a genuine high-priority vulnerability given its unauthenticated-from-the-victim's-perspective account takeover impact on a production blockchain.
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk request bodies without JSON escaping, allowing an attacker who can submit a SetAccountName transaction to inject forged bulk actions that create, overwrite, or delete documents in any index the indexer can write to. Because the name is stored in consensus account state, the poisoned value is replayed by new and historical indexers, and no access to the indexing host or the Elasticsearch port is required. Severity is rated 8.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:L; our independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), exploitation requires an authenticated low-privilege on-chain account plus a deployment that actually runs the Elasticsearch indexer, and the issue is fixed in 1.7.20; no public exploit identified at time of analysis, though the upstream fix ships a regression test that reproduces the advisory's injection construction.
Missing BLS public key validation in Klever-Go prior to 1.7.20 allows a remote authenticated party with validator-registration capability (PR:L) to submit a CreateValidatorContract (Register) or ValidatorConfig update (UpdateValidator) containing a malformed BLSPublicKey that the runtime never checks for curve membership, prime-order subgroup, or nonzero value. Impact is delayed and conditional: the malformed-key validator must first become eligible and then be selected into a consensus group, at which point MultiSigner.Reset and the signature-verification creation path fail to deserialize the group key and cancel the slot, causing repeated missed consensus rounds and throughput degradation; a complete halt occurs only when the consensus group equals the eligible validator set. This is an availability-only, conditional risk - no public exploit identified at time of analysis, no KEV listing, and genesis-path validation is unaffected because it already calls CheckPublicKeyValid.
Unauthenticated remote denial of service in Klever-Go (all versions before 1.7.20) allows any client that can reach the node's REST/WebSocket API to exhaust its memory and goroutines through the default-open /subscribe endpoint, and because that API runs in-process with the node, the resulting OOM-kill also takes down P2P and consensus participation. No API key, account, stake, or funds are required (vector PR:N), and publicly available exploit code exists: the vendor advisory ships working PoCs against unmodified production code showing a single 8 MiB WebSocket frame expanding server heap by roughly 32 MiB, 300 concurrent connections accepted despite a configured global cap of 100, and 200,000 attacker-supplied address strings growing the hub's subscription map 1:1 with no cap. The assessed severity is CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and real-world priority is bounded mainly by Klever-Go's limited node footprint rather than by any weakness in the finding itself.
Unauthenticated remote attackers can connect to the /log WebSocket endpoint in Klever-Go and either read live node logs or apply an arbitrary logger profile process-wide, for example setting *:NONE to mute normal slot logs or *:TRACE to flood them. The flaw is a management-plane information exposure (CWE-200) with additional integrity and availability effects, and publicly available exploit code exists because the advisory includes a proof-of-concept reproduction; no CISA KEV active exploitation is indicated. Exploitation requires the REST API to be network-reachable, so nodes that keep the API bound to localhost or an admin-only interface are not remotely exposed, and the vendor-released fix is version 1.7.20.
Improper enforcement of the marketplace settlement workflow in Klever-Go prior to 1.7.20 lets an authenticated seller settle a resting-bid NFT auction through the Claim seller-accept branch while leaving the claimed order loadable with a future EndTime and stale CurrentBid/CurrentBidder values. A later bidder can then submit a higher bid, be debited, and trigger a refund to the previous bidder even though the NFT has already been delivered, while Claim and CancelOrder both reject that bidder because IsClaimed is true - leaving them unable to obtain the NFT or recover their funds. The flaw is purely an integrity/business-logic issue (CWE-841, assessed CVSS:3.1 7.1, AV:N/AC:L/PR:L/UI:N with no confidentiality or availability impact, matching the vendor's 7.1 CVSS 4.0 rating); no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor fix is available in 1.7.20.
Unauthenticated remote attackers can bypass client-certificate trust in Temporal's s2s-proxy 0.1.16 through 0.2.2 by presenting a self-signed certificate and key to a mux or TCP TLS server listener, because the proxy runs Go's RequireAnyClientCert mode whenever skipCAVerification is false and therefore never validates the presented chain against the configured CA. A successful handshake yields a yamux-multiplexed, peer-authenticated channel on which the attacker can call every RPC the proxy's aclPolicy allows, exercising the proxy's own Temporal credentials against the cross-cluster replication API without supplying any trusted certificate, private key, or Temporal credential. No CISA KEV active-exploitation signal is present and no public exploit identified at time of analysis, but the defect carries a 9.3 CVSS 4.0 score and the vendor has published an upstream fix (PR #296 plus associated commits).
Photoview through 2.4.0 contains an authorization bypass in the shareAlbum GraphQL mutation that lets any authenticated low-privileged user generate valid share tokens for albums owned by other users. Because album IDs are sequential integers, an attacker with a normal account can enumerate IDs and create working share links without needing any elevated privileges; distributing the resulting link exposes the victim's photos and sub-albums. Exploitation requires a multi-user deployment and an authenticated session, and no public exploit code has been identified at time of analysis, though the vendor has released an upstream fix.
Timing-based leakage of the single recovery token in OpenBao lets a remote, unauthenticated attacker who can reach the instance while it is running in highly privileged recovery mode recover that token and then read or modify data on the OpenBao instance. The exposure is constrained to the transient recovery-mode break-glass state rather than the normal serving configuration, and exploitation requires collecting a large volume of low-noise timing samples against the recovery endpoint (reflected in the CVSS 4.0 rating of 9.2 with AC:H and AT:P, and in the assessed CVSS 3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). The vendor addressed the flaw in OpenBao v2.6.0; no public exploit identified at time of analysis.
Unauthenticated denial of service in the sipgo SIP library (versions up to and including 1.4.2) lets any remote attacker who can reach a SIP-over-WebSocket (WS or WSS) listener crash or memory-exhaust the server process. WSConnection.Read allocates a buffer directly from the client-declared WebSocket frame length - a value the attacker controls up to 2^63-1 - before MaxFrameSize or the downstream ParseMaxMessageLength check is ever applied, so a single header-only frame with a huge declared length triggers a makeslice panic that terminates the whole process (sipgo does not recover it), or forces an oversized allocation. No authentication, credentials, or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 7.5, CWE-789), a working proof-of-concept frame is documented in the vendor advisory, and the flaw is fixed in 1.4.3; impact is confined to availability, with no confidentiality or integrity effect, and only services that actually enable the WS/WSS transport are exposed.
Memory-exhaustion denial of service in the SIPGO Go library (versions up to and including 1.4.0) lets an unauthenticated remote peer crash or destabilize any SIP service built on it that exposes a stream listener. A single SIP message sent over TCP, TLS, WebSocket, or WebSocket-Secure with an oversized, attacker-declared Content-Length header (up to 2^32-1) causes the stream parser to allocate a body buffer of that size before the library's 65535-byte max-message-length guard is evaluated, exhausting process memory. The flaw is fixed in version 1.4.1, the vendor advisory (GHSA-pg59-5vwg-4jxq) includes a working proof-of-concept, so publicly available exploit code exists; impact is availability-only with no code execution or data disclosure, consistent with the CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
Concurrent upload-session requests in Cloudreve prior to 4.18.0 allow an authenticated user holding Files.Write permission - which the default User group provides - to bypass the per-account storage quota and reserve more space than the account is allowed, ultimately exhausting host disk and denying uploads to other users. The flaw is a time-of-check-to-time-of-use race: PrepareUpload validates capacity against a stale in-memory value while the actual storage charge is applied later and outside the same quota-enforcing transaction, so parallel requests that read the same snapshot all pass the MaxStorage check. Exploitation requires genuinely simultaneous requests and a valid low-privileged account, and impact is limited to availability (no data disclosure or code execution); no public exploit code was identified at time of analysis, and the issue is fixed in 4.18.0.
Horizontal privilege escalation in the x-ui web panel 0.3.2 allows any authenticated panel user to rewrite another user's inbound proxy configuration - remark, port, protocol, settings, enabled state, expiry time and traffic quota - by submitting an inbound-update request that carries the victim's resource identifier, because the update path never verifies that the referenced inbound belongs to the requesting session user (CWE-284). The flaw is network-reachable and requires no victim interaction, with a CVSS 3.1 vector of AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8); an independent assessment retains High severity and confirms the integrity impact (cross-tenant configuration tampering) while narrowing confidentiality and availability to Low, since the tampering is confined to proxy resource data rather than granting panel or host compromise. Exploitation is limited to multi-tenant deployments where more than one account holds inbound resources; no public exploit code has been identified at time of analysis and EPSS is low (0.20%, ~10th percentile), so mass scanning is unlikely, though the flaw is trivially reachable by any legitimate panel account.
Permanent destruction of an entire group's inventory in HomeBox is possible for any authenticated user who belongs to that group, due to a broken authorization check in the wipe-inventory action handler affecting versions prior to 0.26.0. The flaw lets a self-registered user - who is automatically flagged as a global owner of their own group - select a different group via the X-Tenant header and invoke POST /v1/actions/wipe-inventory against it, deleting data that cannot be recovered without external backups. Exploitation requires an authenticated account on a multi-group instance where the attacker is also a legitimate member of the victim group, so single-user or single-group deployments are not affected; no public exploit identified at time of analysis.
Cross-tenant record tampering in HomeBox versions prior to 0.26.0 allows an authenticated low-privileged user to overwrite or permanently delete another group's maintenance entries by supplying a maintenance-entry UUID that belongs to a different tenant. The flaw is a CWE-639 broken object-level authorization (IDOR) in the maintenance-entry update and delete repository paths, which act on the caller-supplied ID without confirming the record belongs to the caller's active group; exploitation requires a valid session plus knowledge of a non-enumerable random UUID, so it is access-gated rather than trivially reachable and is practically limited to multi-group/multi-tenant deployments. Impact is blind write/delete only with no data disclosure, and there is no public exploit identified at time of analysis and no indication of active exploitation. Vendor-released patch: 0.26.0.
HomeBox versions prior to 0.26.0 allow an authenticated low-privilege user to read and overwrite another tenant's notification configuration via PUT /v1/notifiers/{id}, exposing plaintext Shoutrrr credentials (Slack, SMTP, Telegram, Pushover, Discord) that are stored inside the notifier URL. The primary assessed impact is credential disclosure (high confidentiality), with a more limited integrity impact from the ability to point the victim's notifications at an attacker-controlled webhook. Exploitation requires a multi-tenant HomeBox deployment, a valid account, and knowledge of the victim's notifier UUID - UUIDs are not enumerable, which is the main real-world limiting factor; no public exploit has been identified at time of analysis, and the vendor fixed the issue in 0.26.0.
Authenticated command injection in KubeEdge (1.21.0 up to 1.21.2, 1.22.2, and 1.23.1) lets a principal holding Kubernetes RBAC rights to create or modify ConfigUpdateJob resources inject shell metacharacters into the updateFields passed to the keadm config-update command, which the edge taskmanager then runs through a system shell, yielding arbitrary command execution on the enrolled target edge node with the privileges of the KubeEdge process. The vendor rates this 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), and our independent assessment is slightly more severe because compromise of the node process is a scope change (S:C); the PR:L vector confirms the attacker must be authenticated and authorized, so this is not anonymous or remotely unauthenticated abuse. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, but the flaw is a genuine, actionable CWE-78 issue rather than an inflated score, and it is fixed in KubeEdge 1.21.2, 1.22.2, and 1.23.1.
Shell command injection in KubeEdge's v1alpha2 NodeUpgradeJob upgrade workflow allows an authenticated user who holds RBAC permission to create or update NodeUpgradeJob resources to run arbitrary commands on targeted edge nodes with the privileges of the edge upgrade process. Affected deployments are those running KubeEdge 1.12.0 through 1.21.1, 1.22.0/1.22.1, or 1.23.0 that actually process node-upgrade tasks; the vulnerability is high-priority and genuine rather than a CVSS-inflated finding, but it is gated on the NodeUpgradeJob create/update privilege (PR:L, not anonymous) so it is not reachable by unauthenticated users or on clusters that do not grant that permission. No public exploit code and no confirmed active exploitation were identified at time of analysis; EPSS/KEV data were not supplied for this CVE. Vendor-released patches exist in 1.21.2, 1.22.2, and 1.23.1.
KubeEdge keadm releases from 1.16.0 before 1.21.2, 1.22.2, and 1.23.1 contain a path traversal in DecompressTarGz that, on Windows edge nodes, can extract archive entries with parent-directory sequences, backslashes, absolute paths, or drive prefixes outside the intended destination. Exploitation requires the operator to run keadm join or installation using an archive obtained from a compromised, replaced, or untrusted download source, making this primarily a supply-chain trust-boundary bug rather than an attack against official artifacts. No public exploit was identified at time of analysis, and vendor fixes are released in 1.21.2, 1.22.2, and 1.23.1.
Authorization bypass in Tinyauth releases prior to 5.1.2 allows an authenticated, low-privilege user to reach applications whose per-app access controls are configured to exclude them. Tinyauth matches forwarded hostnames case-sensitively in lookupStaticACLs/GetAccessControls and in the Docker-label fallback (GetLabels), while nginx, Traefik, and Caddy route hostnames case-insensitively; requesting the target app with a differently-cased hostname therefore misses the configured policy, returns an empty access-control object, and proxyHandler treats the empty user/group/OAuth/LDAP/IP restrictions as permissive. Exploitation requires valid low-privilege credentials (CVSS PR:L) and a deployment that enforces per-app ACLs behind a case-insensitive proxy; unauthenticated visitors are still stopped at login and global login-time allowlists are not bypassed. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released fix is version 5.1.2.
Account fixation in Hatchet's OAuth callback handling lets an unauthenticated attacker bind a victim's existing Hatchet session to an OAuth identity the attacker controls, achieving login CSRF and account takeover. The flaw affects Hatchet versions prior to 0.91.1 and is only reachable when the deployment has enabled at least one OAuth integration (auth.google.enabled, auth.github.enabled, or the Slack integration) and the victim has already completed an OAuth flow in the current browser session; exploitation still requires victim interaction (the victim's browser must follow the attacker's crafted callback URL containing an empty state parameter and the attacker's own authorization code). The vendor-released patch is version 0.91.1 (upstream commit f90464189ad642251e09412d0f99fde353036428); there is no indication of confirmed active exploitation (no CISA KEV listing) and no public exploit code identified at time of analysis, although the upstream fix ships an integration test that documents the bypass chain.
OpenBao versions prior to 2.6.0 fail to reject syntax-significant characters when templated identity data is substituted into ACL, PKI, and SSH policies, allowing an authenticated principal who can write that identity data to broaden path matching, obtain certificates for unauthorized domains, or add unauthorized SSH principals. Exploitation is gated on a non-default configuration: the policy must use templates that substitute attacker-modifiable identity metadata (for example {{identity.entity.metadata.domains}} or {{identity.entity.metadata.sans}}), and the attacker must already hold the capability to update that identity record (such as update on identity/entity), consistent with the assessed CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N. Deployments whose templates rely solely on the randomly generated identity.entity.id value are not affected, there is no user interaction, and no public exploit code was identified at time of analysis.
Unauthenticated administrator account creation in nginx-ignition affects deployments running versions prior to 2.41.1 that are still in their pre-onboarding state. The endpoint POST /api/users/onboarding/finish is registered as anonymous and, because its "onboarding already completed?" check is not atomic with the subsequent user write, a remote unauthenticated attacker (CVSS 3.1 vector: AV:N/AC:H/PR:N/UI:N, base 8.1) who can reach such an instance can create a full ReadWrite administrator account for themselves, and concurrent requests can create multiple admin accounts in a single race. No public exploit identified at time of analysis, and the practical window is narrow: exploitation requires the instance to be network-reachable while deployed but before a legitimate operator has completed onboarding - once onboarding is legitimately finished, the path is guarded.
Unauthenticated denial of service in nginx-ignition 2.29.0 through 2.40.0 lets any remote client that can reach the management API burn roughly 2.4 seconds of server CPU per request by sending a GET whose Accept-Language header is built from underscore-separated malformed language tags, since the gin i18n middleware parses the raw header unconditionally with no size or shape limit. Impact is availability-only (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): ten concurrent attackers saturate a ten-core host for the duration of the attack while consuming about 10 MiB/s of upstream bandwidth, with no path to data access or code execution. No public exploit code identified at time of analysis and no CISA KEV entry; the vendor-released patch 2.40.1 fixes the issue.
Signature verification bypass in Red Hat's openshift/oc-mirror tool allows an attacker who can intercept or manipulate traffic to the release-signature endpoint to have a forged PGP-signed release payload accepted and mirrored into a disconnected OpenShift 4 registry. The defect (CWE-347) causes oc-mirror to evaluate signature errors before the full signed body has been processed, so a message carrying a legitimate Red Hat release key ID but an invalid signature can pass validation during a normal mirror operation. Exploitation is gated by a demanding precondition: the attacker must already hold a man-in-the-middle/on-path position on the network path and the victim must be actively running an oc-mirror signature-verifying operation; no credentials against oc-mirror are required (PR:N) and no user interaction beyond running the mirror process is needed (UI:N). The realistic impact is integrity-only, since the assessed vector scores C:N/I:H/A:N, and no public exploit has been identified at time of analysis.
Temporal Server releases 1.30.0 and later let an authenticated caller holding write permission in only one namespace trick the server into issuing attacker-chosen, state-changing HTTP POSTs against its own administrative frontend API, enabling cross-namespace workflow termination, namespace registration, configuration tampering, and full namespace deletion. The caller exploits confused-deputy logic (CWE-807) by attaching a Workflow completion callback whose URL passes the configured address allowlist and whose header map contains a non-empty 'source' header, which the History service interprets as evidence the callback is internal; no network access to the internal frontend is required because the server makes the request itself. Releases 1.25.0 through 1.29.7 carry the same defect but require the 'source' header to exactly match a configured cluster-ID UUID that a namespace-scoped caller cannot read through the API, making exploitation materially harder; no public exploit code was identified at time of analysis, and exploitation is gated on non-default deployment settings. Vendor-released patches exist in 1.30.7, 1.31.3, and 1.32.0.
Unauthenticated network peers that can reach a live Ringpop TChannel/SWIM gossip listener can drive memory and gossip-bandwidth exhaustion in github.com/temporalio/ringpop-go, because peer-supplied label maps are retained and re-disseminated without being checked against the application's configured LabelOptions limits. Applications that use ringpop's label feature are affected; repeated membership changes for distinct member addresses carrying oversized label keys, values, or counts inflate the member list and propagate to the whole cluster, degrading and potentially taking down the hosting process (availability only, no confidentiality or integrity impact). Exploitation requires network reachability to the gossip/TChannel port - typically an internal cluster interface - and there is no public exploit identified at time of analysis, though the assessed severity (CVSS 3.1 base 8.7, PR:N, A:H) makes the exposure of that port the decisive risk factor.
Unauthenticated remote denial of service in github.com/temporalio/tchannel-go (the Go implementation of the TChannel RPC protocol) before v1.22.1 lets any network peer that can complete the standard TChannel initialization handshake crash the hosting process. A crafted call fragment that carries checksum metadata but contains no length-prefixed argument chunks leaves the fragment reader's chunk slice empty, and the unconditional selection of the first element triggers an unrecovered Go slice-bounds panic on a library-created dispatch goroutine, terminating the process. There is no confidentiality or integrity impact, exploitation requires network reachability to a TChannel listener exposed to untrusted peers, and no public exploit code was identified at time of analysis (not confirmed actively exploited / not in CISA KEV); the assessed CVSS:3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
Denial of service in Temporal Server stems from uncontrolled recursion (CWE-674) in the bundled temporalio/sqlparser library: SQL containing deeply nested unary expressions is accepted and produces a correspondingly deep abstract syntax tree, and the library's recursive String and Walk traversals then exhaust the Go stack and abort the process in a way that Go panic recovery cannot contain. Affected are Temporal Server deployments prior to v1.30.7 and v1.31.3 that pass caller-controlled query text to the parser through the archival, visibility, and worker-query paths, including validation code that recursively formats an invalid expression while constructing an error. Exploitation requires an authenticated caller holding namespace read permission (the published CVSS 4.0 vector lists PR:N, but the reported prerequisites specify an authenticated caller and the independent assessment scores PR:L), the dynamically confirmed ListWorkers route additionally requires at least one retained worker heartbeat, and repeated requests can sustain the outage; impact is availability-only and no public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in Temporal Server allows an authenticated caller holding at least namespace read permission to crash the receiving Matching process by submitting a malformed MySQL version comment through the ListWorkers API when that API is enabled. The root cause is in the bundled temporalio/sqlparser Go library, where ExtractMysqlComment fails to validate the -1 returned by strings.IndexFunc before using it as a slice boundary, producing an unhandled Go runtime panic whenever a '/*! ... */' comment has empty contents or one to five decimal digits. Impact is availability-only (process termination, repeatable to sustain an outage) with no confidentiality or integrity effect; no public exploit identified at time of analysis, and exploitation is gated on both API enablement and authenticated namespace read access.
CPU exhaustion in Temporal Server before v1.30.7 and v1.31.3 allows an authenticated caller holding namespace write permission (PR:L) to persist a Schedule whose fine-grained cadence is fully negated by an exclusion calendar, forcing the next-action-time search to evaluate excluded candidates without any per-search work budget and burning CPU in the Frontend and Schedule worker components. Because the abusive specification is stored, consumption continues through repeated backing-Workflow failures and retries even after the initial request finishes, until the Schedule is deleted or its backing Workflow terminated; repeated or parallel Schedules can degrade or deny service to shared infrastructure. The impact is availability-only with no exposure or modification of Workflow data, no public exploit code has been identified at time of analysis, and vendor-released patches are available in v1.30.7 and v1.31.3. This is a genuine but bounded availability issue whose severity is highest in multi-tenant clusters where one namespace's write access can degrade shared Frontend and Schedule-worker capacity.
Replayed TOTP passcodes stay valid in mayswind ezBookkeeping before 2.0.0, so an attacker who already holds a victim's valid primary credentials and has captured a live TOTP code can resubmit that same code against the two-factor authorization or OAuth2 callback endpoint instead of being rejected after its first use. The window of abuse is bounded by the server's TOTP acceptance period (roughly 90 seconds, reflecting adjacent 30-second time steps), and only accounts with TOTP-based two-factor authentication enabled on pre-2.0.0 releases are exposed; interception must happen in real time via a phishing proxy, MITM position, or direct observation. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:R (7.6), and although PR:N indicates no privileges are required on the vulnerable component, practical exploitation presupposes stolen credentials plus a captured code, so this is a conditional weakness rather than a default-install compromise - no public exploit identified at time of analysis, and the vendor fixed it in 2.0.0.
Cross-scope secret disclosure in Perses (versions 0.43.0 through 0.54.0-rc.0) allows an authenticated user holding only GlobalDatasource:create or a project-level datasource-creation right to attach a project or global Secret they are not permitted to read to a datasource they control, causing Perses to forward the decrypted secret in plaintext to an attacker-operated endpoint. Exploitation requires an account with datasource-create permission in a deployment where Datasource and Secret scopes are separately granted, plus the ability to point the datasource at attacker-controlled infrastructure; the vendor fix enforces a Secret read-permission check on both the datasource-creation service and the unsaved-datasource proxy paths, and older releases can be fully protected by creating datasources via provisioning and revoking the datasource-create right. No public exploit code has been identified at time of analysis, and there is no indication of active exploitation (CISA KEV).
Authenticated users holding only viewer rights on a single project can read the dashboards, datasources, and variables of every other project in Perses deployments prior to 0.54.0-beta.3, by overriding the project in scope with a client-supplied 'project' query parameter on project-scoped list endpoints. Exploitation requires a low-privilege authenticated account (PR:L), needs no user interaction or non-default configuration, and yields read-only cross-tenant disclosure of full resource specifications rather than any modification. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor-released fix is version 0.54.0-beta.3.
Ultraviolet CoCoS through version 0.8.2 contains a session-misbinding flaw in the intra-handshake attested TLS (aTLS) verification path for Intel TDX: the verifier fails to copy the expected current-session freshness value into the TDX quote-body policy before quote validation, so any structurally valid TDX QuoteV4 Evidence is accepted without checking that its REPORT_DATA field matches the reportData expected for that session. An unauthenticated remote counterparty (CVSS vector AV:N/PR:N) that can supply or relay such a quote - acting as the attesting party or replaying a previously captured or foreign quote - can therefore cause a relying party to release application data bound to an unintended attestation context, giving high confidentiality and integrity impact. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the vendor's 9.1 score (AV:N/AC:L) slightly overstates ease of exploitation versus our assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, since a valid TDX quote and use of the affected TDX aTLS branch are prerequisites. The issue is fixed in version 0.9.0.
An attestation-freshness and origin-validation failure in the aTLS AMD SEV-SNP verification path of Cocos AI (Ultraviolet) affects versions up to and including 0.8.2: when a relying party invokes the intra-handshake verification path with no expected reportData value (nil, empty, or omitted), the SEV-SNP policy ReportData is left unset and the verifier will accept unrelated or stale Evidence that is not bound to the current TLS connection. An attacker who possesses a valid but foreign or replayed SEV-SNP attestation blob can therefore induce a trusting party to accept an unintended attestation context, undermining the core trust guarantee of the confidential-computing platform and potentially enabling both integrity and confidentiality compromise in any workflow where aTLS output drives a trust or authorization decision. Exploitation is unauthenticated at the network layer (CVSS PR:N) but constrained by high attack complexity and specific prerequisites - the caller must omit the expected reportData, and only SEV-SNP aTLS deployments up to 0.8.2 are exposed; no public exploit code or confirmed active exploitation has been identified at time of analysis. The issue is fixed in version 0.9.0.
zot container registry versions prior to 2.1.18 mis-map the HTTP DELETE method to the "push" scope action in its bearer authentication handler, so an authenticated client holding a token scoped only to pull and push can delete manifests and blobs inside that token's repository scope. Because bearer-authenticated requests also skip the fine-grained DistSpecAuthzHandler and the DeleteManifest/DeleteBlob handlers perform no independent permission check, no delete authorization is ever required; the attacker can make images unavailable and alter repository history (CWE-285, CVSS 8.1). Exploitation requires the registry to be configured for bearer/JWT authentication and the attacker to already possess a valid, unexpired token covering the target repository - no public exploit code has been identified at the time of analysis, and the flaw is fixed in 2.1.18.
Capsule, the Kubernetes multi-tenancy and policy framework (projectcapsule/capsule), mishandles case-insensitive sorting in its forbidden-list lookup on versions prior to 0.13.7, allowing an authenticated tenant owner to slip denied metadata keys past api.ValidateForbidden and bypass configured namespace, Service, or delegated node metadata restrictions - potentially altering cluster policies, network exposure, or pod scheduling outside the tenant boundary. Exploitation is conditional: the cluster administrator's forbidden list must mix capitalized and lowercase keys (or otherwise produce different case-insensitive and byte-order sortings), which is why the assessed vector is AV:N/AC:H/PR:L with scope change and high integrity impact. The flaw maps to CWE-697 (Incorrect Comparison), and no public exploit code or confirmed in-the-wild activity has been identified at time of analysis; a vendor fix is available in 0.13.7.
Cross-tenant credential disclosure in Convoy (frain-dev/convoy) prior to version 26.6.8 lets an authenticated user or project-scoped API key holder read another tenant's Source record - including unredacted AMQP, Kafka, SQS, and Google PubSub broker credentials - by substituting a foreign Source identifier in GET /api/v1/projects/{projectID}/sources/{sourceID}. The endpoint correctly authorizes the project in the URL but Handler.GetSource resolves the Source purely by sourceID, so the object-level ownership check is missing (IDOR/BOLA, CWE-639). Exploitation requires only a low-privilege authenticated credential (CVSS:4.0 PR:L, CVSS:3.1 PR:L) plus knowledge or enumeration of the target Source UID; the list endpoint remains properly project-scoped and is not affected. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and a vendor-released patch is available in 26.6.8.
Cross-workspace impersonation and complete authorization bypass in kcp (kcp-dev) before 0.31.4 and 0.32.x before 0.32.2 let any authenticated tenant forge Kubernetes-style identity headers that the shard accepts as trusted authentication assertions. Because the front-proxy and the server localproxy forward inbound X-Remote-User, X-Remote-Group, and X-Remote-Extra-* headers without clearing them, an attacker with valid credentials for any single workspace can supply values such as X-Remote-Group: system:masters, authorization.kcp.io/warrant, authentication.kcp.io/scopes, or a group used for per-workspace required-group gating to read, write, or delete resources, secrets, RBAC data, APIExports, APIBindings, and LogicalClusters across the installation. Exploitation requires authenticated access (CVSS vector PR:L, AV:N, no UI), yields changed scope per the vendor vector (CVSS 9.9), and no public exploit code or confirmed active exploitation was identified at time of analysis; fixed releases 0.31.4 and 0.32.2 are published.
Stack exhaustion in go-openapi/swag's jsonutils package before 0.27.1 allows unauthenticated remote attackers to crash any Go service that parses or serializes ordered JSON from untrusted input - most notably endpoints that accept OpenAPI specification documents or otherwise route attacker-controlled JSON through the ordered marshal/unmarshal path - by submitting a deeply nested document that recurses without any depth limit. The result is a fatal Go stack overflow that terminates the process and drops all in-flight requests; there is no data exposure or modification, so impact is confined to availability (CVSS 8.7, CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VA:H). No public exploit code has been identified at time of analysis and the flaw is not listed in CISA KEV, but exploitation requires only a single crafted request, so exposure should be treated as high for internet-facing services built on this library. The underlying defect is CWE-674 (uncontrolled recursion).
SQL injection in the SigNoz v5 query_range API (versions 0.87.0 through 0.141.x) lets authenticated users with the Viewer role or higher inject backticks and quotes into user-supplied telemetry field-key names, breaking out of ClickHouse identifier and string-literal contexts to execute arbitrary SQL. Successful exploitation allows cross-scope read access to ClickHouse system tables and exfiltration of telemetry data, with limited integrity impact; an attacker needs only valid low-privilege credentials and network access to the SigNoz API, with no user interaction or non-default configuration required. The issue is patched in SigNoz 0.142.0 per the vendor advisory (GHSA-q3h7-gpc9-2rxc), and no public exploit code was identified at time of analysis.
Improper validation of the Username argument in rcourtman Pulse's Quick Security Setup handler (/api/security/quick-setup) allows manipulation of the value passed into fmt.Sprintf in versions up to 6.0.4 and 6.1.0-rc.4, with the vendor scoring it 9.4 while VULDB tags the issue as information disclosure. The vendor CVSS 4.0 vector specifies PR:H, indicating a privileged/authenticated actor, yet quick-setup style endpoints are frequently reachable during initial unconfigured deployment before authentication is enforced, and this contradiction is unresolved in the available data. There is no public exploit identified at time of analysis and the CVE is not in CISA KEV, so practical risk is bounded by an unclear demonstrated impact rather than the headline score; analysis tags show no CPE strings, and reference material points to a vendor fix in release v6.1.0.
SAML SSO authentication bypass in SUSE NeuVector lets anyone who legitimately holds an account on another application behind the same corporate identity provider log into NeuVector without ever having been granted a NeuVector account. NeuVector's SAML service provider handler never validates the assertion's <Audience> element, so a bearer assertion minted for a wiki, ticketing system, or expenses tool is accepted verbatim; the internal NotInAudience warning is produced but never read, which is the CWE-287 improper-authentication root cause. Exploitation is not free - it requires SAML authentication to be enabled against an IdP shared with at least one other relying party and valid credentials in that same federation (PR:L, AT:P) - but it needs no NeuVector account, no admin rights, and no victim interaction, and it yields high confidentiality and integrity impact; there is no public exploit identified at time of analysis and no CISA KEV entry, so this is a high-priority authentication defect rather than a confirmed actively exploited one.
Session cross-wiring in SUSE NeuVector before 5.6.1 allows an unauthenticated remote attacker to obtain another user's authenticated console session when multiple SAML or OIDC SSO login attempts occur concurrently, effectively enabling account takeover of the container security console. Exploitation requires SSO to be enabled and a race condition against a legitimate user's simultaneous login, so it is not trivially automatable; an independent assessment rates it with high attack complexity and user interaction. Publicly available exploit code exists, but EPSS is low (0.24%, 15th percentile) and no active exploitation has been confirmed (CISA SSVC: exploitation none).
Server-side request forgery in Coze Studio through version 0.5.1 allows an authenticated user who can register or configure a plugin tool to supply an arbitrary server URL, causing the backend to issue HTTP requests to internal-only destinations on the attacker's behalf. The primary risk is confidentiality rather than code execution: responses from cloud metadata endpoints (for example 169.254.169.254) or other services reachable only from the backend network can be read back through the plugin mechanism, potentially exposing credentials, tokens, and internal service data. The issue is rated 7.1 in the CVSS 4.0 vector published with the CVE, while the independent assessment scores it as a credentialed SSRF (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) with no integrity or availability impact; no public exploit code was identified at time of analysis and no CISA KEV listing applies, so this is a moderate-priority, credentialed SSRF rather than a critical remote-takeover flaw.
Authorization bypass in GoAdmin through 1.2.26 allows any authenticated user with a valid session (CVSS PR:L - an account on the target instance is required) to reach administrative endpoints by appending a crafted query string containing the configured admin prefix followed by /logout to a request URL; the permission-checking middleware mistakes the request for the exempt logout route and skips authorization entirely. Successful exploitation permits unauthorized reads of sensitive data and modification of application state (C:H/I:H), with no user interaction needed in a default deployment. No public exploit code and no confirmed in-the-wild exploitation have been identified at time of analysis - the issue is tracked as EUVD-2026-81056 and reported by VulnCheck, and no vendor-released patch version is identified in the available data.
Authentication bypass in OpenNHP through 1.0.2 allows remote unauthenticated attackers to defeat trusted-execution attestation verification by supplying evidence that includes a test_purpose key, which forces the FallbackVerifier to execute unconditionally. Attackers must also provide enrolled measure and serial-number pairs that already exist in the allowlist, which is the primary real-world limiter on exploitability. No public exploit code was identified at time of analysis, and the issue is not listed in CISA KEV; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) indicates high confidentiality impact, though the raw CVSS 4.0 score of 8.7 slightly overstates unconditional trivial exploitability.
Unauthenticated path traversal in Uber Kraken through 0.1.29 allows remote attackers to read files outside the configured storage root via the /tags/{tag} endpoint when the testfs backend and build-index tagserver are exposed. Percent-encoded parent-directory segments in the tag parameter bypass path validation and disclose files readable by the testfs process account, yielding high confidentiality impact with no integrity or availability effect. No public exploit identified at time of analysis.
Improper authorization in Coze Studio through 0.5.1 lets an authenticated user (CVSS PR:L) abuse the workflow SQL customization node to reach memory-database tables belonging to other workspaces, because referenced table names are never validated against the caller's own workspace. By enumerating predictable table identifiers, the attacker can read, insert, or delete data in another tenant's memory database, yielding high confidentiality and integrity impact within the affected multi-tenant deployment (our assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Exploitation requires valid low-privilege credentials and a deployment hosting multiple workspaces on a shared memory-database backend; single-tenant installations have little to expose via this path. No public exploit code was identified at time of analysis, and there is no KEV confirmation of active exploitation.
Harbor through 2.15.2 can disclose scanner adapter AccessCredential secrets to an authenticated project administrator who abuses fuzzy q-parameter filtering and observes response row counts one character at a time. This is a privilege-gated confidentiality issue rather than a critical remote-takeover flaw: the attacker must already hold a project-admin role and must issue many sequential API requests, with no user interaction and no special feature toggle required in default configurations. Publicly available exploit code exists, and the supplied data does not confirm active exploitation by CISA KEV.
Authenticated users on Harness deployments through version 3.3.0 can read infrastructure provider configurations from spaces they do not belong to, because the GET /api/v1/infraproviders endpoint fails to validate space-level access control (CWE-862). Exploitation requires only a valid low-privilege account (CVSS v4.0 PR:L, and the independent assessment rates it PR:L as well), so it is realistic mainly on multi-tenant or multi-space instances where the attacker's account lives in a different space than the targeted provider records; a single-tenant instance with no untrusted users has limited exposure. The result is a confidentiality-only impact (VC:H, no integrity or availability effect) exposing sensitive provider metadata such as Docker endpoints, TLS certificate paths, and cloud project identifiers. No public exploit identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV). Note: the supplied CVSS v4.0 base score of 7.1 and the independent CVSS v3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) agree on the authenticated, network-reachable, read-only nature of the flaw.
Unauthenticated remote attackers can forge valid administrator session cookies for the Chaitin SafeLine management console (all versions through 9.4.1) because the session-signing secret is derived from a time-seeded math/rand generator (CWE-338) and can be reconstructed offline once the install timestamp is bounded. Successful exploitation yields full administrative control of the protected sites managed by that console, matching the 9.2 CVSS 4.0 rating and the independently assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H profile. Two prerequisites limit practical reach: the management console must be network-reachable from the attacker, and the attacker must be able to narrow the installation time enough to make the seed search feasible. No public exploit code and no confirmed in-the-wild exploitation were identified at the time of analysis, and consoles placed behind network segmentation, VPN, or IP allow-listing are not exposed to remote cookie forgery.
Nil-pointer dereference in kin-openapi 0.136.0 through 0.148.x lets an unauthenticated remote client reliably panic Go applications that run openapi3filter request validation against an OpenAPI 3.1 spec declaring an array schema without an items definition. Three decoder paths are affected: a plain array query parameter, a deepObject query parameter whose object contains an array property, and an application/x-www-form-urlencoded body whose array property appears inside an allOf, anyOf, or oneOf subschema - each passes a nil items schema into urlValuesDecoder.parseArray or buildResObj, which dereferences it. Impact is availability-only (CVSS 7.5, CWE-476), exploitation is conditional on the target application actually exposing such a nil-items array schema on a validated route, and no public exploit code or CISA KEV entry is identified at time of analysis; the vendor fixed the issue in 0.149.0.
Denial of service in kin-openapi before 0.149.0 allows unauthenticated remote attackers to terminate the entire Go process by triggering unbounded recursion during runtime schema validation. When a loaded OpenAPI document contains an allOf, anyOf, or oneOf chain that refers back to an ancestor schema - a circular reference the loader and document validation accept without error - a request or response that reaches that schema causes Schema.visitJSON or openapi3filter.decodeValue to recurse until the goroutine stack is exhausted; the resulting fatal stack overflow cannot be caught with recover and aborts the whole process, including unrelated in-flight requests. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5), driven entirely by availability with no confidentiality or integrity impact; the key limiting factor is that a vulnerable circular schema must already exist in the deployed spec, so default non-circular specs are unaffected. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the issue is fixed in version 0.149.0.
A nil-pointer panic in kin-openapi's openapi3filter validation path can crash any Go service that embeds versions 0.136.0 through 0.142.x and serves an OpenAPI 3.1 document with an array schema that omits the items keyword. Unauthenticated remote clients (CVSS vector PR:N/UI:N) only need to send a single nonempty application/x-www-form-urlencoded or multipart/form-data request to an affected operation - or trigger a matching response on a surface such as a response header - to deterministically panic ValidateRequest or ValidateResponse, producing denial of service with no confidentiality or integrity impact (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 7.5). The risk is real but bounded: only OpenAPI 3.1 specs containing the specific malformed-but-spec-legal array shape are exposed, JSON request bodies use a different decoder, and OpenAPI 3.0 documents are rejected at validation time. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation.
RA-TLS session binding bypass in Privasys Go before privasys-v0.5.1-go1.26.5 allows remote attackers who already possess a valid enclave TLS private key to relay a genuine attestation quote onto a different TLS connection, causing a relying party to accept an attacker-terminated handshake as an attested enclave connection. The flaw stems from challenge-mode RA-TLS certificates binding quote ReportData to the certificate public key and client nonce but not to the active TLS session (CWE-346). No public exploit code has been identified, and exploitation requires both a stolen enclave TLS private key and a verifier that does not independently bind attestation to the session channel; the vendor has released a fix in privasys-v0.5.1-go1.26.5.
Memory exhaustion in Go's standard-library net/http HTTP/2 server lets a remote attacker send a single crafted request whose "Trailer" header declares an excessive number of fields, causing the server to allocate a disproportionately large Request.Trailer map for the handler. The issue is availability-only (C:N/I:N/A:H), requires no authentication and no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and crucially bypasses the Server.MaxHeaderValueCount and Server.MaxHeaderBytes defenses; HTTP/1 servers are not affected because they do not multiplex many requests over one connection and account for MaxHeaderBytes differently. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV); EPSS is low at 0.23% (12th percentile), and vendor patches are available, so this is a genuine but moderate-priority availability bug rather than an emergency.
Checksum verification bypass in the Go toolchain (cmd/go) versions 1.27.0 before 1.27.2 and before 1.26.9 allows a malicious Go project with a forged golang.org/toolchain go.sum entry, combined with a user-selected attacker-controlled GOMODPROXY, to substitute a tampered toolchain that cmd/go would otherwise reject. Exploitation requires local access and user interaction (CVSS 7.8, AV:L/UI:R) and two attacker-controlled preconditions the victim must opt into: operating inside the crafted project and using the malicious proxy. No public exploit code identified at time of analysis, and EPSS is 0.13% (2nd percentile), indicating low predicted exploitation likelihood.
Resource exhaustion in the Excelize Go library (versions 2.1.0 through 2.11.0) lets a crafted .xlsx workbook drive excessive CPU and memory consumption - up to process OOM - when an application loads the file and later invokes a column-mutating API such as SetColWidth. The root cause is a missing bounds check in flatCols, which iterates from an attacker-controlled column minimum to an attacker-controlled maximum and performs a deep copy plus append for every declared column number instead of clamping to the spreadsheet's 16,384-column limit. Exploitation requires a victim or service to parse the malicious workbook (UI:P) and then perform a column operation on it; no authentication to the library is required (PR:N), no public exploit code has been identified at time of analysis, and no fixed release is available - although an upstream fix exists as a pull request and commit. CVSS 4.0 base score is 7.1 with availability-only impact (VC:N/VI:N/VA:H); the impact is denial of service, not confidentiality or integrity loss.
Denial of service in the Excelize Go spreadsheet library (github.com/xuri/excelize/v2 2.0.0-2.11.0 and github.com/xuri/excelize 1.1.0-1.4.1) lets an unauthenticated remote attacker terminate the calling process by supplying a crafted workbook. The ColumnNameToNumber function converts bijective base-26 column names into int64 without overflow detection, so an over-long name such as VGWQHXLSDVIKWV wraps to zero and is later used as a slice index by checkSheetR0 and xlsxWorksheet.checkRow, producing a negative index panic during worksheet normalization. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5), meaning availability-only impact; there is no evidence of confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis, though the upstream fix commit and PR are public. This is a moderate-severity denial-of-service condition rather than a high-priority emergency, and it is only reachable when an application built on the vulnerable versions parses an untrusted spreadsheet.
Uncontrolled recursion in the Excelize Go library (versions 2.8.1 through 2.11.0) allows a fatal Go stack overflow that aborts the host process when mutually referencing dynamic-array formulas using _xlfn.ANCHORARRAY are evaluated, resulting in a pure availability impact (CVSS:3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Reachability depends entirely on the host application: it is exploitable only when an application feeds attacker-controlled spreadsheet content into CalcCellValue or another formula-evaluating API, while applications that merely read raw cell values are unaffected. No public exploit code has been identified at time of analysis, and although an upstream fix commit exists, no released patched version has been confirmed (the advisory states no fixed version is available as of its review).
Memory exhaustion and runtime panic in the Excelize Go library (versions 2.3.1 through 2.11.0) let unauthenticated remote attackers crash or drive out-of-memory conditions in any service that decrypts attacker-supplied, password-protected OLE compound (CFB) Excel workbooks. The assessed CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) confirms no privileges or user interaction are needed and that impact is confined to availability, with no code execution or data exposure. No vendor-tagged fixed release was available as of this review, though an upstream fix exists as PR #2396 / commit 5f636f9; no public exploit code was identified at time of analysis and there is no KEV listing.
Denial of service in Excelize versions 2.3.1 through 2.11.0 allows unauthenticated remote attackers to terminate the calling Go process by supplying a malformed OLE compound file with a version-valid EncryptionInfo stream to the library's Decrypt function. The decryption dispatch lacks structural and parameter validation, causing nine malformed-input classes to trigger unrecovered Go runtime panics instead of returning documented errors. Exploitation requires the host application to process attacker-supplied encrypted spreadsheets, no fixed version is available as of this review, and no public exploit code has been identified.
Denial of service in Excelize 2.9.0 through 2.11.0 allows a crafted spreadsheet to panic and terminate a Go process that calls File.GetSlicers. When a worksheet contains an extLst element but the independently optional drawing element is absent, GetSlicers dereferences the nil ws.Drawing pointer while resolving the drawing relationship, producing a runtime panic; the CVSS v4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) indicates remote, unauthenticated triggering with high availability impact but no confidentiality, integrity, or scope impact. Exploitation is not confirmed to be occurring in real-world campaigns and no public exploit code has been identified at time of analysis, though the upstream fix commit and pull request are public, which lowers the bar for crafting a malicious XLSX; the independent assessment rates this as a moderate, impact-limited risk because GetSlicers is not part of the default file-open or parse path and any recover() wrapper neutralizes the crash.
Denial of service in the Excelize Go library (versions 2.1.0 through 2.11.0) allows an attacker-controlled spreadsheet to pin a CPU core for an arbitrary duration when a Go application calls File.GetRows or iterates Rows.Next/Rows.Columns on the untrusted file. The bug is an inconsistency in the row-number limit: Rows.Next enforces the TotalRows (1,048,576) cap, but Rows.Columns consumes the 'r' attribute of a crafted <row> element located after an ordinary valid row without that cap, so the iterator walks every missing row number instead of rejecting the workbook. Impact is availability-only (CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), unauthenticated but requiring the application to accept and parse attacker-supplied XLSX files; no public exploit code was identified at time of analysis and no fixed release exists, though an upstream fix is present in PR #2438/commit 01a9ff32. This is a genuine but bounded denial-of-service issue (CWE-770, uncontrolled resource consumption).
Silent argument dropping in Coraza WAF v3 (>= 3.0.0, < 3.8.1) lets unauthenticated remote attackers evade every SecRule that inspects ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES or ARGS_PATH - including the OWASP CRS SQLi, XSS, RCE and LFI families - by padding a request past SecArgumentsLimit (default 1000) so the malicious parameter is discarded before phase 2 evaluation; roughly 10,000 GET parameters yields about a 94% per-request bypass, and the failure is completely silent (no audit-log entry, no transaction flag). The same advisory covers unbounded ARGS_POST growth because Coraza's urlencoded and JSON body processors ignored the argument cap entirely, which is also a per-request memory-exhaustion DoS surface. No public exploit identified at time of analysis and no confirmed active exploitation; vendor-released patch: 3.8.1 (the 3.8.0 fix was incomplete and 3.8.0 remains listed as affected), and the advisory/report is credited to the corazawaf project with AI-assisted analysis disclosed. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L (7.2 High), a CWE-693 protection-mechanism failure whose impact lands on the protected application rather than Coraza itself.
Denial of service in Apache Thrift's Go bindings (versions before 0.25.0) lets unauthenticated remote attackers exhaust memory or CPU by sending highly compressed payloads over a compressed transport, so a tiny request expands into a disproportionately large in-memory buffer (CWE-409 data amplification / decompression bomb). Exploitation is conditional: per the vendor's CVSS 4.0 score the AT:P metric applies, meaning the affected service must actually accept attacker-supplied compressed data (for example a zlib-backed transport carrying untrusted input) - deployments of the Go bindings that do not parse compressed payloads from external sources are not exposed. Impact is availability-only (service crash, hang, or memory exhaustion) with no code execution or data disclosure; no public exploit code and no confirmed active exploitation were identified at time of analysis, and our independent assessment uses a 3.1 vector of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H reflecting that precondition.
OpenSave through 2.4.0 contains a path-validation bypass (CWE-73) in which a paired peer can supply save paths that fall outside the operator's configured save locations, enabling arbitrary file read and write on the target instance via the manifest request handler and sync routes. The CVSS 4.0 base score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H) reflects high confidentiality and integrity impact with no user interaction and low attack complexity, though the attacker must already be a paired peer of the target (authenticated, PR:L), so an unpaired remote party cannot reach the flaw. No public exploit code and no confirmed active exploitation were identified at time of analysis, but a public advisory and the affected source locations are documented, making the issue straightforward to reason about for anyone already inside a peer trust relationship.
Improper verification of the source of ADS discovery responses in Apache PLC4X (CWE-940) allows an attacker on the adjacent network to redirect subsequent connections to an arbitrary host by spoofing a UDP discovery response, potentially exposing ADS route credentials. Affected versions are PLC4Go 0.11.0-<1.0.0, PLC4J ADS/Modbus 0.10.0-<1.0.0, and PLC4J EtherNet/IP 0.11.0-<1.0.0. Exploitation requires the consuming application to invoke the opt-in discovery API and act on discovered items; no public exploit identified at time of analysis. Upgrade to 1.0.0 to fix.
Symbolic-link path resolution flaw in Google MCP Toolbox for Databases 1.2.0 through 1.9.0 lets an authenticated remote attacker who holds tool-execution permissions read or overwrite arbitrary local files outside the directories configured in allowedLocalRoots. The affected tools, cloud-storage-upload-object and cloud-storage-download-object, validate a caller-supplied path lexically before following it, so a symlink planted inside an allowed root that points outside that root is accepted. Exploitation requires valid tool-execution authorization (CVSS PR:L) and a symlink reachable inside an allowed root, so no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); the vendor describes the control as a guardrail that must be layered on top of OS file permissions.
Improper authorization in Ollama's experimental agent-mode Bash tool allows an attacker who can influence model output - for example through prompt injection from untrusted content the agent reads - to smuggle extra shell commands past the user approval prompt. Because the approval logic (x/agent/approval.go in 0.14.0 through 0.31.1) authorizes commands by prefix match without parsing shell syntax, appending a control operator such as ';', '&&', or '||' to an already-approved command causes the trailing command to run with full host privileges, yielding high confidentiality, integrity, and availability impact (CVSS 4.0 base 8.5; independently assessed as CVSS 3.1 AV:L/AC:L/PR:N/UI:R with C:H/I:H/A:H). This is a genuine but conditionally-gated risk rather than a mass-exploitation threat: the attack vector is local, agent mode is an experimental feature that is not enabled by default, and the victim must approve at least one Bash command within the session; no public exploit identified at time of analysis.
Arbitrary code execution on an operator's workstation is achievable through kube-compare when it processes a 'container://' reference path pointing at an untrusted container image, because the tool launches that image's entrypoint instead of only reading data out of a stopped container. Exploitation is locally scoped and gated: per the assessed vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, an unauthenticated (PR:N) attacker must convince the operator to invoke the tool against the malicious reference (UI:R), so the victim's own action is the trigger. This is a genuine but conditionally-gated risk - escalation to full root-mediated impact occurs only where the local Docker daemon runs with elevated privileges - and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis; EPSS data was not supplied. The tool is distributed in Red Hat OpenShift Container Platform 4 and the 'Pen Drive Powered by Red Hat Lightspeed' offering.
Host header injection in Nezha 2.2.3's OAuth2 redirect endpoint (/api/v1/oauth2/{provider}) allows an unauthenticated remote attacker who can control the HTTP Host header on a request reaching the server to make Nezha emit an attacker-chosen redirect_uri to the configured identity provider; a victim induced to start the OAuth2 login/binding flow can then have their authorization code delivered to the attacker's origin, letting the attacker complete the flow and take over the account. The bug is a regression of the GHSA-9rc6-8cjv-rcvx fix and only manifests when the new optional dashboard_host setting is left empty, so the code no longer falls back to install_host; exploitation also requires victim interaction and an identity provider that accepts the forged redirect URI, which is why the independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:R while the vendor-style CVSS 4.0 rating is 9.3. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; no patched release version was published with the advisory, only an upstream fix commit (38824dbc11a63964c5b9296ae4c68e62b34fa04b).
Authorization bypass in Obot before v0.21.1 lets any authenticated user with a known MCP Server ID connect to restricted MCP servers through the /mcp-connect/{id} gateway endpoint, which fails to enforce Access Control Rules and MCP Registry membership. Because the gateway reuses Obot's stored OAuth/API credentials for the upstream server, an attacker in a Basic role or above can invoke that server's tools - reading and writing data in whatever backends those credentials reach - even when administrators explicitly scoped the server to a small group. Independently assessed at CVSS 9.3, this is a genuine high-priority authorization flaw limited to multi-user deployments that register credential-bearing MCP servers and depend on ACRs for isolation; no public exploit code has been identified at time of analysis, and vendor-released patched version 0.21.1 is available.
Server-side request forgery in Obot through v0.22.1 allows an authenticated user holding the Power User, Power User Plus, or Admin role to register a remote MCP server pointing at an arbitrary URL, which Obot then fetches server-side with no destination validation. Because the fetched response is reflected back in Obot's error messages, this is a non-blind SSRF: the attacker can read responses from internal services and, against the cloud metadata endpoint 169.254.169.254, potentially obtain the host's cloud IAM credentials and pivot into the cloud account. Exploitation is role-gated and requires authentication to be enabled with privileged users permitted to register remote MCP servers; there is no public exploit identified at time of analysis, and the issue is fixed in v0.23.0.
OAuth dynamic client registration in Obot through v0.22.1 allows unauthenticated remote attackers to register an OAuth client pointing at an attacker-controlled redirect URI, then harvest an access and refresh token from a logged-in victim who visits a single crafted authorization URL. The minted token carries the victim's full group set and is accepted as a bearer token against any Obot API endpoint the victim can access - not just the requested MCP server - letting the attacker read or modify the victim's resources until the token is revoked. Exploitation is gated by the server running with OBOT_SERVER_ENABLE_AUTHENTICATION=true and by required victim interaction (clicking the link); no public exploit code has been identified at time of analysis. Versions v0.23.0 and later add a consent screen, token scoping to the requesting MCP server, and audience validation.
Host-controlled AML injection in Edgeless Systems' Contrast confidential-computing runtime before 1.18.0 lets an adversary who controls the QEMU host achieve arbitrary code execution inside AMD SEV-SNP guest VMs, including reads and writes to private memory pages that the confidential-computing model is supposed to shield. Only the Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms are affected; Metal-QEMU-TDX is not, because OVMF measures ACPI table contents into RTMR 0 on Intel TDX. The flaw is rated CVSS 8.4 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) via the host-to-guest trust boundary, carries no CISA KEV status and no public exploit code identified at time of analysis, and is fixed in Contrast 1.18.0, which sandboxes the kernel AML interpreter; the underlying BadAML technique is publicly documented in academic and Black Hat EU 2024 research, and the weakness is generic to Confidential Computing deployments that expose the ACPI interface to the host.
Arbitrary writes to the guest root filesystem in Edgeless Systems' Contrast confidential-computing runtime before 1.19.1 allow a malicious process on the untrusted Kubernetes host to achieve full guest takeover. The flaw lives in the Kata agent policies generated by the Contrast CLI: the CopyFile verification does not correctly resolve symlinks (CWE-59), so an attacker who can open a VSOCK connection to the Kata agent can chain CopyFile requests to overwrite security-critical files inside the guest or trick the workload into disclosing sensitive data. The vendor (via VulnCheck) scores this CVSS 4.0 8.6 (High), and an independent assessment concurs that it is a genuine confidentiality-and-integrity break (CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) rather than a high-score paper cut. Exploitation is not reachable over a standard network - the attacker must already hold a foothold on the untrusted host, which is precisely the adversary model Contrast assumes - and no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis.
Remote attestation relay in Edgeless Systems Contrast before 1.16.0 allows an attacker to impersonate a Contrast Coordinator or a Contrast workload and defeat attested TLS (aTLS) identity verification. Contrast accepted any TEE attestation report that verified correctly and matched expected firmware patch levels and software measurements, without binding that attestation to specific, physically-trusted hardware, so a valid report captured from one machine can be replayed to stand in for another. Per the assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), no public exploit code has been identified at time of analysis, and this is not exploitable against a default deployment by a purely remote attacker: it requires a network man-in-the-middle position on the aTLS path plus a genuine TEE machine under the attacker's physical control. The vendor's CVSS 4.0 score of 9.1 (Critical) substantially overstates real-world risk because it does not fully reward the steep compound preconditions this attack requires.
Container image substitution in Edgeless Contrast 1.14.0 through 1.23.0 lets an attacker who can reach the Kata agent API - in Contrast's threat model, a Kubernetes cluster administrator - swap a workload's container image for an exploit payload and thereby break the integrity guarantees of the confidential container. The root cause is a runtime-policy generation bug: a misplaced allow_storage rule introduced by a bad rebase during a Kata Containers update accepts storage entries using the image_guest_pull driver without verifying the image digest. No public exploit code has been identified at time of analysis and EPSS is low at 0.23% (12th percentile), but exploitation is authenticated (CVSS PR:L), non-automatable per SSVC, and gated on the substituted image still satisfying all remaining policy rules; technical impact is rated total.
Coordinator impersonation in Edgeless Systems Contrast (a confidential-computing runtime for Kubernetes) before version 1.4.1 lets an attacker who can redirect traffic to a rogue Coordinator recover arbitrary secrets of workloads deployed after the attack. The recovering Coordinator fails to verify the seed supplied by the recovering party, so a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled can issue certificates chaining to its own root CA, impersonating a workload owner when the `contrast` CLI `set` call does not compare the returned root CA certificate against the existing one (the CLI's default behavior) or when `verify` is run without comparing against a trusted reference. Exploitation is unauthenticated but conditional - it requires a network-position/man-in-the-middle prerequisite plus a victim workload-owner action - so this is a genuine but conditional integrity and confidentiality flaw rather than a widespread emergency; no public exploit is identified at time of analysis and the issue is not in CISA KEV.
Workload secrets managed by Edgeless Systems' Contrast confidential-computing platform are written to Kubernetes pod logs, letting anyone with log-read access recover secrets that are meant to be visible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner. All Contrast releases up to and including 1.8.0 are affected whenever the Contrast initializer runs at the default CONTRAST_LOG_LEVEL of info (the same leak also occurs at debug), so installations that never customized the initializer log level are exposed by default; deployments that do not use workload secrets at all are unaffected. Recovering the leaked value requires low-privileged access - Kubernetes get or list permission on pods/logs (PR:L in the assessed vector) or read access to the underlying Kubernetes log storage - this is a passive confidentiality disclosure with no code execution, and no public exploit has been identified at time of analysis.
Kyverno 1.14.0 through 1.19.0 fail open in a way that lets unsigned or untrusted container images be admitted to a Kubernetes cluster: the ImageValidatingPolicy evaluator silently ignores the spec.images and spec.allowedValues fields of a PolicyException, so any exception whose policyRefs and matchConditions match a resource disables image signature verification for that entire resource rather than only for the named images or values. An authenticated user with Kubernetes API rights sufficient to deploy or modify workloads covered by such an exception (CVSS PR:L) can therefore bypass signature enforcement without obtaining any new privileges - the flaw simply turns a narrow, trust-anchored carve-out into a blanket exemption. No public exploit code identified at time of analysis, and the vendor has released a fix in Kyverno 1.19.1; scope is limited to clusters that actively enforce signature verification through ImageValidatingPolicy and define matching PolicyExceptions.
Case-sensitivity bypass in Hugo's security.http.urls IP-literal deny rule lets builds running v0.162.0 through v0.165.x fetch URLs that the rule was configured to block - a mixed-case scheme such as 'HTTP://localhost/...' evades the deny match, re-enabling SSRF through resources.GetRemote. The issue is unauthenticated (PR:N) but local (AV:L): it only matters when a Hugo build processes attacker-influenced input and the operator depends on the IP-literal deny rule as the SSRF control, and it cannot be triggered against an already-served static site. No public exploit code has been identified and there is no confirmation of active exploitation, but a vendor patch is available in Hugo v0.166.0.
Symlink-following flaws in Hugo's theme and module mount confinement allow files outside a project's mount roots to be read during a site build and, via static mounts, published into the public/ output directory. The flaw affects Hugo builds after v0.123.0 and before v0.166.0 for any project that adopts an untrusted theme checked into themes/ or a vendored (non-Go-modules) module containing a symlink at a mount root and then runs a build; the vendor scores this 8.7 (High) under CVSS 4.0, while independent analysis models it as CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N because the site operator must first adopt the malicious theme and execute the build. No public exploit code identified at time of analysis and no KEV listing; a vendor-released patch exists in v0.166.0.
Account takeover in Wakapi before 2.17.6 is possible because the user caching service resolves lookups in an unintended context, allowing one user's lookup to return another user's cached record; unauthenticated remote attackers can thereby hijack an existing account. The high attack complexity (AC:H) reflects that an attacker must induce or await the specific cache state in which lookups cross contexts, rather than sending a single deterministic request, and no public exploit has been identified at time of analysis. Vendor-released patch: 2.17.6.
Signature-verification bypass in MinIO (all releases through commit 7aac2a2) and in the pgsty/silo fork (before commit 1233254) lets an attacker who holds a valid SigV4 presigned PUT URL - one scoped to a single object - append an unsigned x-amz-copy-source header to the otherwise unmodified URL and cause a server-side CopyObject executed with the signer's credentials, converting a write grant into reads of every object that signing key can reach. The root cause is a CWE-347 improper-verification-of-signature error: extractSignedHeaders() in cmd/signature-v4-utils.go iterates only the client-claimed X-Amz-SignedHeaders list and never enumerates the x-amz-* headers that actually arrived, so an unsigned header is neither hashed into the canonical request nor rejected, while cmd/api-router.go dispatches CopyObject purely on the presence of x-amz-copy-source. Amazon S3 rejects the equivalent request with HTTP 403 AccessDenied; exploitation here requires a delegated presigned URL plus a signing key with broader read permission, making this a privilege escalation from a delegated credential rather than unauthenticated access, with no public exploit code or confirmed active exploitation identified at time of analysis.
SigNoz deployments configured to use the non-default opaque session tokenizer leave existing sessions valid after a password reset or user deletion, so a remote authenticated attacker who already holds a live session token for an account retains that account's full access - up to administrator - for up to the token's configured maximum lifetime (30 days by default) after a reset, and until the token next rotates (30 minutes by default) after deletion. Affected versions run from v0.98.0 up to but not including v0.143.0; default installations in that range never used the opaque tokenizer and are therefore not exposed. The vendor has released v0.143.0 as the fix, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Session token forgery in SigNoz v0.8.0 through v0.142.x allows unauthenticated attackers to impersonate any user, including administrators, when the default JWT tokenizer provider runs without a configured signing secret. The application defaults the JWT HMAC key to an empty string and fails to reject this in Config.Validate(), so tokens are both signed and verified with an empty key; an attacker who knows a target user ID can forge valid access and refresh tokens, and the refresh token can be rotated at /api/v2/sessions/rotate and cannot be revoked. No public exploit identified at time of analysis; deployments that explicitly set a secret or use the opaque provider are not affected, and v0.143.0 eliminates the exposure.
Account takeover in Klever-Go's KleverUpdateAccountPermission built-in (all versions prior to 1.7.20) allows an attacker-controlled smart contract to replace a victim account's entire permission set without any victim key or signature. The handler authorizes updates using the attacker-supplied vmInput.RecipientAddr instead of the authenticated vmInput.CallerAddr, and because the default self-signer created by createDefaultOwnerPermission satisfies the contractHasValidPermission check, a contract can name any permissioned victim as recipient and install attacker-supplied Owner permissions - enabling asset theft or permanent lockout of the victim. The CVSS 4.0 score is 8.7 with a low-privilege vector (PR:L), reflecting that the attacker must be able to deploy or control a contract that can issue an indirect built-in call; accounts without stored permissions and the native transaction path are not affected. Exploitation requires no user interaction, and no public exploit code or confirmed active exploitation was identified at time of analysis; this is nevertheless a genuine high-priority vulnerability given its unauthenticated-from-the-victim's-perspective account takeover impact on a production blockchain.
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk request bodies without JSON escaping, allowing an attacker who can submit a SetAccountName transaction to inject forged bulk actions that create, overwrite, or delete documents in any index the indexer can write to. Because the name is stored in consensus account state, the poisoned value is replayed by new and historical indexers, and no access to the indexing host or the Elasticsearch port is required. Severity is rated 8.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:L; our independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), exploitation requires an authenticated low-privilege on-chain account plus a deployment that actually runs the Elasticsearch indexer, and the issue is fixed in 1.7.20; no public exploit identified at time of analysis, though the upstream fix ships a regression test that reproduces the advisory's injection construction.
Missing BLS public key validation in Klever-Go prior to 1.7.20 allows a remote authenticated party with validator-registration capability (PR:L) to submit a CreateValidatorContract (Register) or ValidatorConfig update (UpdateValidator) containing a malformed BLSPublicKey that the runtime never checks for curve membership, prime-order subgroup, or nonzero value. Impact is delayed and conditional: the malformed-key validator must first become eligible and then be selected into a consensus group, at which point MultiSigner.Reset and the signature-verification creation path fail to deserialize the group key and cancel the slot, causing repeated missed consensus rounds and throughput degradation; a complete halt occurs only when the consensus group equals the eligible validator set. This is an availability-only, conditional risk - no public exploit identified at time of analysis, no KEV listing, and genesis-path validation is unaffected because it already calls CheckPublicKeyValid.
Unauthenticated remote denial of service in Klever-Go (all versions before 1.7.20) allows any client that can reach the node's REST/WebSocket API to exhaust its memory and goroutines through the default-open /subscribe endpoint, and because that API runs in-process with the node, the resulting OOM-kill also takes down P2P and consensus participation. No API key, account, stake, or funds are required (vector PR:N), and publicly available exploit code exists: the vendor advisory ships working PoCs against unmodified production code showing a single 8 MiB WebSocket frame expanding server heap by roughly 32 MiB, 300 concurrent connections accepted despite a configured global cap of 100, and 200,000 attacker-supplied address strings growing the hub's subscription map 1:1 with no cap. The assessed severity is CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and real-world priority is bounded mainly by Klever-Go's limited node footprint rather than by any weakness in the finding itself.
Unauthenticated remote attackers can connect to the /log WebSocket endpoint in Klever-Go and either read live node logs or apply an arbitrary logger profile process-wide, for example setting *:NONE to mute normal slot logs or *:TRACE to flood them. The flaw is a management-plane information exposure (CWE-200) with additional integrity and availability effects, and publicly available exploit code exists because the advisory includes a proof-of-concept reproduction; no CISA KEV active exploitation is indicated. Exploitation requires the REST API to be network-reachable, so nodes that keep the API bound to localhost or an admin-only interface are not remotely exposed, and the vendor-released fix is version 1.7.20.
Improper enforcement of the marketplace settlement workflow in Klever-Go prior to 1.7.20 lets an authenticated seller settle a resting-bid NFT auction through the Claim seller-accept branch while leaving the claimed order loadable with a future EndTime and stale CurrentBid/CurrentBidder values. A later bidder can then submit a higher bid, be debited, and trigger a refund to the previous bidder even though the NFT has already been delivered, while Claim and CancelOrder both reject that bidder because IsClaimed is true - leaving them unable to obtain the NFT or recover their funds. The flaw is purely an integrity/business-logic issue (CWE-841, assessed CVSS:3.1 7.1, AV:N/AC:L/PR:L/UI:N with no confidentiality or availability impact, matching the vendor's 7.1 CVSS 4.0 rating); no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor fix is available in 1.7.20.
Unauthenticated remote attackers can bypass client-certificate trust in Temporal's s2s-proxy 0.1.16 through 0.2.2 by presenting a self-signed certificate and key to a mux or TCP TLS server listener, because the proxy runs Go's RequireAnyClientCert mode whenever skipCAVerification is false and therefore never validates the presented chain against the configured CA. A successful handshake yields a yamux-multiplexed, peer-authenticated channel on which the attacker can call every RPC the proxy's aclPolicy allows, exercising the proxy's own Temporal credentials against the cross-cluster replication API without supplying any trusted certificate, private key, or Temporal credential. No CISA KEV active-exploitation signal is present and no public exploit identified at time of analysis, but the defect carries a 9.3 CVSS 4.0 score and the vendor has published an upstream fix (PR #296 plus associated commits).
Photoview through 2.4.0 contains an authorization bypass in the shareAlbum GraphQL mutation that lets any authenticated low-privileged user generate valid share tokens for albums owned by other users. Because album IDs are sequential integers, an attacker with a normal account can enumerate IDs and create working share links without needing any elevated privileges; distributing the resulting link exposes the victim's photos and sub-albums. Exploitation requires a multi-user deployment and an authenticated session, and no public exploit code has been identified at time of analysis, though the vendor has released an upstream fix.
Timing-based leakage of the single recovery token in OpenBao lets a remote, unauthenticated attacker who can reach the instance while it is running in highly privileged recovery mode recover that token and then read or modify data on the OpenBao instance. The exposure is constrained to the transient recovery-mode break-glass state rather than the normal serving configuration, and exploitation requires collecting a large volume of low-noise timing samples against the recovery endpoint (reflected in the CVSS 4.0 rating of 9.2 with AC:H and AT:P, and in the assessed CVSS 3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). The vendor addressed the flaw in OpenBao v2.6.0; no public exploit identified at time of analysis.
Unauthenticated denial of service in the sipgo SIP library (versions up to and including 1.4.2) lets any remote attacker who can reach a SIP-over-WebSocket (WS or WSS) listener crash or memory-exhaust the server process. WSConnection.Read allocates a buffer directly from the client-declared WebSocket frame length - a value the attacker controls up to 2^63-1 - before MaxFrameSize or the downstream ParseMaxMessageLength check is ever applied, so a single header-only frame with a huge declared length triggers a makeslice panic that terminates the whole process (sipgo does not recover it), or forces an oversized allocation. No authentication, credentials, or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 7.5, CWE-789), a working proof-of-concept frame is documented in the vendor advisory, and the flaw is fixed in 1.4.3; impact is confined to availability, with no confidentiality or integrity effect, and only services that actually enable the WS/WSS transport are exposed.
Memory-exhaustion denial of service in the SIPGO Go library (versions up to and including 1.4.0) lets an unauthenticated remote peer crash or destabilize any SIP service built on it that exposes a stream listener. A single SIP message sent over TCP, TLS, WebSocket, or WebSocket-Secure with an oversized, attacker-declared Content-Length header (up to 2^32-1) causes the stream parser to allocate a body buffer of that size before the library's 65535-byte max-message-length guard is evaluated, exhausting process memory. The flaw is fixed in version 1.4.1, the vendor advisory (GHSA-pg59-5vwg-4jxq) includes a working proof-of-concept, so publicly available exploit code exists; impact is availability-only with no code execution or data disclosure, consistent with the CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
Concurrent upload-session requests in Cloudreve prior to 4.18.0 allow an authenticated user holding Files.Write permission - which the default User group provides - to bypass the per-account storage quota and reserve more space than the account is allowed, ultimately exhausting host disk and denying uploads to other users. The flaw is a time-of-check-to-time-of-use race: PrepareUpload validates capacity against a stale in-memory value while the actual storage charge is applied later and outside the same quota-enforcing transaction, so parallel requests that read the same snapshot all pass the MaxStorage check. Exploitation requires genuinely simultaneous requests and a valid low-privileged account, and impact is limited to availability (no data disclosure or code execution); no public exploit code was identified at time of analysis, and the issue is fixed in 4.18.0.
Horizontal privilege escalation in the x-ui web panel 0.3.2 allows any authenticated panel user to rewrite another user's inbound proxy configuration - remark, port, protocol, settings, enabled state, expiry time and traffic quota - by submitting an inbound-update request that carries the victim's resource identifier, because the update path never verifies that the referenced inbound belongs to the requesting session user (CWE-284). The flaw is network-reachable and requires no victim interaction, with a CVSS 3.1 vector of AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8); an independent assessment retains High severity and confirms the integrity impact (cross-tenant configuration tampering) while narrowing confidentiality and availability to Low, since the tampering is confined to proxy resource data rather than granting panel or host compromise. Exploitation is limited to multi-tenant deployments where more than one account holds inbound resources; no public exploit code has been identified at time of analysis and EPSS is low (0.20%, ~10th percentile), so mass scanning is unlikely, though the flaw is trivially reachable by any legitimate panel account.
Permanent destruction of an entire group's inventory in HomeBox is possible for any authenticated user who belongs to that group, due to a broken authorization check in the wipe-inventory action handler affecting versions prior to 0.26.0. The flaw lets a self-registered user - who is automatically flagged as a global owner of their own group - select a different group via the X-Tenant header and invoke POST /v1/actions/wipe-inventory against it, deleting data that cannot be recovered without external backups. Exploitation requires an authenticated account on a multi-group instance where the attacker is also a legitimate member of the victim group, so single-user or single-group deployments are not affected; no public exploit identified at time of analysis.
Cross-tenant record tampering in HomeBox versions prior to 0.26.0 allows an authenticated low-privileged user to overwrite or permanently delete another group's maintenance entries by supplying a maintenance-entry UUID that belongs to a different tenant. The flaw is a CWE-639 broken object-level authorization (IDOR) in the maintenance-entry update and delete repository paths, which act on the caller-supplied ID without confirming the record belongs to the caller's active group; exploitation requires a valid session plus knowledge of a non-enumerable random UUID, so it is access-gated rather than trivially reachable and is practically limited to multi-group/multi-tenant deployments. Impact is blind write/delete only with no data disclosure, and there is no public exploit identified at time of analysis and no indication of active exploitation. Vendor-released patch: 0.26.0.
HomeBox versions prior to 0.26.0 allow an authenticated low-privilege user to read and overwrite another tenant's notification configuration via PUT /v1/notifiers/{id}, exposing plaintext Shoutrrr credentials (Slack, SMTP, Telegram, Pushover, Discord) that are stored inside the notifier URL. The primary assessed impact is credential disclosure (high confidentiality), with a more limited integrity impact from the ability to point the victim's notifications at an attacker-controlled webhook. Exploitation requires a multi-tenant HomeBox deployment, a valid account, and knowledge of the victim's notifier UUID - UUIDs are not enumerable, which is the main real-world limiting factor; no public exploit has been identified at time of analysis, and the vendor fixed the issue in 0.26.0.
Authenticated command injection in KubeEdge (1.21.0 up to 1.21.2, 1.22.2, and 1.23.1) lets a principal holding Kubernetes RBAC rights to create or modify ConfigUpdateJob resources inject shell metacharacters into the updateFields passed to the keadm config-update command, which the edge taskmanager then runs through a system shell, yielding arbitrary command execution on the enrolled target edge node with the privileges of the KubeEdge process. The vendor rates this 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), and our independent assessment is slightly more severe because compromise of the node process is a scope change (S:C); the PR:L vector confirms the attacker must be authenticated and authorized, so this is not anonymous or remotely unauthenticated abuse. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, but the flaw is a genuine, actionable CWE-78 issue rather than an inflated score, and it is fixed in KubeEdge 1.21.2, 1.22.2, and 1.23.1.
Shell command injection in KubeEdge's v1alpha2 NodeUpgradeJob upgrade workflow allows an authenticated user who holds RBAC permission to create or update NodeUpgradeJob resources to run arbitrary commands on targeted edge nodes with the privileges of the edge upgrade process. Affected deployments are those running KubeEdge 1.12.0 through 1.21.1, 1.22.0/1.22.1, or 1.23.0 that actually process node-upgrade tasks; the vulnerability is high-priority and genuine rather than a CVSS-inflated finding, but it is gated on the NodeUpgradeJob create/update privilege (PR:L, not anonymous) so it is not reachable by unauthenticated users or on clusters that do not grant that permission. No public exploit code and no confirmed active exploitation were identified at time of analysis; EPSS/KEV data were not supplied for this CVE. Vendor-released patches exist in 1.21.2, 1.22.2, and 1.23.1.
KubeEdge keadm releases from 1.16.0 before 1.21.2, 1.22.2, and 1.23.1 contain a path traversal in DecompressTarGz that, on Windows edge nodes, can extract archive entries with parent-directory sequences, backslashes, absolute paths, or drive prefixes outside the intended destination. Exploitation requires the operator to run keadm join or installation using an archive obtained from a compromised, replaced, or untrusted download source, making this primarily a supply-chain trust-boundary bug rather than an attack against official artifacts. No public exploit was identified at time of analysis, and vendor fixes are released in 1.21.2, 1.22.2, and 1.23.1.
Authorization bypass in Tinyauth releases prior to 5.1.2 allows an authenticated, low-privilege user to reach applications whose per-app access controls are configured to exclude them. Tinyauth matches forwarded hostnames case-sensitively in lookupStaticACLs/GetAccessControls and in the Docker-label fallback (GetLabels), while nginx, Traefik, and Caddy route hostnames case-insensitively; requesting the target app with a differently-cased hostname therefore misses the configured policy, returns an empty access-control object, and proxyHandler treats the empty user/group/OAuth/LDAP/IP restrictions as permissive. Exploitation requires valid low-privilege credentials (CVSS PR:L) and a deployment that enforces per-app ACLs behind a case-insensitive proxy; unauthenticated visitors are still stopped at login and global login-time allowlists are not bypassed. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released fix is version 5.1.2.
Account fixation in Hatchet's OAuth callback handling lets an unauthenticated attacker bind a victim's existing Hatchet session to an OAuth identity the attacker controls, achieving login CSRF and account takeover. The flaw affects Hatchet versions prior to 0.91.1 and is only reachable when the deployment has enabled at least one OAuth integration (auth.google.enabled, auth.github.enabled, or the Slack integration) and the victim has already completed an OAuth flow in the current browser session; exploitation still requires victim interaction (the victim's browser must follow the attacker's crafted callback URL containing an empty state parameter and the attacker's own authorization code). The vendor-released patch is version 0.91.1 (upstream commit f90464189ad642251e09412d0f99fde353036428); there is no indication of confirmed active exploitation (no CISA KEV listing) and no public exploit code identified at time of analysis, although the upstream fix ships an integration test that documents the bypass chain.
OpenBao versions prior to 2.6.0 fail to reject syntax-significant characters when templated identity data is substituted into ACL, PKI, and SSH policies, allowing an authenticated principal who can write that identity data to broaden path matching, obtain certificates for unauthorized domains, or add unauthorized SSH principals. Exploitation is gated on a non-default configuration: the policy must use templates that substitute attacker-modifiable identity metadata (for example {{identity.entity.metadata.domains}} or {{identity.entity.metadata.sans}}), and the attacker must already hold the capability to update that identity record (such as update on identity/entity), consistent with the assessed CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N. Deployments whose templates rely solely on the randomly generated identity.entity.id value are not affected, there is no user interaction, and no public exploit code was identified at time of analysis.
Unauthenticated administrator account creation in nginx-ignition affects deployments running versions prior to 2.41.1 that are still in their pre-onboarding state. The endpoint POST /api/users/onboarding/finish is registered as anonymous and, because its "onboarding already completed?" check is not atomic with the subsequent user write, a remote unauthenticated attacker (CVSS 3.1 vector: AV:N/AC:H/PR:N/UI:N, base 8.1) who can reach such an instance can create a full ReadWrite administrator account for themselves, and concurrent requests can create multiple admin accounts in a single race. No public exploit identified at time of analysis, and the practical window is narrow: exploitation requires the instance to be network-reachable while deployed but before a legitimate operator has completed onboarding - once onboarding is legitimately finished, the path is guarded.
Unauthenticated denial of service in nginx-ignition 2.29.0 through 2.40.0 lets any remote client that can reach the management API burn roughly 2.4 seconds of server CPU per request by sending a GET whose Accept-Language header is built from underscore-separated malformed language tags, since the gin i18n middleware parses the raw header unconditionally with no size or shape limit. Impact is availability-only (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): ten concurrent attackers saturate a ten-core host for the duration of the attack while consuming about 10 MiB/s of upstream bandwidth, with no path to data access or code execution. No public exploit code identified at time of analysis and no CISA KEV entry; the vendor-released patch 2.40.1 fixes the issue.
Signature verification bypass in Red Hat's openshift/oc-mirror tool allows an attacker who can intercept or manipulate traffic to the release-signature endpoint to have a forged PGP-signed release payload accepted and mirrored into a disconnected OpenShift 4 registry. The defect (CWE-347) causes oc-mirror to evaluate signature errors before the full signed body has been processed, so a message carrying a legitimate Red Hat release key ID but an invalid signature can pass validation during a normal mirror operation. Exploitation is gated by a demanding precondition: the attacker must already hold a man-in-the-middle/on-path position on the network path and the victim must be actively running an oc-mirror signature-verifying operation; no credentials against oc-mirror are required (PR:N) and no user interaction beyond running the mirror process is needed (UI:N). The realistic impact is integrity-only, since the assessed vector scores C:N/I:H/A:N, and no public exploit has been identified at time of analysis.
Temporal Server releases 1.30.0 and later let an authenticated caller holding write permission in only one namespace trick the server into issuing attacker-chosen, state-changing HTTP POSTs against its own administrative frontend API, enabling cross-namespace workflow termination, namespace registration, configuration tampering, and full namespace deletion. The caller exploits confused-deputy logic (CWE-807) by attaching a Workflow completion callback whose URL passes the configured address allowlist and whose header map contains a non-empty 'source' header, which the History service interprets as evidence the callback is internal; no network access to the internal frontend is required because the server makes the request itself. Releases 1.25.0 through 1.29.7 carry the same defect but require the 'source' header to exactly match a configured cluster-ID UUID that a namespace-scoped caller cannot read through the API, making exploitation materially harder; no public exploit code was identified at time of analysis, and exploitation is gated on non-default deployment settings. Vendor-released patches exist in 1.30.7, 1.31.3, and 1.32.0.
Unauthenticated network peers that can reach a live Ringpop TChannel/SWIM gossip listener can drive memory and gossip-bandwidth exhaustion in github.com/temporalio/ringpop-go, because peer-supplied label maps are retained and re-disseminated without being checked against the application's configured LabelOptions limits. Applications that use ringpop's label feature are affected; repeated membership changes for distinct member addresses carrying oversized label keys, values, or counts inflate the member list and propagate to the whole cluster, degrading and potentially taking down the hosting process (availability only, no confidentiality or integrity impact). Exploitation requires network reachability to the gossip/TChannel port - typically an internal cluster interface - and there is no public exploit identified at time of analysis, though the assessed severity (CVSS 3.1 base 8.7, PR:N, A:H) makes the exposure of that port the decisive risk factor.
Unauthenticated remote denial of service in github.com/temporalio/tchannel-go (the Go implementation of the TChannel RPC protocol) before v1.22.1 lets any network peer that can complete the standard TChannel initialization handshake crash the hosting process. A crafted call fragment that carries checksum metadata but contains no length-prefixed argument chunks leaves the fragment reader's chunk slice empty, and the unconditional selection of the first element triggers an unrecovered Go slice-bounds panic on a library-created dispatch goroutine, terminating the process. There is no confidentiality or integrity impact, exploitation requires network reachability to a TChannel listener exposed to untrusted peers, and no public exploit code was identified at time of analysis (not confirmed actively exploited / not in CISA KEV); the assessed CVSS:3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
Denial of service in Temporal Server stems from uncontrolled recursion (CWE-674) in the bundled temporalio/sqlparser library: SQL containing deeply nested unary expressions is accepted and produces a correspondingly deep abstract syntax tree, and the library's recursive String and Walk traversals then exhaust the Go stack and abort the process in a way that Go panic recovery cannot contain. Affected are Temporal Server deployments prior to v1.30.7 and v1.31.3 that pass caller-controlled query text to the parser through the archival, visibility, and worker-query paths, including validation code that recursively formats an invalid expression while constructing an error. Exploitation requires an authenticated caller holding namespace read permission (the published CVSS 4.0 vector lists PR:N, but the reported prerequisites specify an authenticated caller and the independent assessment scores PR:L), the dynamically confirmed ListWorkers route additionally requires at least one retained worker heartbeat, and repeated requests can sustain the outage; impact is availability-only and no public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in Temporal Server allows an authenticated caller holding at least namespace read permission to crash the receiving Matching process by submitting a malformed MySQL version comment through the ListWorkers API when that API is enabled. The root cause is in the bundled temporalio/sqlparser Go library, where ExtractMysqlComment fails to validate the -1 returned by strings.IndexFunc before using it as a slice boundary, producing an unhandled Go runtime panic whenever a '/*! ... */' comment has empty contents or one to five decimal digits. Impact is availability-only (process termination, repeatable to sustain an outage) with no confidentiality or integrity effect; no public exploit identified at time of analysis, and exploitation is gated on both API enablement and authenticated namespace read access.
CPU exhaustion in Temporal Server before v1.30.7 and v1.31.3 allows an authenticated caller holding namespace write permission (PR:L) to persist a Schedule whose fine-grained cadence is fully negated by an exclusion calendar, forcing the next-action-time search to evaluate excluded candidates without any per-search work budget and burning CPU in the Frontend and Schedule worker components. Because the abusive specification is stored, consumption continues through repeated backing-Workflow failures and retries even after the initial request finishes, until the Schedule is deleted or its backing Workflow terminated; repeated or parallel Schedules can degrade or deny service to shared infrastructure. The impact is availability-only with no exposure or modification of Workflow data, no public exploit code has been identified at time of analysis, and vendor-released patches are available in v1.30.7 and v1.31.3. This is a genuine but bounded availability issue whose severity is highest in multi-tenant clusters where one namespace's write access can degrade shared Frontend and Schedule-worker capacity.
Replayed TOTP passcodes stay valid in mayswind ezBookkeeping before 2.0.0, so an attacker who already holds a victim's valid primary credentials and has captured a live TOTP code can resubmit that same code against the two-factor authorization or OAuth2 callback endpoint instead of being rejected after its first use. The window of abuse is bounded by the server's TOTP acceptance period (roughly 90 seconds, reflecting adjacent 30-second time steps), and only accounts with TOTP-based two-factor authentication enabled on pre-2.0.0 releases are exposed; interception must happen in real time via a phishing proxy, MITM position, or direct observation. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:R (7.6), and although PR:N indicates no privileges are required on the vulnerable component, practical exploitation presupposes stolen credentials plus a captured code, so this is a conditional weakness rather than a default-install compromise - no public exploit identified at time of analysis, and the vendor fixed it in 2.0.0.
Cross-scope secret disclosure in Perses (versions 0.43.0 through 0.54.0-rc.0) allows an authenticated user holding only GlobalDatasource:create or a project-level datasource-creation right to attach a project or global Secret they are not permitted to read to a datasource they control, causing Perses to forward the decrypted secret in plaintext to an attacker-operated endpoint. Exploitation requires an account with datasource-create permission in a deployment where Datasource and Secret scopes are separately granted, plus the ability to point the datasource at attacker-controlled infrastructure; the vendor fix enforces a Secret read-permission check on both the datasource-creation service and the unsaved-datasource proxy paths, and older releases can be fully protected by creating datasources via provisioning and revoking the datasource-create right. No public exploit code has been identified at time of analysis, and there is no indication of active exploitation (CISA KEV).
Authenticated users holding only viewer rights on a single project can read the dashboards, datasources, and variables of every other project in Perses deployments prior to 0.54.0-beta.3, by overriding the project in scope with a client-supplied 'project' query parameter on project-scoped list endpoints. Exploitation requires a low-privilege authenticated account (PR:L), needs no user interaction or non-default configuration, and yields read-only cross-tenant disclosure of full resource specifications rather than any modification. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor-released fix is version 0.54.0-beta.3.
Ultraviolet CoCoS through version 0.8.2 contains a session-misbinding flaw in the intra-handshake attested TLS (aTLS) verification path for Intel TDX: the verifier fails to copy the expected current-session freshness value into the TDX quote-body policy before quote validation, so any structurally valid TDX QuoteV4 Evidence is accepted without checking that its REPORT_DATA field matches the reportData expected for that session. An unauthenticated remote counterparty (CVSS vector AV:N/PR:N) that can supply or relay such a quote - acting as the attesting party or replaying a previously captured or foreign quote - can therefore cause a relying party to release application data bound to an unintended attestation context, giving high confidentiality and integrity impact. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the vendor's 9.1 score (AV:N/AC:L) slightly overstates ease of exploitation versus our assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, since a valid TDX quote and use of the affected TDX aTLS branch are prerequisites. The issue is fixed in version 0.9.0.
An attestation-freshness and origin-validation failure in the aTLS AMD SEV-SNP verification path of Cocos AI (Ultraviolet) affects versions up to and including 0.8.2: when a relying party invokes the intra-handshake verification path with no expected reportData value (nil, empty, or omitted), the SEV-SNP policy ReportData is left unset and the verifier will accept unrelated or stale Evidence that is not bound to the current TLS connection. An attacker who possesses a valid but foreign or replayed SEV-SNP attestation blob can therefore induce a trusting party to accept an unintended attestation context, undermining the core trust guarantee of the confidential-computing platform and potentially enabling both integrity and confidentiality compromise in any workflow where aTLS output drives a trust or authorization decision. Exploitation is unauthenticated at the network layer (CVSS PR:N) but constrained by high attack complexity and specific prerequisites - the caller must omit the expected reportData, and only SEV-SNP aTLS deployments up to 0.8.2 are exposed; no public exploit code or confirmed active exploitation has been identified at time of analysis. The issue is fixed in version 0.9.0.
zot container registry versions prior to 2.1.18 mis-map the HTTP DELETE method to the "push" scope action in its bearer authentication handler, so an authenticated client holding a token scoped only to pull and push can delete manifests and blobs inside that token's repository scope. Because bearer-authenticated requests also skip the fine-grained DistSpecAuthzHandler and the DeleteManifest/DeleteBlob handlers perform no independent permission check, no delete authorization is ever required; the attacker can make images unavailable and alter repository history (CWE-285, CVSS 8.1). Exploitation requires the registry to be configured for bearer/JWT authentication and the attacker to already possess a valid, unexpired token covering the target repository - no public exploit code has been identified at the time of analysis, and the flaw is fixed in 2.1.18.
Capsule, the Kubernetes multi-tenancy and policy framework (projectcapsule/capsule), mishandles case-insensitive sorting in its forbidden-list lookup on versions prior to 0.13.7, allowing an authenticated tenant owner to slip denied metadata keys past api.ValidateForbidden and bypass configured namespace, Service, or delegated node metadata restrictions - potentially altering cluster policies, network exposure, or pod scheduling outside the tenant boundary. Exploitation is conditional: the cluster administrator's forbidden list must mix capitalized and lowercase keys (or otherwise produce different case-insensitive and byte-order sortings), which is why the assessed vector is AV:N/AC:H/PR:L with scope change and high integrity impact. The flaw maps to CWE-697 (Incorrect Comparison), and no public exploit code or confirmed in-the-wild activity has been identified at time of analysis; a vendor fix is available in 0.13.7.
Cross-tenant credential disclosure in Convoy (frain-dev/convoy) prior to version 26.6.8 lets an authenticated user or project-scoped API key holder read another tenant's Source record - including unredacted AMQP, Kafka, SQS, and Google PubSub broker credentials - by substituting a foreign Source identifier in GET /api/v1/projects/{projectID}/sources/{sourceID}. The endpoint correctly authorizes the project in the URL but Handler.GetSource resolves the Source purely by sourceID, so the object-level ownership check is missing (IDOR/BOLA, CWE-639). Exploitation requires only a low-privilege authenticated credential (CVSS:4.0 PR:L, CVSS:3.1 PR:L) plus knowledge or enumeration of the target Source UID; the list endpoint remains properly project-scoped and is not affected. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and a vendor-released patch is available in 26.6.8.
Cross-workspace impersonation and complete authorization bypass in kcp (kcp-dev) before 0.31.4 and 0.32.x before 0.32.2 let any authenticated tenant forge Kubernetes-style identity headers that the shard accepts as trusted authentication assertions. Because the front-proxy and the server localproxy forward inbound X-Remote-User, X-Remote-Group, and X-Remote-Extra-* headers without clearing them, an attacker with valid credentials for any single workspace can supply values such as X-Remote-Group: system:masters, authorization.kcp.io/warrant, authentication.kcp.io/scopes, or a group used for per-workspace required-group gating to read, write, or delete resources, secrets, RBAC data, APIExports, APIBindings, and LogicalClusters across the installation. Exploitation requires authenticated access (CVSS vector PR:L, AV:N, no UI), yields changed scope per the vendor vector (CVSS 9.9), and no public exploit code or confirmed active exploitation was identified at time of analysis; fixed releases 0.31.4 and 0.32.2 are published.
Stack exhaustion in go-openapi/swag's jsonutils package before 0.27.1 allows unauthenticated remote attackers to crash any Go service that parses or serializes ordered JSON from untrusted input - most notably endpoints that accept OpenAPI specification documents or otherwise route attacker-controlled JSON through the ordered marshal/unmarshal path - by submitting a deeply nested document that recurses without any depth limit. The result is a fatal Go stack overflow that terminates the process and drops all in-flight requests; there is no data exposure or modification, so impact is confined to availability (CVSS 8.7, CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VA:H). No public exploit code has been identified at time of analysis and the flaw is not listed in CISA KEV, but exploitation requires only a single crafted request, so exposure should be treated as high for internet-facing services built on this library. The underlying defect is CWE-674 (uncontrolled recursion).
SQL injection in the SigNoz v5 query_range API (versions 0.87.0 through 0.141.x) lets authenticated users with the Viewer role or higher inject backticks and quotes into user-supplied telemetry field-key names, breaking out of ClickHouse identifier and string-literal contexts to execute arbitrary SQL. Successful exploitation allows cross-scope read access to ClickHouse system tables and exfiltration of telemetry data, with limited integrity impact; an attacker needs only valid low-privilege credentials and network access to the SigNoz API, with no user interaction or non-default configuration required. The issue is patched in SigNoz 0.142.0 per the vendor advisory (GHSA-q3h7-gpc9-2rxc), and no public exploit code was identified at time of analysis.
Improper validation of the Username argument in rcourtman Pulse's Quick Security Setup handler (/api/security/quick-setup) allows manipulation of the value passed into fmt.Sprintf in versions up to 6.0.4 and 6.1.0-rc.4, with the vendor scoring it 9.4 while VULDB tags the issue as information disclosure. The vendor CVSS 4.0 vector specifies PR:H, indicating a privileged/authenticated actor, yet quick-setup style endpoints are frequently reachable during initial unconfigured deployment before authentication is enforced, and this contradiction is unresolved in the available data. There is no public exploit identified at time of analysis and the CVE is not in CISA KEV, so practical risk is bounded by an unclear demonstrated impact rather than the headline score; analysis tags show no CPE strings, and reference material points to a vendor fix in release v6.1.0.
SAML SSO authentication bypass in SUSE NeuVector lets anyone who legitimately holds an account on another application behind the same corporate identity provider log into NeuVector without ever having been granted a NeuVector account. NeuVector's SAML service provider handler never validates the assertion's <Audience> element, so a bearer assertion minted for a wiki, ticketing system, or expenses tool is accepted verbatim; the internal NotInAudience warning is produced but never read, which is the CWE-287 improper-authentication root cause. Exploitation is not free - it requires SAML authentication to be enabled against an IdP shared with at least one other relying party and valid credentials in that same federation (PR:L, AT:P) - but it needs no NeuVector account, no admin rights, and no victim interaction, and it yields high confidentiality and integrity impact; there is no public exploit identified at time of analysis and no CISA KEV entry, so this is a high-priority authentication defect rather than a confirmed actively exploited one.
Session cross-wiring in SUSE NeuVector before 5.6.1 allows an unauthenticated remote attacker to obtain another user's authenticated console session when multiple SAML or OIDC SSO login attempts occur concurrently, effectively enabling account takeover of the container security console. Exploitation requires SSO to be enabled and a race condition against a legitimate user's simultaneous login, so it is not trivially automatable; an independent assessment rates it with high attack complexity and user interaction. Publicly available exploit code exists, but EPSS is low (0.24%, 15th percentile) and no active exploitation has been confirmed (CISA SSVC: exploitation none).
Server-side request forgery in Coze Studio through version 0.5.1 allows an authenticated user who can register or configure a plugin tool to supply an arbitrary server URL, causing the backend to issue HTTP requests to internal-only destinations on the attacker's behalf. The primary risk is confidentiality rather than code execution: responses from cloud metadata endpoints (for example 169.254.169.254) or other services reachable only from the backend network can be read back through the plugin mechanism, potentially exposing credentials, tokens, and internal service data. The issue is rated 7.1 in the CVSS 4.0 vector published with the CVE, while the independent assessment scores it as a credentialed SSRF (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) with no integrity or availability impact; no public exploit code was identified at time of analysis and no CISA KEV listing applies, so this is a moderate-priority, credentialed SSRF rather than a critical remote-takeover flaw.
Authorization bypass in GoAdmin through 1.2.26 allows any authenticated user with a valid session (CVSS PR:L - an account on the target instance is required) to reach administrative endpoints by appending a crafted query string containing the configured admin prefix followed by /logout to a request URL; the permission-checking middleware mistakes the request for the exempt logout route and skips authorization entirely. Successful exploitation permits unauthorized reads of sensitive data and modification of application state (C:H/I:H), with no user interaction needed in a default deployment. No public exploit code and no confirmed in-the-wild exploitation have been identified at time of analysis - the issue is tracked as EUVD-2026-81056 and reported by VulnCheck, and no vendor-released patch version is identified in the available data.
Authentication bypass in OpenNHP through 1.0.2 allows remote unauthenticated attackers to defeat trusted-execution attestation verification by supplying evidence that includes a test_purpose key, which forces the FallbackVerifier to execute unconditionally. Attackers must also provide enrolled measure and serial-number pairs that already exist in the allowlist, which is the primary real-world limiter on exploitability. No public exploit code was identified at time of analysis, and the issue is not listed in CISA KEV; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) indicates high confidentiality impact, though the raw CVSS 4.0 score of 8.7 slightly overstates unconditional trivial exploitability.
Unauthenticated path traversal in Uber Kraken through 0.1.29 allows remote attackers to read files outside the configured storage root via the /tags/{tag} endpoint when the testfs backend and build-index tagserver are exposed. Percent-encoded parent-directory segments in the tag parameter bypass path validation and disclose files readable by the testfs process account, yielding high confidentiality impact with no integrity or availability effect. No public exploit identified at time of analysis.
Improper authorization in Coze Studio through 0.5.1 lets an authenticated user (CVSS PR:L) abuse the workflow SQL customization node to reach memory-database tables belonging to other workspaces, because referenced table names are never validated against the caller's own workspace. By enumerating predictable table identifiers, the attacker can read, insert, or delete data in another tenant's memory database, yielding high confidentiality and integrity impact within the affected multi-tenant deployment (our assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Exploitation requires valid low-privilege credentials and a deployment hosting multiple workspaces on a shared memory-database backend; single-tenant installations have little to expose via this path. No public exploit code was identified at time of analysis, and there is no KEV confirmation of active exploitation.
Harbor through 2.15.2 can disclose scanner adapter AccessCredential secrets to an authenticated project administrator who abuses fuzzy q-parameter filtering and observes response row counts one character at a time. This is a privilege-gated confidentiality issue rather than a critical remote-takeover flaw: the attacker must already hold a project-admin role and must issue many sequential API requests, with no user interaction and no special feature toggle required in default configurations. Publicly available exploit code exists, and the supplied data does not confirm active exploitation by CISA KEV.
Authenticated users on Harness deployments through version 3.3.0 can read infrastructure provider configurations from spaces they do not belong to, because the GET /api/v1/infraproviders endpoint fails to validate space-level access control (CWE-862). Exploitation requires only a valid low-privilege account (CVSS v4.0 PR:L, and the independent assessment rates it PR:L as well), so it is realistic mainly on multi-tenant or multi-space instances where the attacker's account lives in a different space than the targeted provider records; a single-tenant instance with no untrusted users has limited exposure. The result is a confidentiality-only impact (VC:H, no integrity or availability effect) exposing sensitive provider metadata such as Docker endpoints, TLS certificate paths, and cloud project identifiers. No public exploit identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV). Note: the supplied CVSS v4.0 base score of 7.1 and the independent CVSS v3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) agree on the authenticated, network-reachable, read-only nature of the flaw.
Unauthenticated remote attackers can forge valid administrator session cookies for the Chaitin SafeLine management console (all versions through 9.4.1) because the session-signing secret is derived from a time-seeded math/rand generator (CWE-338) and can be reconstructed offline once the install timestamp is bounded. Successful exploitation yields full administrative control of the protected sites managed by that console, matching the 9.2 CVSS 4.0 rating and the independently assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H profile. Two prerequisites limit practical reach: the management console must be network-reachable from the attacker, and the attacker must be able to narrow the installation time enough to make the seed search feasible. No public exploit code and no confirmed in-the-wild exploitation were identified at the time of analysis, and consoles placed behind network segmentation, VPN, or IP allow-listing are not exposed to remote cookie forgery.