A vulnerability in the MCP TypeScript SDK versions 1.24.0 through before 1.32.0 allowed clients sharing an InMemoryTaskStore to access and manipulate each other's tasks due to missing session ownership checks. This authorization bypass issue was fixed in version 1.32.0.
ApostropheCMS versions prior to 4.33.0 have a vulnerability where an unauthenticated user can access the GET /api/v1/<piece-type>/:_id/locales REST route without proper authorization checks. This allows the user to determine if a document exists and which locales it is published in, exposing sensitive metadata that should be restricted. The issue is fixed in version 4.33.0.
ApostropheCMS versions prior to 4.33.0 have a vulnerability in the notification module where PATCH and DELETE REST endpoints allow unauthenticated users to modify or delete notifications by using a valid notification ID. This occurs because the endpoints do not verify authentication or ownership of the target notification. The issue is fixed in version 4.33.0.
ApostropheCMS versions prior to 4.33.0 contain a missing authorization vulnerability in the exist-in-locale API. This flaw allows authenticated users with low privileges to detect the existence of restricted documents in specific locales and modes, including draft mode, without proper document-level authorization checks. The issue is resolved in version 4.33.0.
ApostropheCMS versions prior to 4.34.0 and import-export module versions prior to 3.7.1 contain a missing authorization vulnerability. An editor with import permissions but lacking stronger publication roles can improperly create, replace, or remove published content variants without the usual publish permission and lifecycle checks. This flaw allows unauthorized modification of published content through import write helpers. The issue is resolved in ApostropheCMS 4.34.0 and import-export 3.7.1.
ApostropheCMS versions prior to 4.33.0 contain an authorization bypass vulnerability allowing authenticated editors with edit rights on a page to reorder sibling pages under a restricted parent without having create authorization on that parent. This bypass is limited to sibling ordering and does not allow arbitrary content modification, confidentiality loss, or creation of restricted nesting. The issue is fixed in version 4.33.0.
ApostropheCMS versions prior to 3.7.1 and 4.34.0 have a missing authentication vulnerability in the import-export module. The API endpoint POST /api/v1/@apostrophecms/import-export/clean-export lacks authentication and authorization checks, allowing any client, including unauthenticated users with a standard CSRF cookie, to invoke a critical function. This issue is fixed in versions 3.7.1 and 4.34.0.
A missing authorization vulnerability in apostrophecms apostrophe allows editor-level users to bypass type-level and field-level access controls on the `getOne` REST endpoint for pages. While the `getAll` endpoint correctly enforces `viewRole` and `viewPermission` restrictions, the `getOne` endpoint does not, enabling editors who know a document ID to access admin-only pages and privileged fields.
CVE-2026-94023 is an out-of-bounds read vulnerability in Eclipse Foundation's Eclipse ThreadX affecting versions 6.0.1 through 6.5.1.202602a. The flaw arises because a ThreadX module can request deletion of kernel objects it does not own by exploiting the Module Manager's dispatch layer, which only checks if the object lies outside the module's code and data. This improper validation allows a module to delete objects created by other modules, violating intended sharing policies.
Draft text for GHSA-qw47-mcm5-934w. The body below drops into the GitHub advisory description
field; the metadata block maps to the form fields. Set the patched version at release; publish
when the fix ships._
---
- **Ecosystem:** Maven
- **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (task store / authorization)
- **Affected versions:** `<= 1.2.0.Final` (and `1.2.1.Final-SNAPSHOT` on `main` prior to the fix)
- **Patched version:** _(the release that carries the fix, e.g. 1.2.1.Final)_
- **CWE:** CWE-1188 (Insecure Default Initialization), CWE-862 (Missing Authorization)
- **Severity:** High
- **CVSS v3.1:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` (7.5, High)
---
## Details
The default task store performs no authorization on task reads. `InMemoryTaskStore`'s no-arg
constructor sets `authorizationProvider = null`, and `InMemoryTaskStore.get(String taskId)` is a
bare map lookup with no authorization check regardless of provider:
```java
public InMemoryTaskStore() {
this.authorizationProvider = null; // default wiring
}
@Override
public @Nullable Task get(String taskId) {
return tasks.get(taskId); // no owner / caller check
}
```
Authorization is enforced only when the application both supplies a `TaskAuthorizationProvider`
*and* routes requests through `AuthorizationRequestHandlerDecorator` (via CDI), which checks
ownership before delegating. A server that uses the default store, or wires
`DefaultRequestHandler.builder().build()` manually, or integrates through a non-CDI stack (e.g.
Spring), never reaches that check. The safe posture is therefore opt-in and the shipped default is
the unsafe one. A caller can read a task created by another caller simply by knowing or guessing
its id.
## Summary
With the SDK's default configuration, task reads are not authorized: any caller can retrieve a
task (including its status, context, message history, and artifacts) created by another caller,
by supplying the task id.
## PoC
Using only the real production classes wired the default way (no mocks):
1. Construct the default store: `InMemoryTaskStore store = new InMemoryTaskStore();` (no-arg
constructor, so no authorization provider).
2. As one caller, save a task: `store.save(victimTask, false);` with id `victim-task-42`.
3. As a second, unrelated caller with no auth context, read it back: `store.get("victim-task-42")`.
The second caller receives the first caller's task in full, with no authorization check:
```
unauthenticated get(victim-task-42) returned task owned by nobody-checked: victim-task-42 / ctx=victim-ctx
```
Verified on `main` (commit `72d220c`, JDK 21) and reproduces unchanged on `1.2.0.Final`.
## Impact
Task data crosses caller boundaries with no authorization. In any multi-caller deployment built on
the default wiring, one caller can enumerate and read another caller's tasks, including task status,
context id, the message history, and any artifacts the task carries, which for agent workloads is
frequently sensitive input and generated content. Because the insecure behaviour is the default
rather than a misconfiguration, it is easy to ship unintentionally, and in the default/reference
deployment the transport endpoints are served without authentication enforced, so the read is
reachable by an unauthenticated caller (`PR:N`). CVSS is scored against the default configuration
as shipped.
## Remediation
Fail closed by default: deny task reads when no authorization provider is configured, rather than
treating a missing provider as allow-all, and apply the authorization check in the store's `get`
path (not only in `list` and the CDI decorator) so it holds regardless of how the handler is
wired. If the current permissive default is retained for single-user/testing scenarios, emit a
prominent startup warning when the server comes up with no authorization provider so it cannot be
shipped by accident.
## Workarounds
Until a fixed release, configure a `TaskAuthorizationProvider` and ensure requests are routed
through the authorization decorator (CDI wiring), rather than relying on the default no-arg store
or a manually built handler.
## References
- CWE-1188: Insecure Default Initialization of Resource: https://cwe.mitre.org/data/definitions/1188.html
- CWE-862: Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
Missing authorization in the configuration cascade operations of the Collaboration Server in Unblu inc. Unblu Spark 7.0 through 8.36.1-hotfix.0, on on-premises and cloud deployments, allows an authenticated remote attacker to read and change configuration properties of entities they aren't authorized to access, including other users, other accounts and, in Unblu Cloud, other customers' accounts, via configuration read and write operations that target those entities.
The Collaboration Server doesn't check whether the user reading or changing configuration has access to the entity the configuration belongs to. With certain non-default configuration validation settings, a registered user can additionally write configuration properties they aren't allowed to edit, in any scope.
Exploitation requires an authenticated session but no user interaction.
The extension no longer applied its access protection to files in file storages that use a non-default relative base path. These files were served directly by the web server, without any authentication or permission check. The issue is only exploitable when the extension is used on a website running TYPO3 14.3.
The routes that provide consent history and statistics data did not check whether the backend user had access to the module or to the requested page. Any authenticated backend user, regardless of permissions, could therefore retrieve consent data of any site in the installation.
The JSON import of the cookie consent configuration did not respect the backend user's permissions. Non-admin backend users with access to the module could import a configuration that adds arbitrary scripts to the frontend of the website.
The order cancellation function accepts an order identifier from the request and acts on that order without checking that the caller owns it. Any site visitor can set orders that are still awaiting payment to "canceled". This requires a page that contains the shop's order plugin. Orders that are already paid are not affected.
The payment notification endpoint for PayPal accepts incoming data without verifying that it comes from the payment provider. Any site visitor can overwrite the stored payment notification of an order that is still awaiting payment with arbitrary content. This requires a page that contains the shop's order plugin. Orders that are already paid are not affected.
The extension provides a backend endpoint that writes a submitted value into a submitted field of a submitted page record. It neither checks the user's permissions nor limits which fields can be changed. Any authenticated backend user can therefore change any property of any page, including its access permissions and configuration, outside the scope granted to them.
The AJAX routes of the extension do not check whether a backend user has access to the related module or dashboard widget. Any backend user can therefore retrieve analytics data of the sites they have page access to.
CVE-2025-7043 is a missing authorization vulnerability in WSO2 API Manager's ForgeRock client. The flaw allows refresh tokens to be incorrectly validated as valid access tokens, bypassing the requirement for client credentials when exchanging refresh tokens for access tokens. An attacker with a stolen or exposed refresh token can directly access protected resources without proper authorization checks.
Mercury is a Python framework for sharing Jupyter notebooks as web applications and dashboards. Prior to 3.2.6, default tokenless deployments allow anonymous clients to create Jupyter kernels and send execute_request messages containing arbitrary Python. The endpoint blocklist does not cover /api/kernels, and the websocket wrapper previously tracked idle activity without authorizing executable messages. This issue is fixed in version 3.2.6.