Monthly
MoLing's SSE server mode (enabled with the non-default -l/ListenAddr flag) exposes the /sse and /message HTTP endpoints without authentication, and the mcp-go dependency hardcodes Access-Control-Allow-Origin: * on /sse, so any web page the victim visits can open a cross-origin EventSource, read the endpoint event, extract the unauthenticated sessionId, and then post unauthorized MCP tool calls to /message. Impact is bounded by which MCP tools are configured but can include local file read/write and command execution, and the vendor notes that binding only to loopback does not stop this because the attack is browser-mediated from the victim's own machine. Versions before 0.5.0 are affected; 0.5.0 adds mandatory token authentication and strips the wildcard CORS header. Exploitation requires the victim to run SSE mode and visit an attacker-controlled page (UI:R); no public exploit code or confirmed active exploitation is identified in the available data, though the advisory includes a simplified proof-of-concept snippet, so a public PoC reference exists but is not verified as working exploit code. The priority decision label is act_now.
A permissive CORS misconfiguration in Transmission 4.0.0 through 4.1.2 exposes the RPC anti-CSRF token (X-Transmission-Session-Id) to any web origin, so a malicious page can read the token from the 409 handshake response and replay it to drive the RPC interface as the user. Successful replay allows settings tampering, download-directory changes and torrent or data deletion, and escalates to code execution where the script-torrent-done feature is usable, but only defeats the anti-CSRF check - an RPC password or an enabled IP whitelist blocks the replay. Exploitation requires the RPC web server (default port 9091) to be reachable from the victim's browser and the victim to visit the attacker's page; no KEV entry exists, EPSS is low at 0.53% (44th percentile), and a public researcher write-up with a PoC reference exists but is not verified here as working exploit code.
Account takeover in Vikunja 2.2.0 through 2.6.0 stems from a default CORS policy that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set, so a page served from any local port can call the token refresh endpoint and read the returned bearer JWT. The attack is conditional rather than mass-exploitable: the attacker must be able to host malicious content on the victim's own machine, and the victim must have an active authenticated session; it is not directly exploitable from an arbitrary external internet origin. No public exploit identified at time of analysis.
The RabbitMQ management plugin (rabbit_mgmt_cors.erl) reflects an attacker-controlled Origin header straight back in Access-Control-Allow-Origin while also returning Access-Control-Allow-Credentials: true, so when an operator has configured cors_allow_origins = "*" a hostile web page can make a signed-in administrator's browser issue authenticated, state-changing requests to the management HTTP API. Exploitation is conditional rather than automatic: it requires the non-default wildcard CORS setting, a live cached HTTP Basic-auth administrator session, and the administrator being lured to the attacker's page (user interaction), and no public exploit code has been identified at time of analysis; assessed severity is CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N. The issue affects the management plugin in RabbitMQ releases prior to 3.13.17, 4.0.22, 4.1.13 and 4.2.6.
Credentialed cross-origin reads and namespace takeover were possible against the hosted open-vsx.org registry because its CDN/edge layer reflected the requesting Origin back in Access-Control-Allow-Origin while simultaneously emitting Access-Control-Allow-Credentials: true on authenticated /user/ endpoints. A page on any origin could then issue credentialed requests in a logged-in user's browser and read the responses, exposing /user (login name, avatar, homepage, tokens URL), /user/tokens, /user/namespaces, /user/extensions, /user/search/{name}, /user/namespace/{name}/members and - critically - /user/csrf; with the CSRF token readable, the write-endpoint protection collapsed, and chaining /user/csrf with /user/token/create let the attacker page mint and exfiltrate a personal access token carrying publish and delete rights over the victim's namespaces. Attackers need no authentication of their own (CVSS 4.0 PR:N) and only passive victim interaction - the victim must be logged in to open-vsx.org and visit the attacker's page - while no public exploit code has been identified at time of analysis.
Cross-origin data exposure in RESTEasy's CorsFilter (CVSS 7.4) occurs when a deployment is configured with allowedOrigins set to the wildcard '*' together with allowCredentials=true, causing the filter to reflect the caller's Origin header back in Access-Control-Allow-Origin alongside Access-Control-Allow-Credentials: true. Because that configuration defeats the browser's built-in guard against combining wildcard origins with credentials, an attacker who lures an already-authenticated user (UI:R) to an attacker-controlled page can issue credentialed cross-origin requests and read that user's authenticated API responses - a confidentiality-only impact (C:H/I:N/A:N), with no integrity or availability effect. The prerequisite wildcard-plus-credentials CORS configuration is a non-default operator choice, and analysis identifies no public exploit identified at time of analysis.
Unauthenticated cross-origin RCE in Windows ML CLI (winml-cli < 0.4.0) is reachable when a developer runs the `serve` command, which exposes a localhost HTTP API with a wildcard CORS policy and no authentication gate. Any malicious webpage visited by the user while the server is running can send cross-origin requests to `/v1/cli/build` or `/v1/cli/config`, inject `trust_remote_code=true`, and cause the server to call `AutoConfig.from_pretrained(trust_remote_code=True)` - downloading and executing attacker-controlled Python code from a remote model repository as the server user. The vendor has released a fix in version 0.4.0; no public exploit is identified at time of analysis.
Cross-origin credential exposure in HeyForm before 3.0.0-rc.8 allows any attacker-controlled web page visited by a logged-in user to make fully authenticated GraphQL API requests against the HeyForm server. The server's default CORS configuration (`origin: true, credentials: true`) unconditionally echoed the request Origin header back as `Access-Control-Allow-Origin` while also asserting `Access-Control-Allow-Credentials: true`, defeating the browser's same-origin policy for all origins. This exposes workspaces, projects, forms, submissions, and respondent data to exfiltration and permits account settings modification; no public exploit has been identified at time of analysis.
CORS misconfiguration in Rybbit before 2.7.0 allows any attacker-controlled website to issue credentialed cross-origin requests to the Rybbit analytics server, because the server unconditionally reflects the request's Origin header in Access-Control-Allow-Origin while simultaneously enabling Access-Control-Allow-Credentials. Authenticated victims who visit a malicious page expose their analytics data, account information, and permit the attacker's script to perform state-changing API operations on their behalf. No public exploit has been identified at time of analysis, but the underlying attack class requires only standard browser Fetch API usage and is trivial to implement.
Permissive CORS misconfiguration in the Grav API Plugin (all versions prior to 1.0.0-rc.16) allows cross-origin JavaScript on any attacker-controlled website to submit a stolen JWT via Authorization or X-API-Token headers and read full authenticated API responses, enabling data exfiltration and account modification with the token owner's privileges. The wildcard Access-Control-Allow-Origin: * header was returned by default for all /api/v1 endpoints - including authenticated ones - bypassing browser Same-Origin Policy protections entirely. A secondary vector existed via URL query-string token acceptance (?token=) on general API routes, leaking JWTs into server logs and Referer headers where they could be harvested and then weaponized via the CORS bypass. No public exploit code has been identified at time of analysis, and no CISA KEV listing is present.
MoLing's SSE server mode (enabled with the non-default -l/ListenAddr flag) exposes the /sse and /message HTTP endpoints without authentication, and the mcp-go dependency hardcodes Access-Control-Allow-Origin: * on /sse, so any web page the victim visits can open a cross-origin EventSource, read the endpoint event, extract the unauthenticated sessionId, and then post unauthorized MCP tool calls to /message. Impact is bounded by which MCP tools are configured but can include local file read/write and command execution, and the vendor notes that binding only to loopback does not stop this because the attack is browser-mediated from the victim's own machine. Versions before 0.5.0 are affected; 0.5.0 adds mandatory token authentication and strips the wildcard CORS header. Exploitation requires the victim to run SSE mode and visit an attacker-controlled page (UI:R); no public exploit code or confirmed active exploitation is identified in the available data, though the advisory includes a simplified proof-of-concept snippet, so a public PoC reference exists but is not verified as working exploit code. The priority decision label is act_now.
A permissive CORS misconfiguration in Transmission 4.0.0 through 4.1.2 exposes the RPC anti-CSRF token (X-Transmission-Session-Id) to any web origin, so a malicious page can read the token from the 409 handshake response and replay it to drive the RPC interface as the user. Successful replay allows settings tampering, download-directory changes and torrent or data deletion, and escalates to code execution where the script-torrent-done feature is usable, but only defeats the anti-CSRF check - an RPC password or an enabled IP whitelist blocks the replay. Exploitation requires the RPC web server (default port 9091) to be reachable from the victim's browser and the victim to visit the attacker's page; no KEV entry exists, EPSS is low at 0.53% (44th percentile), and a public researcher write-up with a PoC reference exists but is not verified here as working exploit code.
Account takeover in Vikunja 2.2.0 through 2.6.0 stems from a default CORS policy that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set, so a page served from any local port can call the token refresh endpoint and read the returned bearer JWT. The attack is conditional rather than mass-exploitable: the attacker must be able to host malicious content on the victim's own machine, and the victim must have an active authenticated session; it is not directly exploitable from an arbitrary external internet origin. No public exploit identified at time of analysis.
The RabbitMQ management plugin (rabbit_mgmt_cors.erl) reflects an attacker-controlled Origin header straight back in Access-Control-Allow-Origin while also returning Access-Control-Allow-Credentials: true, so when an operator has configured cors_allow_origins = "*" a hostile web page can make a signed-in administrator's browser issue authenticated, state-changing requests to the management HTTP API. Exploitation is conditional rather than automatic: it requires the non-default wildcard CORS setting, a live cached HTTP Basic-auth administrator session, and the administrator being lured to the attacker's page (user interaction), and no public exploit code has been identified at time of analysis; assessed severity is CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N. The issue affects the management plugin in RabbitMQ releases prior to 3.13.17, 4.0.22, 4.1.13 and 4.2.6.
Credentialed cross-origin reads and namespace takeover were possible against the hosted open-vsx.org registry because its CDN/edge layer reflected the requesting Origin back in Access-Control-Allow-Origin while simultaneously emitting Access-Control-Allow-Credentials: true on authenticated /user/ endpoints. A page on any origin could then issue credentialed requests in a logged-in user's browser and read the responses, exposing /user (login name, avatar, homepage, tokens URL), /user/tokens, /user/namespaces, /user/extensions, /user/search/{name}, /user/namespace/{name}/members and - critically - /user/csrf; with the CSRF token readable, the write-endpoint protection collapsed, and chaining /user/csrf with /user/token/create let the attacker page mint and exfiltrate a personal access token carrying publish and delete rights over the victim's namespaces. Attackers need no authentication of their own (CVSS 4.0 PR:N) and only passive victim interaction - the victim must be logged in to open-vsx.org and visit the attacker's page - while no public exploit code has been identified at time of analysis.
Cross-origin data exposure in RESTEasy's CorsFilter (CVSS 7.4) occurs when a deployment is configured with allowedOrigins set to the wildcard '*' together with allowCredentials=true, causing the filter to reflect the caller's Origin header back in Access-Control-Allow-Origin alongside Access-Control-Allow-Credentials: true. Because that configuration defeats the browser's built-in guard against combining wildcard origins with credentials, an attacker who lures an already-authenticated user (UI:R) to an attacker-controlled page can issue credentialed cross-origin requests and read that user's authenticated API responses - a confidentiality-only impact (C:H/I:N/A:N), with no integrity or availability effect. The prerequisite wildcard-plus-credentials CORS configuration is a non-default operator choice, and analysis identifies no public exploit identified at time of analysis.
Unauthenticated cross-origin RCE in Windows ML CLI (winml-cli < 0.4.0) is reachable when a developer runs the `serve` command, which exposes a localhost HTTP API with a wildcard CORS policy and no authentication gate. Any malicious webpage visited by the user while the server is running can send cross-origin requests to `/v1/cli/build` or `/v1/cli/config`, inject `trust_remote_code=true`, and cause the server to call `AutoConfig.from_pretrained(trust_remote_code=True)` - downloading and executing attacker-controlled Python code from a remote model repository as the server user. The vendor has released a fix in version 0.4.0; no public exploit is identified at time of analysis.
Cross-origin credential exposure in HeyForm before 3.0.0-rc.8 allows any attacker-controlled web page visited by a logged-in user to make fully authenticated GraphQL API requests against the HeyForm server. The server's default CORS configuration (`origin: true, credentials: true`) unconditionally echoed the request Origin header back as `Access-Control-Allow-Origin` while also asserting `Access-Control-Allow-Credentials: true`, defeating the browser's same-origin policy for all origins. This exposes workspaces, projects, forms, submissions, and respondent data to exfiltration and permits account settings modification; no public exploit has been identified at time of analysis.
CORS misconfiguration in Rybbit before 2.7.0 allows any attacker-controlled website to issue credentialed cross-origin requests to the Rybbit analytics server, because the server unconditionally reflects the request's Origin header in Access-Control-Allow-Origin while simultaneously enabling Access-Control-Allow-Credentials. Authenticated victims who visit a malicious page expose their analytics data, account information, and permit the attacker's script to perform state-changing API operations on their behalf. No public exploit has been identified at time of analysis, but the underlying attack class requires only standard browser Fetch API usage and is trivial to implement.
Permissive CORS misconfiguration in the Grav API Plugin (all versions prior to 1.0.0-rc.16) allows cross-origin JavaScript on any attacker-controlled website to submit a stolen JWT via Authorization or X-API-Token headers and read full authenticated API responses, enabling data exfiltration and account modification with the token owner's privileges. The wildcard Access-Control-Allow-Origin: * header was returned by default for all /api/v1 endpoints - including authenticated ones - bypassing browser Same-Origin Policy protections entirely. A secondary vector existed via URL query-string token acceptance (?token=) on general API routes, leaking JWTs into server logs and Referer headers where they could be harvested and then weaponized via the CORS bypass. No public exploit code has been identified at time of analysis, and no CISA KEV listing is present.