Loading story…
Mockoon disclosed and fixed CVE-2026-59148, a high-severity flaw affecting versions before 9.7.0 that exposed its Admin API on the same Express listener as user-defined mock routes without authentication. Combined with wildcard CORS and permitted write methods, the issue allowed remote attackers who could reach the mock server port to read MOCKOON_* environment variables, alter mock route bodies, headers, and status codes, access transaction logs and SSE streams, and purge application state. The vulnerability carries a CVSS 8.8 rating and is tied to missing authentication, CSRF risk, improper permission controls, and permissive cross-domain policy weaknesses.
The fix shipped in Mockoon 9.7.0 through a broader Admin API security hardening update. The changes introduced mandatory bearer-token protection for the Admin API, support for --admin-api-token and MOCKOON_ADMIN_API_TOKEN, automatic secure token generation when none is supplied, configurable CORS allowlisting, and stricter controls on environment-variable writes so empty prefixes are rejected and arbitrary variable modification is blocked. The update also expanded redaction of sensitive headers and values in logs and Admin API responses, while documenting that the Admin API remains enabled by default at /mockoon-admin/ but can be disabled.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
On 2026-07-09, CVE-2026-59148 was published describing a high-severity Mockoon vulnerability affecting versions prior to 9.7.0. The issue allowed remote attackers reaching the mock server port to access MOCKOON_* environment variables, alter mock routes and responses, view logs and SSE streams, and purge application state.
On 2026-06-18, Mockoon published release v9.7.0. Reference content indicates this version contains fixes for the exposed unauthenticated Admin API, permissive CORS behavior, and unsafe environment-variable handling.
On 2026-06-18, Mockoon merged pull request #2254 into main, adding bearer-token authentication for the Admin API, configurable CORS allowlisting, enforced environment-variable prefixing for admin writes, and broader redaction of sensitive values.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcegithub.com
Open sourcegithub.com
Open sourcemockoon.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Blinko, an AI-powered card note-taking project, patched two high-severity vulnerabilities in version `1.8.4` after GitHub security advisories disclosed that earlier releases were vulnerable to both arbitrary file read and remote code execution. The first issue, tracked as `CVE-2026-23482`, affects the `/api/file/temp` endpoint, which failed to enforce permission checks and did not block path traversal, allowing unauthorized attackers to read arbitrary files from the server. Where scheduled backups were enabled, exposed backup files could reveal all user notes and user tokens. A second flaw, `CVE-2026-23882`, allowed OS command injection in Blinko's MCP server creation workflow. In versions before `1.8.4`, the connection-testing function accepted arbitrary commands and arguments and executed them, creating an admin-level remote code execution path mapped to `CWE-78`. The combined disclosures show that unpatched Blinko instances faced risks to confidentiality, integrity, and availability, with fixes released through the project's `1.8.4` update and associated code commits.
Jun 29, 2026
A high-severity vulnerability tracked as **CVE-2026-49948** affects self-hosted **Mem0** deployments through version `0.2.8`, allowing any authenticated user to modify global settings through the `POST /configure` endpoint. The flaw stems from missing authorization checks: the server accepts a valid JWT or distributed `X-API-Key` but does not verify the caller’s role before permitting changes to the instance-wide LLM provider and embedder configuration. An attacker with low privileges can use the weakness to redirect all LLM and embedding traffic for the instance to an attacker-controlled server, exposing sensitive data and enabling broad integrity compromise across all users and API keys. The malicious configuration is stored in PostgreSQL and survives restarts, making the change persistent until corrected. The issue is classified as **CWE-862** and was fixed in commit `ae7f406`.
Jun 29, 2026
RabbitMQ fixed a high-severity information disclosure vulnerability, **CVE-2026-57219**, that could let unauthenticated attackers retrieve OAuth 2 client secrets through the obsolete management API endpoint `GET /api/auth`. The issue affects deployments with the management plugin enabled and `management.oauth_client_secret` configured in certain less common OAuth 2 setups. Affected versions are `>= 3.13.0 and < 3.13.15`, `>= 4.0.0 and < 4.0.21`, `>= 4.1.0 and < 4.1.11`, and `>= 4.2.0 and < 4.2.6`; the flaw is rated **CVSS 4.0 8.7** and is classified under **CWE-200**. The vendor addressed the exposure in RabbitMQ `3.13.15`, `4.0.20`, `4.1.11`, and `4.2.6`. RabbitMQ `4.2.6` was released as a maintenance update with broader security-relevant hardening, including improved permission enforcement, access control, API behavior, WebSocket safety limits, login timeout handling, origin validation, and protections against excessive CPU and memory consumption from malformed inputs. The release also removed the deprecated unused API endpoint tied to the disclosure risk and reduced exposure of sensitive connection URI data in shovel status output, with users advised to upgrade and verify supported Erlang versions before deployment.
Jul 11, 2026