CVE WatchOct 19, 2026

CVE-2026-108372

Open and provider-neutral, LoopX is a lightweight state kernel and local-first control plane for loop engineering. From version 0.0.1 until

CVSS

—

No CVSS

EPSS

0.2%

p12

KEV

—

Exploit Today

0-100

Published: Oct 16, 2026 · Last modified: Oct 19, 2026 · CWE-346 · CWE-942

EPSS · 30d

0.2%EPSS · 30 days0.2%

2026-10-172026-10-19

Technical description

Open and provider-neutral, LoopX is a lightweight state kernel and local-first control plane for loop engineering. From version 0.0.1 until 0.4.5, `loopx serve-status` in `loopx/status_server.py` uses `StatusRequestHandler._send_json()` and `do_OPTIONS()` to send `Access-Control-Allow-Origin: *` for unauthenticated responses on predictable loopback ports. A remote attacker can cause an operator who visits attacker-controlled web content to issue cross-origin requests to `GET /status.json`, `GET /review-material?goal_id=...&path=...`, `GET /`, and `POST /control-plane/configure-goal/dry-run`, exposing control-plane state, goal and run information, local absolute paths, private Markdown files below registered goal roots, and dry-run configuration projections. The affected routes do not provide cross-origin writes or arbitrary-file access. This issue is fixed in version 0.4.5.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-33033.7 LOW

—

——0IBM Concert 1.0 through 3.0.0 uses cross-origin resource sharing (CORS) which could allow an attacker to carry out privileged actions as the domain name is not being limited to only trusted domains.18h CVE-2026-1123777.4 HIG

—

——0CCC Attestation SIG attested-tls-poc through commit 731ca82 fails to bind early attestation Evidence to the TLS connection, allowing attackers to relay valid Evidence from a genuine attester. Attackers holding an extracted attested TLS private key can forward the relying party's nonce to a genuine attester and replay its Evidence to impersonate the attested workload and intercept data.18h CVE-2026-853134.3 MED

—

——0Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Jetty component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. Setting enableCORS on a Jetty endpoint installed Jetty's CrossOriginFilter with its stock defaults, which accept every origin and allow credentials. An operator asking for CORS therefore obtained a policy that lets a page on any origin make credentialed cross-origin requests to the endpoint and read the responses, without any indication that turning the option on had chosen an allow-all policy rather than an empty one to be filled in. This is the same defect class as the platform-http-vertx advisory published alongside it, in a different component. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. enableCORS no longer grants credentials to an origin the operator did not name. A deployment that relied on any origin being accepted must now list its origins explicitly. For deployments that cannot upgrade immediately, configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs, naming the allowed origins.18h CVE-2026-841766.5 MED

—

——0Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Platform HTTP Vertx component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. createCorsHandler() set Access-Control-Allow-Credentials: true outside the origin check, so the header went out on every response to a request carrying an Origin header, including responses to origins the handler had just decided not to allow. When camel.server.cors.origins is unset, the handler treats every origin as allowed and echoes the caller's own Origin back as Access-Control-Allow-Origin. Together those produce the credentialed any-origin configuration that the fetch specification refuses to express as a literal wildcard, which is precisely why reflecting the origin is the usual way around that rule. A page on any origin could therefore make credentialed cross-origin requests to the Camel endpoint and read the responses. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Access-Control-Allow-Credentials is now sent only when the request origin matched an origin the operator actually configured. With no origin list the origin is still reflected, as before, but credentials are not granted, and Vary: Origin is now set whenever the origin is reflected so that a shared cache cannot serve one origin's response to another. For deployments that cannot upgrade immediately, set camel.server.cors.origins to the explicit list of origins that need access rather than leaving it unset.18h CVE-2026-1121014.3 MED

—

——0A vulnerability was determined in BlackBeltTechnology pi-agent-dashboard up to 0.8.0. The affected element is an unknown function of the file /BlackBeltTechnology/pi-agent-dashboard of the component WebSocket Gateway. Executing a manipulation of the argument cwd can lead to origin validation error. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 0.9.0 is sufficient to fix this issue. This patch is called 48fd0bad5adfe76af9736599699d51a5f60019f6. It is recommended to upgrade the affected component.22h CVE-2026-1119226.3 MED

0.8%

——0Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.18h